7 ms·

On Android Fragmentation

61 points by jokermatt999 16y ago

moultano 16y ago
Nice to have some actual information in one of these posts. I'd be interested to hear the experience of android app developers who have had to deal with different phone models. Android's biggest marketing challenge is the disinformation.
martythemaniak 16y ago
One important point is how much misinformation there is out there over fragmentation - a lot of it written by people who don't know (and usually don't care to know) much about the actual issues. 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.
- Groxx 16y ago
  correctly-placed layout weights will give you the flexibility to deal with slightly different aspect ratios. 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.
  - martythemaniak 16y ago
    Maybe it's my web-dev background, but Android reminds me a lot of that. When designing a web-app, styling it using CSS is such a fundamental part of it, that it shouldn't be considered a different activity. No one would seriously put up a webapp that relied on the browser's native rendering of lists, input boxes etc. 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).
    - Groxx 16y ago
      I see a ridiculous amount of fixed-width webpages, which would imply that using even fairly simple, standard components in a fluid way is far more difficult than many developers are interested in doing. Many, not all by any means. 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.)
      - 16y ago
- dieterrams 16y ago
  Re: the Multiple Resolutions Problem, it's probably less of an issue if you're writing a utility app. But for games, which frequently make use of resolution-dependent assets, it is far from trivial or fictitious. A larger developer might be able to eat the cost of maintaining multiple sets of assets, but smaller developers frequently can't. Nor can they typically afford to own a comprehensive set of devices to test on, which is necessary if you're trying to figure out things like how many sprites or particles you can display at a given resolution and framerate.
  - martythemaniak 16y ago
    The solution is rather simple - start with a high-res asset, put it in the drawable-hdpi folder, then downscale by 66% to get the mid-res assets. 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.
    - dieterrams 16y ago
      The solution is rather simple - start with a high-res asset, put it in the drawable-hdpi folder, then downscale by 66% to get the mid-res assets. 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.
- FooBarWidget 16y ago
  What is the 1.5 vs 1.6 problem? I thought in the Android SDK you can select your target. What's forcing you to use 1.6 during development?
  - blasdel 16y ago
    It's very common for newer releases of SDK toolchains to drop support for targeting older SDKs. Apple has done the same thing with OS X several times.
lenni 16y ago
To me the key point of this post was:"And in the long term, as the mobile industry gets more accustomed to the idea of upgradeable phone software, more and more devices will be be upgraded." 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.
- enjo 16y ago
  Why? Sense seems to work just fine for me. Every app I've downloaded (I've tried ~100 or so) works great. Sense integrates well, and seems to work perfectly with any integration points it has with 3rd party apps. It really seems to be a thin layer that really dresses up (in my opinion) the overall experience.
  - biafra 16y ago
    I think the problem with sense ui is not so much the apps but the time HTC needs to upgrade to the latest Android release on their phones.
  - sharksandwich 16y ago
    It's great Sense works for you, but I hate that it's not optional. I shouldn't have to root my phone to run vanilla Android
- NateLawson 16y ago
  I agree that's the key part. However, perhaps the reason upgrades are so slow is that Google is moving too fast for OEMs. Their profit margin on these Android phones is lower because they're more powerful and costly than the typical Symbian phone. No other phones (Blackberry, Sidekick) require them to be as involved in updating software. Apple ships iPhone OS updates via iTunes, not AT&T or Samsung. 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?
davidedicillo 16y ago
I'll give my opinion as a designer. I want to be able to have control on what my user will be. That's why Pantones exists in print. That's why designers love spending hours to polish their iPhone apps, because they want them pixel-perfect. That's why I curse every time a client of mine tells me he can't see the site well in IE6. Will I start developing for Android as well? Of course, I'd be stupid not to, but I hate the fact I know the UX won't as near as the one iPhone users of the same app will have.
- not_an_alien 16y ago
  iPhone devices will see fragmentation soon too. iPad has a different resolution, the next iPhone will too. The problems you see with Android today are just problems that Apple is holding on but that will have to be faced in the future - it won't be the same 320x480 device anymore. 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.
  - jcsiracusa 16y ago
    "it won't be the same 320x480 device anymore." 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.
    - spot 16y ago
      not for the iPad.
    - ZeroGravitas 16y ago
      No-one seems to mention the downside of this approach. The iPhone is going to jump from what has always been an okay resolution but is now becoming low resolution, to what is going to be a high resolution but not for very long because very similar phone resolutions have been available for about a year now. Newer devices will continually increase the resolutions available but Apple can't improve on theirs until they double height/width, and quadruple pixels again. 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.

