Android fragmentation is a feature, not the big problem everyone says it is(vbsteven.com)
vbsteven.com
Android fragmentation is a feature, not the big problem everyone says it is
http://vbsteven.com/archives/595
11 comments
I dissagree as I haven't had a lot of problems with the apps I've worked on. But maybe it's because of the APIs I've used, some of them are probably more solid than others, I never had to use NIO or Bluetooth.
As far as the design guidelines, there is a compatibility library that lets you use them back to 1.6.
As far as the design guidelines, there is a compatibility library that lets you use them back to 1.6.
But NIO, Location APIs, and in some cases the Bluetooth APIs are kind of important to the platform and used by most Android developers.
I have used Location without a problem, I don't know why you would ask the GPS for the time anyway.
Wifi only devices have no time source (Android doesn't include NTP) so a wifi only device can have drifted quite a bit.
> As of march 2012, 92% of devices are running Android 2.2 (Froyo) and higher. The
> Froyo feature set is a really good base line for most of the applications. I challenge
> you to find a new feature in higher versions that you really need to have in a general purpose app.
So, for "general purpose apps", whatever that is, Android 2.2 (which was launched 2 years ago) is great. 2 years is ages in computer land and this is a huge issue, even though the author likes to downplay this because the 2 year old software works "just fine". Android is very fragmented and if you have to develop for 2 year old software still today, that's a big proof.
> Developer tools
This whole section can be skipped when developing for iOS. Big deal, there are tools to help you develop for the chaos that is the Android flora. Just because the tools exist doesn't mean it's easy to support all these different devices.
> Developers can provide different graphics for different screen sizes
I don't have the exact number on the range of Android screen sizes, but there's much more work to this than the author implies. Just because you can doesn't mean it's easy.
> There is an emulator and UI builder that can emulate any Android version, screen resolution
> and pixel density combo
The ARM emulator is really really slow. Maybe it's picked up speed with Android x86 but when I was developing for Android the emulator was almost unusable and basically everybody's advice was to go out and buy an Android device. This will get pretty expensive pretty fast if you need to emulate the range of Android devices.
> It doesn’t matter if you prefer a large vs a small screen, a hardware keyboard vs software
> input, a 1Ghz+ quadcore vs a 600Mhz single core, a device from an A brand vs a Chinese
> copy or maybe you just want the best available phone for you specific budget.
> There will be a device available for your needs. This is only possible due to the so called
> “fragmentation”.
IMHO, sure, some people prefer larger screen or a hardware keyboard. But the rest of this paragraph doesn't make sense. Who'd want a single core rather than quadcore? Who'd want a chinese knock off instead of a brand? This is both just a question of budget. So in reality, again IMHO, I think the "featureful" difference between Android devices is much less then is purported in this post.
Just one more thing, I'm not knocking on Android as such - variety is good and Android has some features over iOS and iOS has features over Android. But having developed a little bit for both platforms, Android is definitely very fragmented and harder to develop for.
> Froyo feature set is a really good base line for most of the applications. I challenge
> you to find a new feature in higher versions that you really need to have in a general purpose app.
So, for "general purpose apps", whatever that is, Android 2.2 (which was launched 2 years ago) is great. 2 years is ages in computer land and this is a huge issue, even though the author likes to downplay this because the 2 year old software works "just fine". Android is very fragmented and if you have to develop for 2 year old software still today, that's a big proof.
> Developer tools
This whole section can be skipped when developing for iOS. Big deal, there are tools to help you develop for the chaos that is the Android flora. Just because the tools exist doesn't mean it's easy to support all these different devices.
> Developers can provide different graphics for different screen sizes
I don't have the exact number on the range of Android screen sizes, but there's much more work to this than the author implies. Just because you can doesn't mean it's easy.
> There is an emulator and UI builder that can emulate any Android version, screen resolution
> and pixel density combo
The ARM emulator is really really slow. Maybe it's picked up speed with Android x86 but when I was developing for Android the emulator was almost unusable and basically everybody's advice was to go out and buy an Android device. This will get pretty expensive pretty fast if you need to emulate the range of Android devices.
> It doesn’t matter if you prefer a large vs a small screen, a hardware keyboard vs software
> input, a 1Ghz+ quadcore vs a 600Mhz single core, a device from an A brand vs a Chinese
> copy or maybe you just want the best available phone for you specific budget.
> There will be a device available for your needs. This is only possible due to the so called
> “fragmentation”.
IMHO, sure, some people prefer larger screen or a hardware keyboard. But the rest of this paragraph doesn't make sense. Who'd want a single core rather than quadcore? Who'd want a chinese knock off instead of a brand? This is both just a question of budget. So in reality, again IMHO, I think the "featureful" difference between Android devices is much less then is purported in this post.
Just one more thing, I'm not knocking on Android as such - variety is good and Android has some features over iOS and iOS has features over Android. But having developed a little bit for both platforms, Android is definitely very fragmented and harder to develop for.
For what it's worth, versions newer than android 2.2 do have features that are worth using. My personal favorite is hardware accelerated graphics. That really does make the phone's UI feel as snappy as the one on iOS.
Then there's the support for multi-core apps (introduced in 3.0), resizable widgets (3.1), social API (4.0), calendar api (4.0), beam (4.0), low-level media streaming (4.0), media effects(4.0) .. and many many others. Android 4.0 is full of goodies.
My first Android "app" (actually, a runtime for HTML5 apps call Blossom[1]) only will run on ICS because its requires hardware-accelerated graphics and surfaces.
On iOS, I could support all the way back to the original iPhone, but I'm actually requiring iOS 5 (that includes all three iPad generations, and the iPhone 3GS, 4, and 4S) mainly so I can use ARC and because people in the iOS ecosystem update so fast anyway.
[1] https://github.com/fohr/blossom
On iOS, I could support all the way back to the original iPhone, but I'm actually requiring iOS 5 (that includes all three iPad generations, and the iPhone 3GS, 4, and 4S) mainly so I can use ARC and because people in the iOS ecosystem update so fast anyway.
[1] https://github.com/fohr/blossom
"The ARM emulator is really really slow. Maybe it's picked up speed with Android x86 but when I was developing for Android the emulator was almost unusable and basically everybody's advice was to go out and buy an Android device. This will get pretty expensive pretty fast if you need to emulate the range of Android devices."
This is spot on and. I've used other J2ME emulators in the past and it shocks me that the current Android emulator is acceptable and hasn't improved that much. I mean, one can't even begin to convey how ridiculously slow it is and in this day and age, that's unacceptable. Especially when you put it next to the iOS simulator - which has been fast from day one. In fact, this can be said for all the Android tools.
The people making Android might see all this as great and feel good about working with the OS community, but as someone who has to deliver apps using those tools, they - imo - suck and are counter productive. But, that can be said about most of the Java stack/tools, which is why I abandoned it years ago.
This is spot on and. I've used other J2ME emulators in the past and it shocks me that the current Android emulator is acceptable and hasn't improved that much. I mean, one can't even begin to convey how ridiculously slow it is and in this day and age, that's unacceptable. Especially when you put it next to the iOS simulator - which has been fast from day one. In fact, this can be said for all the Android tools.
The people making Android might see all this as great and feel good about working with the OS community, but as someone who has to deliver apps using those tools, they - imo - suck and are counter productive. But, that can be said about most of the Java stack/tools, which is why I abandoned it years ago.
> ... current Android emulator is acceptable
I don't know a single Android developer who uses the emulator. As you point out, I don't understand how I can run the emulator on a 3 point something gigahertz processor with zillions of cores, many gigabytes of RAM and the emulator has the same sort of performance as a 100MHz ARM device.
And even if you manage to get the emulator running it is virtually useless. Various pieces are missing. A lot of my work involved sound. The trivial "play this mp3" interface worked, but doing anything else failed. For practical purposes you cannot play or record audio.
Then Google likes to have bugs such as the WebView crashing when you use addJavascriptInterface. This means you can't run most apps that use WebViews. The bug has been there for 18 months, starred by many users, and Google has done SFA about it. Most importantly, why does the emulator differ in behaviour from the real device?
http://code.google.com/p/android/issues/detail?id=12987
I don't know a single Android developer who uses the emulator. As you point out, I don't understand how I can run the emulator on a 3 point something gigahertz processor with zillions of cores, many gigabytes of RAM and the emulator has the same sort of performance as a 100MHz ARM device.
And even if you manage to get the emulator running it is virtually useless. Various pieces are missing. A lot of my work involved sound. The trivial "play this mp3" interface worked, but doing anything else failed. For practical purposes you cannot play or record audio.
Then Google likes to have bugs such as the WebView crashing when you use addJavascriptInterface. This means you can't run most apps that use WebViews. The bug has been there for 18 months, starred by many users, and Google has done SFA about it. Most importantly, why does the emulator differ in behaviour from the real device?
http://code.google.com/p/android/issues/detail?id=12987
Saying 92% have Android 2.2 and above makes it look as if there are 92% of them that have only Froyo, and the rest 8% are Gingerbread and ICS. It's not like that. Last I checked around November or December last year, 75% of them had Gingerbread. I figure by now there should be around 85% that have Gingerbread.
I haven't tried the emulator in a while but they've just announced that the new emulator can be run at near-native x86 speed with some modifications, and it also has GPU acceleration for Android 4.0+ API's.
That being said, I still wish they found a way to make it an order of magnitude easier to upgrade your own Android smartphone, and do it soon after the new version has just been released.
I haven't tried the emulator in a while but they've just announced that the new emulator can be run at near-native x86 speed with some modifications, and it also has GPU acceleration for Android 4.0+ API's.
That being said, I still wish they found a way to make it an order of magnitude easier to upgrade your own Android smartphone, and do it soon after the new version has just been released.
Not sure where you checked, but based on Google's numbers, about 67% are on 2.3 or better (and 1.6% on 4.x). See http://developer.android.com/resources/dashboard/platform-ve...
> So, for "general purpose apps", whatever that is, Android 2.2 (which was launched 2 years ago) is great. 2 years is ages in computer land and this is a huge issue
Brand new Windows apps work on Windows XP and are written to APIs that work on Windows XP, which is now 10 years old.
I'm not going to argue the Android fragmentation issue other than to say API stability > API age for installed "packaged"* software.
* - If there is such a thing anymore. I buy most of my Windows software online or through Steam.
Brand new Windows apps work on Windows XP and are written to APIs that work on Windows XP, which is now 10 years old.
I'm not going to argue the Android fragmentation issue other than to say API stability > API age for installed "packaged"* software.
* - If there is such a thing anymore. I buy most of my Windows software online or through Steam.
The big problem is one of customer expectation. End users don't really care about which version of Android is which. They care, for the most part, about being able to run their favourite apps on a device.
When a customer buys an Android device, rightly or wrongly they more or less expect it to behave in the same way as their friend's. Even if their friend has a SG SII and they've just bought a ZTE or Huawei. After all, that's how things (more or less) work for iOS.
What a lot of operators have found is that when they flood their network with cheap, low end Android devices (which are not adequately explained as such), that many get returned. Many of these returns are 'No Fault Found' - meaning that there was no technical fault with the device at all, but it didn't meet the customers expectations.
The argument that it was a feature would work if there were tighter minimum hardware specs for running Android, but too often fragmentation means the Android platform being misused by being loaded onto poorly equipped devices.
When a customer buys an Android device, rightly or wrongly they more or less expect it to behave in the same way as their friend's. Even if their friend has a SG SII and they've just bought a ZTE or Huawei. After all, that's how things (more or less) work for iOS.
What a lot of operators have found is that when they flood their network with cheap, low end Android devices (which are not adequately explained as such), that many get returned. Many of these returns are 'No Fault Found' - meaning that there was no technical fault with the device at all, but it didn't meet the customers expectations.
The argument that it was a feature would work if there were tighter minimum hardware specs for running Android, but too often fragmentation means the Android platform being misused by being loaded onto poorly equipped devices.
How can something that raises the costs of development be regarded as a feature?
It might not be a fatal problem, but it does raise the barrier to entry, and it does reduce profitability for apps that are more marginal.
It might not be a fatal problem, but it does raise the barrier to entry, and it does reduce profitability for apps that are more marginal.
The article clearly states it is a feature for consumers, not developers, a feature that is largely responsible for the success of Android as a platform, since consumers have a choice to pick what kind of device they like.
It is relatively harder to develop for Android than for iOS, but it is nowhere near being as big of an issue as some are trying to portray it. Of course if you are, for example, a one man band developer, it will be very difficult to provide high quality native experiences on two different platforms, but that's a limitation of time and experience, not of inherent impossibility of any platform.
It's not a limitation of experience. Regardless of how experienced you are, it will still cost you more.
Higher development costs for apps is a problem for consumers as well as developers.
When developers complain about fragmentation they aren't complaining about the diversity of form factors and device capabilities.
They are complaining that these aren't cleanly abstracted away by the operating system, and that the delivery of updates is a mess.
OS Support for diverse hardware is a feature. Fragmentation is not.
Apple sidesteps this problem by not supporting diverse hardware.
Android could potentially solve the problem with better abstraction and a better software update process, but hasn't yet, so the costs are passed on to developers and consumers.
Higher development costs for apps is a problem for consumers as well as developers.
When developers complain about fragmentation they aren't complaining about the diversity of form factors and device capabilities.
They are complaining that these aren't cleanly abstracted away by the operating system, and that the delivery of updates is a mess.
OS Support for diverse hardware is a feature. Fragmentation is not.
Apple sidesteps this problem by not supporting diverse hardware.
Android could potentially solve the problem with better abstraction and a better software update process, but hasn't yet, so the costs are passed on to developers and consumers.
I agree in regards to a better software update process. I don't know how much the abstraction could be improved, since the diversity makes some things impossible to abstract. I should clarify I'm talking from a perspective of developing apps, not games (simple apps at that, as I started learning Android slightly more than half a year ago), so I haven't encountered the really difficult development issues that games developers stumble upon so often. What I have learned so far, however, has helped me plan out each project better. What in the beginning seemed an issue that will double the amount of work (and maybe even was so on the first project), ended up being solved with maybe 5 to 10% more effort and thought on the second project.
Yes, either way you look at it, it is more work, but with experience it has become more or less marginal for me. Although it could also be that once you accept something as unchangeable fact, you adapt expectations and it no longer represents a source of frustration :). Who knows!
Edit: Reading my post, I realised how ridiculous my claim of experience is based on working on Android for less than a year, especially without any other previous programming experience, but I hope it's still clear what I mean.
Yes, either way you look at it, it is more work, but with experience it has become more or less marginal for me. Although it could also be that once you accept something as unchangeable fact, you adapt expectations and it no longer represents a source of frustration :). Who knows!
Edit: Reading my post, I realised how ridiculous my claim of experience is based on working on Android for less than a year, especially without any other previous programming experience, but I hope it's still clear what I mean.
In the context of the article, it's an end-user feature. Just as having the ability to use anything from a 10" netbook screen to a 6-monitor array is a major feature of PCs that could not be equaled if there were only one or two PC models on the market. Though surely it would be cheaper and easier to develop PC apps if there were only one or two models.
Considering I'm typing this on my phone's physical keyboard, I'm a big fan of the fact that hardware diversity allows me to find a phone that fits the way I want to work.
Considering I'm typing this on my phone's physical keyboard, I'm a big fan of the fact that hardware diversity allows me to find a phone that fits the way I want to work.
>How can something that raises the costs of development be regarded as a feature?
Because it serves the needs of customers better?
Because it serves the needs of customers better?
Fragmentation is not the same thing as support for different hardware capabilities. Fragmentation itself doesn't serve anyone better.
If this fragmentation (or anything else) prevents them from fixing issue 3434 in a timely manner, my application will have to stay on iOS. It's that simple.
Well, since 3+ years is already untimely...
Have had 3434 and scads of other major issues starred since forever. :/ Every once in awhile, a comment will come in on one of them and I'll get excited...only to find that it's another "Me, too! Come on, guys!" post.
Throwing pennies in a fountain making wishes is what it all feels like.
Have had 3434 and scads of other major issues starred since forever. :/ Every once in awhile, a comment will come in on one of them and I'll get excited...only to find that it's another "Me, too! Come on, guys!" post.
Throwing pennies in a fountain making wishes is what it all feels like.
I completely agree with the people who say that old versions of android not getting upgraded is bad.
But this screen size and hardware is different between devices is fragmentation and is bad is a bit bullshit. If that was so bad where are all the articles says OSX is fragmented and hard to develop for, it support a large range of screen sizes (11 -> 27 inch) and both semislow and super fast cpus (and now we are not even talking windows...).
But this screen size and hardware is different between devices is fragmentation and is bad is a bit bullshit. If that was so bad where are all the articles says OSX is fragmented and hard to develop for, it support a large range of screen sizes (11 -> 27 inch) and both semislow and super fast cpus (and now we are not even talking windows...).
There is a big difference in UI design for the mobile devices and for the desktop. On the desktop you can often specify the UI using automatic layout features and the result works. On mobile devices the limited screen estate forces you to weight every pixel and therefore the different screen sizes matter much more. Similar argument can be made about the performance – on desktop Macs the performance differences are not interesting for most regular apps, whereas on the mobile devices even a simple app can tax the machine to the point of not being usable.
Haha this is a great April Fool's article. The old "it's not a bug, it's a feature" joke.
I agree. The "big problem" is the low-ish revenue due to poor app sales figures compared to iOS, and probably nothing else. You can blame it on the device's architecture, I'd rather put the blame on the business itself and the way it works.
"Fragmentation" is an engineering problem that we can iron out. Bad market performance is much more complex and something that's in large part out of our control.
"Fragmentation" is an engineering problem that we can iron out. Bad market performance is much more complex and something that's in large part out of our control.
that low-ish revenue you report is also there in the iphone platform as the overall aggregate iphone app sales masks that data point.
Now can we have a honest conversation instead of using the non-meaningful fragmentation word designed to start a non-conversation..
Its the same problem with code quality..code quality dramatically impacts sellability on both platforms..however we have a diss-connect as on android people want to blame Google Play market rather than the problem and on iphone peopel want to claim its something else because Apple never gets anything wrong..
ITS THE SAME EFFING problem FOLKS ON Both platforms!
Can we please remove our heads from our asses!?
Now can we have a honest conversation instead of using the non-meaningful fragmentation word designed to start a non-conversation..
Its the same problem with code quality..code quality dramatically impacts sellability on both platforms..however we have a diss-connect as on android people want to blame Google Play market rather than the problem and on iphone peopel want to claim its something else because Apple never gets anything wrong..
ITS THE SAME EFFING problem FOLKS ON Both platforms!
Can we please remove our heads from our asses!?
No it's not, read the sales comparisons of apps that have both iOS and Android versions...the difference is quite striking.
The problem may just be that the business model that works on Apple's app store - direct sales - doesn't work as well on Android.
David Edery: "Triple Town did 67% of its iOS revenue on GooglePlay. Confirms what I'd heard: f2p games are probably the way to go on Android."[1]
Chris Pruett: "@djedery Indeed, Wind-up Knight is more profitable on Android than iOS."[2]
[1] https://twitter.com/#!/djedery/status/185800787581091841
[2] https://twitter.com/#!/c_pruett/status/185802890688991232
David Edery: "Triple Town did 67% of its iOS revenue on GooglePlay. Confirms what I'd heard: f2p games are probably the way to go on Android."[1]
Chris Pruett: "@djedery Indeed, Wind-up Knight is more profitable on Android than iOS."[2]
[1] https://twitter.com/#!/djedery/status/185800787581091841
[2] https://twitter.com/#!/c_pruett/status/185802890688991232
We shall see how Google Play affects this. I expect a lift, at least in the short term. Whether GOOG can become an entertainment platform in people's hearts and minds remains to be seen.
Nice try, Google :)
I suppose all the different firewire cables on my macs are a "feature" of apple's fast development.
Either you don't really have a Mac or you've been plugging your hard drives to the video out.
FireWire has had a grand total of two different plugs.
FireWire has had a grand total of two different plugs.
my bad for not clarifying--yes it only has two. I meant to write video out, which has changed repeatedly. I've only owned macs--I love the operating system but think their obsession with dongles is crazy.
Really though, I think people knew the people I was making. So what's up with the downvotes? You don't agree with it, that's cool, just don't vote...
Really though, I think people knew the people I was making. So what's up with the downvotes? You don't agree with it, that's cool, just don't vote...
[deleted]
When I think "fragmentation", device sizes and configurations are the least of my worries, although the tooling around this area is very poor and needs improvement. The real fragmentation issues are things involving bugs which are hard to work around, like
* Froyo having a number of NIO bugs (ByteBuffer.AllocateDirect & selectors) (which were fixed later on) * Samsung GPS driver not filling in Location.getTime() * HTC Desire and others having broken Bluetooth stacks
Or advice from Google like:
"Apache HTTP client has fewer bugs on Eclair and Froyo. It is the best choice for these releases. For Gingerbread and better, HttpURLConnection is the best choice."
I have always found Android and its tools to be extremely buggy. Then take into account you are going to have to maneuver around all of these bugs not for one version of the OS, but essentially every version put out for the past 2 years. Many bugs are from Apache Harmony, a huge pile of turd, which is defunct.
Also, fragmentation comes in other forms entirely, like the Kindle Fire, which does not pass CTS and does not have all of the android APIs (I see the possibility of Google subsidizing a low cost ASUS tablet as a move against this existential threat).
Additionally, the newly published design guidelines are for ICS and above, but most developers will target Froyo-ICS. Its quite a challenge making an app which follows these guidelines if you are also targeting pre-ICS devices. So even the guidelines are "fragmented".
I'm really looking closely at how Windows Phone does. Its becoming more difficult to write non-trivial apps for Android unless you can afford a bunch of phones to test on, or use one of the testing services like Perfecto.
But there is potentially a startup opportunity here. Perhaps someone could create a database that lets you drill down, by API, to see which phones have issues. It would be great if lint hooked into this database and gave me a list of phones to exclude in the market, if I didn't feel like working around them.