On Android Fragmentation
android-developers.blogspot.com
android-developers.blogspot.com
One common meme is the Multiple Resolutions Problem - you know, the onerous problem a developer faces when he has to support both HVGA, QVGA and WVGA resolutions. Except, if you actually do write an app that works well across all those, you find out that managing multiple resources for multiple resolutions is trivial, and that correctly-placed layout weights will give you the flexibility to deal with slightly different aspect ratios.
That is not to say there aren't actual issues - one pain point comes up if you wish to target 1.5 so you can get the widest distribution possible, but are forced to use 1.6 as your target during development.
But just to illustrate my point, try a google search for the fictitious resolution "fragmentation" problem, then try one for the real 1.5 vs 1.6 problem.
Slightly different sizes, yeah. But the problem for some people / designs, and ultimately for end-users, is that it makes super-designed apps like you see on the iPhone more difficult to make.
Not that that should prevent people from programming for / using Android. I personally plan to code a bit for it. But high degrees of polish are significantly more difficult than for a single screen size, and the iPhone has pretty much demonstrated that it does in fact matter to the average user.
With the iPhone you do get a lot of that polish for free, whereas with Android the basics won't get you as far. How much more difficult is it? Depends, it's somewhere between an iPhone and a webapp. IIRC, I probably dedicated about 1 week on my last project to this kind of work, which was around 10 weeks.
Another thing to consider is how much of that polish is simply due to timing - many iPhone apps have been out there much longer and until it's recent stellar rise, Android was seen as a second-rate platform with far fewer resources devoted to it (for example, the Facebook apps).
Ask an average phone user if they think of the UI as a webpage. Given that nearly all are menu / button based, not links-in-content based, I'd imagine nearly all will say "no". The expectations differ, so their perceptions of the same app differ.
Ultimately, which do you want: ubiquitous Android, or geek-only Android? And guess which the average users (and thus hardware makers) want. The push will be to make it ubiquitous, thus successful apps must compete with the iPhone directly in usability and "feel", or people will always feel they've got a second-rate device / application, which is degrading to the whole ecosystem.
(for clarification: different devices on the hardware don't bother me for programming - use them or don't, it's your app. The many screen sizes however imply fluid layouts, or huge amounts of fixed + minor fluidity... and clearly nobody wants to make those if they've got careful design (see: webpages). In time with a good library or ten, this could definitely change, as would more focus on design for Android apps. But until that happens, it's fairly damaging to highly-polished apps, which tend to make money more effectively.)
Given the amount of reading I tend to do, and the infinite-scrollability of webpages, I'm often a portrait-mode fan. It just sucks when you need a bunch of applications open for comparison / parallel development.
edit: hm. widescreen / horizontal Android devices exist (ODROID). So we're back to the same issue...
If you've ever tried doing a UI Layout for Android, you'll find it's actually pretty damn easy to support multiple resolutions. If you're actually interested, here's the canonical resource on supporting different screen in Android: http://developer.android.com/guide/practices/screens_support...
BTW dealing with multiple resolutions is a problem that's rapidly heading to the Apple ecosystem. The iPad is 1024 × 768, the current iPhone is 320×480, the next iphone is rumored to be some multiple of the current iPhone resolution, etc.
You still need to make a ton of resolution-specific images if you want the sharpest possible image, which - again - matters for perceived value. And you're royally screwed if you do pixel-art instead of something easily resized.
The issue here isn't for all applications, it's for highly styled applications, which are kicking ass lately and are important for perceived value of a device. Resolution independence and fluid-ish layouts do indeed make basic UI extremely easy. But basic UI evidently can't compete equally with a more stylized UI, as the iPhone shows pretty clearly.
Support that. I can name several apps on my iPhone that are hardly high-style, yet useful and well received (Quickoffice, iFitness, Yelp!... just to name 3 on my home screen).
Larger than this. This is something that vector graphics solves extremely well. You want really nice images at multiple resolutions? Illustrator is your friend.
Think it's coincidence?
[1] : http://www.macrumors.com/c.php?u=http%3A%2F%2Fitunes.apple.c...
edit: and again. Pixel art. 3D / vector art isn't the only kind, you know. Just look at any favicon, for example.
The whole "fragmentation" thing, at least in terms of API's and developer issues, is more of a talking point than a reality.
The real difference is that with iPOS, Apple doesn't expect developers to automatically handle new device resolutions, and no developer expects to not be informed of new resolutions. Android developers are expected to use fluid layouts, and don't expect to be able to keep up with the release of new and customized devices by a bevy of semi-incompetent manufacturers.
2. Take the typical case right now - accommodating the Nexus One and a typical large-screen HVGA device - the difference would be about 0.5-0.8cm in extra vertical space. Coming up with a design to work on both screens isn't going to ruin your application, neither is it so exceptionally hard as to not be worth it. As you've demonstrated, its a very popular piece of Android FUD right now.
2) so if you've got a background image which you want a button to appear over, you either need bottom buffer space on one, and is weighted off the bottom, or it gets cut off on the other. Or you need two images and two layouts. Same issue, and this is for highly styled apps, not for basic stuff (which is legitimately easy).
As to the resolution independence, you still need to make a ton of resolution-specific images if you want the sharpest possible image, which - again - matters for perceived value. And you're royally screwed if you do pixel-art instead of something easily resized.
2) Having different resolution renderings of 3D images or tile/patterned images is not a problem. Think of Bejeweled on the iPhone (it is a stylish app that uses a bg image as per your example) - minor cutoffs (ie showing more sky) and different resolutions would not be a big issue.
Given the new iPhone 4G (2x the resolution) and the iPad (different resolution and different screen size) these are issues iPlatform developers face too, and they'll get around them the same way.
While some fixed width designs are because the designer went nuts with the rasters and making it scale is hard, many designers are doing it for good reason.
[citation needed ;) ]
Incidentally, this is what iPhone developers will have to start doing this summer. The new iPhone's screen is 2x the resolution. Assuming Apple wants to keep the iPhone forward-compatible and run OS3-based apps, that means image resources will be upscaled by the phone and look fuzzy, or developers will have to update their apps with higher-res assets.
As for framerates, you'll never get away from dealing with different hardware, no matter if you do Android, Web, Desktop or iPhone development. I have a first-gen iPhone and you have no clue how frustrating (ie slow) it is running many apps on it.
This technique doesn't work for pixel art, which can only be scaled up by whole number values. In certain cases where a display's resolution isn't a whole number multiple of the base resolution, you can get away with slightly shrinking or extending the viewable area. But 480x320 to 800x480 is a particularly inconvenient shift, as assets cannot be scaled up without incurring a large loss in viewable area, and they cannot be kept the same without requiring a large increase in viewable area.
Incidentally, this is what iPhone developers will have to start doing this summer. The new iPhone's screen is 2x the resolution. Assuming Apple wants to keep the iPhone forward-compatible and run OS3-based apps, that means image resources will be upscaled by the phone and look fuzzy, or developers will have to update their apps with higher-res assets.
Not true at all. It would only look fuzzy if the screen size were significantly larger. But in fact the screen size is roughly the same, only with a much higher PPI. Because the new resolution is a whole number multiple of the old, all apps can be trivially scaled with 2X nearest-neighbor scaling and look exactly the same as they would on a 480x320 screen.
As for framerates, you'll never get away from dealing with different hardware, no matter if you do Android, Web, Desktop or iPhone development. I have a first-gen iPhone and you have no clue how frustrating (ie slow) it is running many apps on it.
I actually do have a first-gen iPhone. In my experience, it hasn't been that slow for the majority of apps I want to use. But that's sort of irrelevant. As far as a developer is concerned, they only need to own two devices (three after the new iPhone is released) to capture the significant variations in hardware: a first-gen or 3G iPhone, and a 3GS. (Alternatively, and more cheaply, a first-gen and third-gen iPod touch, if you have no need for camera, GPS, etc.)
And it's true that you can never get away from dealing with different hardware, but the whole point is how much different hardware you have to deal with. Apple has been very careful about keeping that to a minimum while satisfying demand for better hardware.
apple has also, by denying the problem, failed to provide good APIs for multiresolution. android as faced and addressed the problem from the get-go and has a better solution.
iPhone apps on the iPad look fuzzy because (A) it does not use nearest-neighbor scaling, and (B) the screen is way larger, with a much lower PPI. It would be surprising if the iPhone HD doesn't use nearest-neighbor scaling.
And Apple hasn't denied a problem because it hasn't created one.
Google is doing a fantastic job with Android, it's just that the carriers and OEMs are dragging their feet at properly supplying their handsets with updates. To make matters worse they continue to fiddle with the Android system (see HTC's Sense UI) for no apparent benefit to the consumer other than to make their phone 'stand out'.
I'm currently very angry with HTC and T-Mobile for their last century attitude to mobile devices. It's ridiculous that they have promised to upgrade my Hero to 2.1 since March and still nothing - also the last firmware update also conveniently disabled all possibility to root the phone. Say what you want about the iPhone, it is at least supplied with updates for a reasonable amount of time (~3 years?) and older models don't get their update months late.
I think we'll see a fundamental testing of the limits of Android fragmentation this year as OEMs have to support so many different phones, starting from various points on 2.x. At what point will they cut off a phone as too old for updates? Will it be similar to Windows where you have an extended support period with only security fixes? Who patches security flaws in your browser on a G1 running 1.6 in 2011? HTC?
It may be a symptom of Googles quick development cycles, but its still a problem. It may be one Google cannot solve but this blog post to me didnt address that issue, rather it said this is what we think fragmentation is, look at all the things we do to fix it. But in reality, for me, the fragmentation is mostly about the varying versions of android around.
Perhaps if HTC were to charge you for the upgrade, in order for them to prioritize the development of it? Would you pay $50 for the upgrade if it meant it would happen in the next month as opposed to ages down the track?
The solution - proper placement, scaling, different layout flow methods - have been around for ages, and it's up to developers to employ them.
And because Android devs had to deal with them already, I can't wait to see the barrage of shit that will happen when devs unprepared for it have to deal with the new iPhone resolutions.
Well, it'll be 640x960 which is a nice integer multiple of the current iPhone resolution, allowing older apps to remain visibly unchanged without and code changes. As for the iPad, it's distinguished from the iPhone and iPod touch not by its resolution but by its size, necessitating new UI for that reason alone. I expect Apple to continue along these lines, requiring UI designs tailored to a few physical screen sizes, using integer multiples of existing resolutions to insulate developers from these changes.
Similarly the iPad doesn't have steller resolution, and unless they want the dreaded fragmentation, they'll not be able to do anything about it until they can double/quadruple the screen from what it is now.
By locking themselves into these resolutions they wander far from the display screen sweet-spot either shipping cheap, low-res displays or expensive, high-res displays. They can't even go to triple current resolution, as that would still look grubby on the middle device without a separate image which defeats the point.
And, apart from certain types of apps, it doesn't buy them anything. When displaying video or images, no difference as it's just scale to fit regardless. When displaying text in books or websites, they take the quality hit whenever they're not at the top of the resolution cycle. In return they get app UIs that are basically hand-drawn pictures and grid-fitted pixel art.
It's an engineering trade-off, and for my particular uses, it doesn't really pay off.