61 points by jokermatt999 16y ago

Nice to have some actual information in one of these posts. I'd be interested to hear the experience of android app developers who have had to deal with different phone models. Android's biggest marketing challenge is the disinformation.

martythemaniak 16y ago

One important point is how much misinformation there is out there over fragmentation - a lot of it written by people who don't know (and usually don't care to know) much about the actual issues. 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.

Groxx 16y ago
correctly-placed layout weights will give you the flexibility to deal with slightly different aspect ratios. 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.
- martythemaniak 16y ago
  Maybe it's my web-dev background, but Android reminds me a lot of that. When designing a web-app, styling it using CSS is such a fundamental part of it, that it shouldn't be considered a different activity. No one would seriously put up a webapp that relied on the browser's native rendering of lists, input boxes etc. 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).
  - Groxx 16y ago
    I see a ridiculous amount of fixed-width webpages, which would imply that using even fairly simple, standard components in a fluid way is far more difficult than many developers are interested in doing. Many, not all by any means. 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.)
    - 16y ago
dieterrams 16y ago
Re: the Multiple Resolutions Problem, it's probably less of an issue if you're writing a utility app. But for games, which frequently make use of resolution-dependent assets, it is far from trivial or fictitious. A larger developer might be able to eat the cost of maintaining multiple sets of assets, but smaller developers frequently can't. Nor can they typically afford to own a comprehensive set of devices to test on, which is necessary if you're trying to figure out things like how many sprites or particles you can display at a given resolution and framerate.
- martythemaniak 16y ago
  The solution is rather simple - start with a high-res asset, put it in the drawable-hdpi folder, then downscale by 66% to get the mid-res assets. 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.
  - dieterrams 16y ago
    The solution is rather simple - start with a high-res asset, put it in the drawable-hdpi folder, then downscale by 66% to get the mid-res assets. 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.
FooBarWidget 16y ago
What is the 1.5 vs 1.6 problem? I thought in the Android SDK you can select your target. What's forcing you to use 1.6 during development?
- blasdel 16y ago
  It's very common for newer releases of SDK toolchains to drop support for targeting older SDKs. Apple has done the same thing with OS X several times.

lenni 16y ago

To me the key point of this post was:"And in the long term, as the mobile industry gets more accustomed to the idea of upgradeable phone software, more and more devices will be be upgraded." 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.

enjo 16y ago
Why? Sense seems to work just fine for me. Every app I've downloaded (I've tried ~100 or so) works great. Sense integrates well, and seems to work perfectly with any integration points it has with 3rd party apps. It really seems to be a thin layer that really dresses up (in my opinion) the overall experience.
- biafra 16y ago
  I think the problem with sense ui is not so much the apps but the time HTC needs to upgrade to the latest Android release on their phones.
- sharksandwich 16y ago
  It's great Sense works for you, but I hate that it's not optional. I shouldn't have to root my phone to run vanilla Android
NateLawson 16y ago
I agree that's the key part. However, perhaps the reason upgrades are so slow is that Google is moving too fast for OEMs. Their profit margin on these Android phones is lower because they're more powerful and costly than the typical Symbian phone. No other phones (Blackberry, Sidekick) require them to be as involved in updating software. Apple ships iPhone OS updates via iTunes, not AT&T or Samsung. 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?

davidedicillo 16y ago

I'll give my opinion as a designer. I want to be able to have control on what my user will be. That's why Pantones exists in print. That's why designers love spending hours to polish their iPhone apps, because they want them pixel-perfect. That's why I curse every time a client of mine tells me he can't see the site well in IE6. Will I start developing for Android as well? Of course, I'd be stupid not to, but I hate the fact I know the UX won't as near as the one iPhone users of the same app will have.

not_an_alien 16y ago
iPhone devices will see fragmentation soon too. iPad has a different resolution, the next iPhone will too. The problems you see with Android today are just problems that Apple is holding on but that will have to be faced in the future - it won't be the same 320x480 device anymore. 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.
- jcsiracusa 16y ago
  "it won't be the same 320x480 device anymore." 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.
  - spot 16y ago
    not for the iPad.
  - ZeroGravitas 16y ago
    No-one seems to mention the downside of this approach. The iPhone is going to jump from what has always been an okay resolution but is now becoming low resolution, to what is going to be a high resolution but not for very long because very similar phone resolutions have been available for about a year now. Newer devices will continually increase the resolutions available but Apple can't improve on theirs until they double height/width, and quadruple pixels again. 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.