Most (but not all) Android phones being produced today support OpenGL 2.0 - even so, there are lots of tricky differences.
The obvious one is different screen sizes and resolutions. This can be a challenge, particularly for 2D games. You need either different versions of artwork, resolution independent artwork (through 9png, vector graphics, or something else), or to accept that your art is going to be stretched on most phones.
Additionally, different combinations of GPU/screen size have vastly different performance characteristics. A phone with a 720p screen might very well have the same GPU as a phone with an 800x480 resolution screen. Guess which one performs better? This requires a lot of testing, as the stereotypical "low end phone" might actually perform better than the latest and greatest with a giant screen.
Phones also differ, and sometimes greatly, based on the graphics chip/driver. HTC phones often don't preserve framebuffers in the way most other manufacturers do.
There are many more: non-po2 textures, compressed texture support, different context preservation behavior based on phone and OS version.
Games may not be the stereotypical application here, but they're a huge part of the market, and Android fragmentation has made developing performant, good looking games much more of a challenge than on iOS.
I'm pretty sure OpenGL ES 2.0 (pedantry: not at all the same standard as OpenGL 2.0) was a platform requirement for everything from Eclair (Android 2.0 -- the Nexus One) forward. I'm sure that factory-new Android 1.x devices still exist in the market somewhere, but you'd be very hard pressed to find one. Note that the original iPhone and 3G didn't do GLES2 either, so the platforms got the support at roughly the same time.
The bit about pixel-perfect art matters to some, I guess. PC game vendors have been doing resolution-independent games for decades now, so it's hardly a killer. But if you have to have it, then you're stuck with the iPhone (not even iOS, obviously, as you'd have to chuck iPad support).
And the rest is just saying that "OpenGL is hard". Yes: if you want to code to precisely the extension support and bug-for-bug quirks of one GPU (presumably the PVR SGX 5xx in your case), then it's easier to support just that phone. Duh. But that seems like bad practice to me. What if Apple goes with Mali or Tegra3 for the iPhone 5?
I'll be the first to criticize Google for not working even harder with manufacturers to standardize Android more or faster, especially when it comes to upgrades. But it's important to remember that iOS only covers a handful of devices at most, and they are all made by the same company, and use 2 or 3 different chips at most.
Any other OS which tries to cover more devices and configurations than that will inherently be less standardized and "harder" for developers, especially in its first few years of existence. There used to be a lot of different GPU manufacturers for PC's out there also 15 years ago.
These sort of things tend to become more standardized after at least a few years have past, and not only the OS is more compatible with different hardware, but there are fewer manufacturers to worry about, too, once the leaders of the market have been set, and the manufacturers themselves work on making their own hardware and drivers more compatible with previous versions once the market is stable.
The author actually says that Android fragmentation is less of a problem than on the web or even on Windows! If that's true, then Android is already doing very well regarding supporting a ton of devices that are still compatible with each other. But again, I still want Google to constantly work hard on making it as small of a problem as possible.
That's what libraries are for. There are some pretty good ones for 2d (Andengine based on Box2d for instance). It saddens me that more developers are not committed to developing/extending gaming platforms and shared code, and instead porting games from other devices piecemeal.
So Android's fragmentation problem isn't that bad for developers if they're used to working on an even worse platform (web developing)? That's a terrible argument. There is always something worse. That doesn't mean Android is any less fragmented.
Android fragmentation is worse than web fragmentation. On the web one only has to test on 4 browsers x two operating systems, as opposed to dozens of phones x several os versions x several carriers.
Well it's also consumer perception. For Android I paid money for the phone itself, for a calling and data plan, and then for the apps (sometimes). So after putting down money and things not working right, yes that angers me.
But for web apps? The browsers are free, the apps are (usually) free, and there is an expectation of approximate user experience on the web. On phones the standard is much higher.
That's at least the way I feel about it (and will be switching to an iPhone away from Nexus S because of all those reasons; my OS X / iOS devices always feel more "real" than my android phone).
I'm not sure the "overblown" fragmentation problem is about the developer. I thought it was about the end user.
Sure it's somewhat difficult to develop and test Android applications due to fragmentation, but I see the bigger problem being the end users with Android devices in their hands that can't run apps because their particular device or their new, but ancient build of Android isn't supported.
What Color? is an example of this. It doesn't work on the Galaxy Nexus. Who knows why. The Netflix app was another example, for at least a while.
And who knows if it will ever be supported, because only $x number of people own that device, which is one of hundreds available worldwide at any given time.
Seems to work fine on my Galaxy Nexus, though I've never heard of it before and maybe support was recently added. And to be fair: this (a camera-integrated "what is this color?" tool for colorblind users) is a really obscure app! The Netflix example is AFAIK wrong; I don't think it was ever "unsupported" in ICS, but maybe I'm misremembering.
Are there any real-world examples? I mean, sure: occasionally you see an app that has bugs on one handset or another, and sometimes those go unfixed. But to pretend that this is a serious problem for "end users" is vastly overstating the case.
We've spent 10+ years on the web trying to educate end users that things will not be pixel perfect across webtv, ie3/4/5/6/7/8/9, netscape 2/3/4, firefox1-12, opera, chrome, safari on linux, mac, windows, on 10"-30" screens. Slowly, over time, it seemed to work.
"This rounded corner on ie7/winxp doesn't look exactly the same as the rounded corner on my iphone4!" isn't the type of complaint I hear from clients any more, but font renderings, aliasing, shape of rounded corners, etc are all things I've had to deal with in the past.
We're now entering mobile devices/tablets, which will bring with it its own version of the same stuff. It was easier to tell someone "that's netscape, this is opera - they're different, and will look a little different*" than it will be to say "this is android, and that's android, but they don't work the same".
> "This rounded corner on ie7/winxp doesn't look exactly the same as the rounded corner on my iphone4!" isn't the type of complaint I hear from clients any more, but font renderings, aliasing, shape of rounded corners, etc are all things I've had to deal with in the past.
Sure it's not an issue if you think you have to support android. When in reality you just have to support the iPhone, and it doesn't have these issues.
Android support is helpful but not neccesary, like supporting IE alongside Firefox a few years ago. Sure people use IE more than any other browser (now Chrome, yes!), but that doesn't mean a lot of IE users are going to use your website in the first place.
IMHO that applies to android today, iPhone users are way more likely to buy your service in the first place so you should focus on them. No need to leave android users hanging, but clearly the platform doesn't warrant anyone's sole focus so much as basic support.
I still hear this kind of stuff all the time. When dealing with clients who I am building applications for it's possible to explain the differences and have them accept those differences. However, if my clients still don't know why things look different in different browser, then it's pretty likely that most other non-technical people don't understand the differences either and I won't have the opportunity to explain things to them. Also, there are a lot of people that still don't even know what browser they use, so any explanation of browser differences is still a few conversations in the future.
I design and support apps for iOS (Tablet and Phone), Android (Tablet and Phone), Blackberry (Tablet and Phone), Windows Phone 7.5, and various J2ME (Nokia s40 etc).
Android is not the very worst one to support (that would be blackberry), but it is the worst within its own ecosystem. As a designer it infuriates me to no end to never know the Dimensions, PPI, or general experience of any given user. It makes any refined UI design nearly impossible. While I can't create great experiences on specific devices, for Android I have to make glorified web apps at best.
If I were a Android customer, I would be irritated that my platform has significantly handicapped my apps.
I'm actually mostly annoyed at my phone manufacturer for not being on top of software most of the time. I finally got ICS for my Dutch Samsung Galaxy S2, but not after a bad update left me with a phone that turned off every hour and had to go to a service center. The service center in turn flashed my phone with a Luxembourg version of the software, which properly upgraded to ICS but I no longer have a "Dutch" phone or the very latest stability upgrade.
The article mentions video - that's directly related to either 3rd party ROMs or phone manufacturers not paying for/getting licenses for MPEG and/or other standards. Google APIs is another - there's various additional requirements that manufacturers have to deal with to get those. There is an alternative BTW to Google's maps - Mapquest (http://developer.mapquest.com/web/products/featured/android-...)
> As a designer it infuriates me to no end to never know the Dimensions, PPI, or general experience of any given user. It makes any refined UI design nearly impossible.
This doesn't make sense to me. Android gives you all the tools you need to scale a UI to different types of screens, so why would not having a set dimension/resolution/PPI value make it hard for design? The added challenge is thinking about how your UI may work gracefully on smaller or larger than expected screens, but those challenges can be overcome as they are on other platforms like the web.
The fragmentation is fairly significant, given that 85% of current Android devices are still running 2.2-2.3.x versions of the Android OS--both of which are now 2 years old.[1]
Four months ago, we were experimenting with a combination of PhoneGap and mobile website versions of an app, and that was an unholy nightmare of bugs--not because of the version of Android, but because of the custom UI that phone manufacturers added on top of the stock OS.
We got three different Android devices (running 2.2, 2.3, and 4.1), and debugging for presentation, rendering, and behavioral issues was pretty painful. Two bugs that I can recall off the top of my head are:
* the "HTC Duplicate Input Bug", where the browser inserted a second <input> or <textarea> element on top of the original element in the DOM when you apply focus to a text input element and bring up the soft keyboard
* issues with heavy caching and cookie management that resulted in failed logins (depending on the user's device) and unpredictable rollout of new versions of CSS and JS
The problem with Android fragmentation is not necessarily that it's spread across the number of devices and versions; it's that the phone manufacturers have incentives to continue using legacy versions of the software (2.2-2.3x) because they have already invested time and resources into building their proprietary UI on top of them.
I think his argument is premature. His app is < 5k installs, he's only targeting phones, he's still using the option menu (i.e. using an old sdk), and his UI is simply an iPhone port.
Just from a UI perspective I'm not sure he has addressed: ActionBarSherlock, black vs. white (or any?) Option Menu icons, portrait/landscape layouts (i.e. sideways keyboards), and multiple layout folders (3x just for tablets).
He's confident now because the app is small & easy. When you get to ~100k installs you start to encounter the niche users and when you're missing something "critical" and unique to them you'll get a lot of 1-star drive-bys...
As he mentioned, it may be overblown unless you're in video. The streaming protocols don't get a lot of love (every 2.x.x version broke different bits of streaming in novel ways) and codecs don't work across devices either.
(Also note other comments here about Color and Netflix apps.)
I'll agree that the web development scene is somewhat "fragmented" but I would argue that Android's fragmentation is not only worse but harder to adjust for.
When coding a website and dealing with different browsers/capabilities/screen sizes I can test all of the different combinations on my laptop. The times when I need to test a site on windows I either get someone else to run QA on it at work or I fire up a remote solution such as http://browserstack.com. The bottom line is I CAN test all the combinations.
Now switch to Android. I'm sorry but emulators are NO EXCUSE for the real thing. I have had code fail in an emulator and then work fine on the device. The emulators are VERY slow and trying to run them on my Macbook Air (4GB RAM) is next to impossible. iOS's Simulator is 100x better. (Emulator != Simulator)
I'm sorry but I would rather write websites all day and have to test on 4 Browsers Across 2 OS's then write one more app for Android.
I disagree that fragmentation is not a problem. I work on the mobile build/test infrastructure at Google, and fragmentation does cause us a lot of extra work. We have to track down and maintain physical phones from each vendor, and then we have to dole out time allotments for tests to run on each phone. (And of course, each model of phone runs a different build of Android for each carrier...) This is annoying because ideally we'd run tests for every affecting change, but there aren't enough phones to do that. (We can and do run the emulator for every change, but the emulator is a very optimistic simulation.)
iOS presents is own challenges; running emulator tests for every change is difficult because the build process is opaque and the emulator only runs on Macs, which we do not use in production.
All in all, the tools that are available to mobile developers are extremely primitive compared to what server-side Java developers get, and wasting time fighting fragmentation isn't exactly helping.
Hmm in your post I read "I work on mobile build/test infrastructure at Google" and "tools that are available to mobile developers are extremely primitive". So what are you waiting for? Pitch your ideas to your (relatively internal) Android team...
Tricky, but not impossible. The same as you would have to learn the API's and general usage patterns of new features, you just have to learn how to use the compatibility package or third party libraries like ActionBarSherlock to take advantage of the most common new features.
That said, I don't fully agree with the OP's argument. Fragmentation is a very real pain in a lot of subtle unexpected areas (mostly UI related).
I think that he means that it is tricky. He doesn't hide this fact, but it is a know fact, and programmers should be award of it and its possible solutions.
I make a living off of Android, and I don't think fragmentation is overblown. Sure, you can make the argument that the PC world has dealt with different screen sizes and hardware specs for a long time, but at least MS was the sole vendor of Windows.
As Android developer you have to deal with myriad of manufacturer and community developed permutations of the OS - TouchWiz, Sense, Cyanogenmod, MIUI to name a few. If you make a widget app like us, you not only have to deal with HTC, Samsung, etc's launcher you have to deal with 3rd party launchers too - ADW, Apex, Launcher Pro, GO, etc.
How about when HTC decides to break multitasking in favor of better battery life?
Personally, I think it's a bit of a double edged sword. A lot of the issues that make Android hard to develop good apps for make it a fun platform, ie the ability to choose whatever launcher or rom you want. That said, you're kidding yourself if you think fragmentation is not a major issue.
The problem with Android fragmentation is the impossibility of most developers to reproduce device-specific bugs. Without physical access to one problematic device it could be very hard or even impossible to debug bugs. There's only so much you can do with the emulator. And most developers don't have access to more than very few devices. If you're not a company, it's hard to invest in all sorts of devices.
I think the fragmentation issue has bigger impacts in software consumption, rather than software production. The fragmentation is really more of a symptom than the problem. That problem is disparate hardware as a result of how device manufacturers compete with each other. Instead of adding any value with useful features (NOTE: the additional battery drain of 4G and lessened security of using NFC are not features), they decide to manufacture devices using cut-rate hardware. The hardware failure rate of Android powered devices is staggering when compared to iOS devices. This hurts the user and it hurts the platform. The user is left with a bad taste in their mouth, which they attribute to "Android's fragmentation problem". Now, I'm not the biggest Apple fan and I love the philosophy behind Android, but I find the crappy hardware a big enough of a pain to deal with that I would rather use a device that's part of a more controlled ecosystem.
I still can't read "The Economist" on Ice Cream Sandwich. I noticed it silently went away the moment I upgraded.
Anecdotal? Yes. But until it is more or less unheard of (especially for an application that "just" renders text and images), there is a fragmentation problem.
"Ice Cream Sandwich" has been available for months.
> "Ice Cream Sandwich" has been available for months.
And only about 5% of phones have it.
Devs have to prioritize. Obviously, power-users are going to be up-to-date, but the vast majority of customers are probably not affected. I would imagine the customers of The Economist on Android are less likely to fit the power-user profile than other apps.
While the fragmentation such as it is really sucks for developers, I do see an upside.
It's a grand experiment with many competing designs, all striving to become the best and biggest (sounds like Osmos ;).
iPhone iterates down a closeted path. Innovation for iphone depends solely on the creativity at Apple. And while that is nothing to sneeze at, if some really left-field neato must-have innovative feature occurs, I think it's going to be found on Android first.
PCs have been doing this for decades without having the OS fragmentation problems. Why ? Because Microsoft allows OEMs to customise the experience while still allowing them the ability to upgrade the core OS.
[+] [-] AntiRush|14 years ago|reply
Most (but not all) Android phones being produced today support OpenGL 2.0 - even so, there are lots of tricky differences.
The obvious one is different screen sizes and resolutions. This can be a challenge, particularly for 2D games. You need either different versions of artwork, resolution independent artwork (through 9png, vector graphics, or something else), or to accept that your art is going to be stretched on most phones.
Additionally, different combinations of GPU/screen size have vastly different performance characteristics. A phone with a 720p screen might very well have the same GPU as a phone with an 800x480 resolution screen. Guess which one performs better? This requires a lot of testing, as the stereotypical "low end phone" might actually perform better than the latest and greatest with a giant screen.
Phones also differ, and sometimes greatly, based on the graphics chip/driver. HTC phones often don't preserve framebuffers in the way most other manufacturers do.
There are many more: non-po2 textures, compressed texture support, different context preservation behavior based on phone and OS version.
Games may not be the stereotypical application here, but they're a huge part of the market, and Android fragmentation has made developing performant, good looking games much more of a challenge than on iOS.
[+] [-] ajross|14 years ago|reply
The bit about pixel-perfect art matters to some, I guess. PC game vendors have been doing resolution-independent games for decades now, so it's hardly a killer. But if you have to have it, then you're stuck with the iPhone (not even iOS, obviously, as you'd have to chuck iPad support).
And the rest is just saying that "OpenGL is hard". Yes: if you want to code to precisely the extension support and bug-for-bug quirks of one GPU (presumably the PVR SGX 5xx in your case), then it's easier to support just that phone. Duh. But that seems like bad practice to me. What if Apple goes with Mali or Tegra3 for the iPhone 5?
[+] [-] nextparadigms|14 years ago|reply
Any other OS which tries to cover more devices and configurations than that will inherently be less standardized and "harder" for developers, especially in its first few years of existence. There used to be a lot of different GPU manufacturers for PC's out there also 15 years ago.
These sort of things tend to become more standardized after at least a few years have past, and not only the OS is more compatible with different hardware, but there are fewer manufacturers to worry about, too, once the leaders of the market have been set, and the manufacturers themselves work on making their own hardware and drivers more compatible with previous versions once the market is stable.
The author actually says that Android fragmentation is less of a problem than on the web or even on Windows! If that's true, then Android is already doing very well regarding supporting a ton of devices that are still compatible with each other. But again, I still want Google to constantly work hard on making it as small of a problem as possible.
[+] [-] methodin|14 years ago|reply
[+] [-] nextstep|14 years ago|reply
[+] [-] rabidsnail|14 years ago|reply
[+] [-] ecoffey|14 years ago|reply
But for web apps? The browsers are free, the apps are (usually) free, and there is an expectation of approximate user experience on the web. On phones the standard is much higher.
That's at least the way I feel about it (and will be switching to an iPhone away from Nexus S because of all those reasons; my OS X / iOS devices always feel more "real" than my android phone).
[+] [-] fragsworth|14 years ago|reply
Did you not pay for your computer itself, an Internet plan, and then for software (sometimes)? How is the Android experience any different?
[+] [-] runjake|14 years ago|reply
Sure it's somewhat difficult to develop and test Android applications due to fragmentation, but I see the bigger problem being the end users with Android devices in their hands that can't run apps because their particular device or their new, but ancient build of Android isn't supported.
What Color? is an example of this. It doesn't work on the Galaxy Nexus. Who knows why. The Netflix app was another example, for at least a while.
And who knows if it will ever be supported, because only $x number of people own that device, which is one of hundreds available worldwide at any given time.
[+] [-] ajross|14 years ago|reply
Seems to work fine on my Galaxy Nexus, though I've never heard of it before and maybe support was recently added. And to be fair: this (a camera-integrated "what is this color?" tool for colorblind users) is a really obscure app! The Netflix example is AFAIK wrong; I don't think it was ever "unsupported" in ICS, but maybe I'm misremembering.
Are there any real-world examples? I mean, sure: occasionally you see an app that has bugs on one handset or another, and sometimes those go unfixed. But to pretend that this is a serious problem for "end users" is vastly overstating the case.
[+] [-] mgkimsal|14 years ago|reply
"This rounded corner on ie7/winxp doesn't look exactly the same as the rounded corner on my iphone4!" isn't the type of complaint I hear from clients any more, but font renderings, aliasing, shape of rounded corners, etc are all things I've had to deal with in the past.
We're now entering mobile devices/tablets, which will bring with it its own version of the same stuff. It was easier to tell someone "that's netscape, this is opera - they're different, and will look a little different*" than it will be to say "this is android, and that's android, but they don't work the same".
[+] [-] pjmlp|14 years ago|reply
I hear this type of stuff all the time.
[+] [-] gauravk92|14 years ago|reply
Android support is helpful but not neccesary, like supporting IE alongside Firefox a few years ago. Sure people use IE more than any other browser (now Chrome, yes!), but that doesn't mean a lot of IE users are going to use your website in the first place.
IMHO that applies to android today, iPhone users are way more likely to buy your service in the first place so you should focus on them. No need to leave android users hanging, but clearly the platform doesn't warrant anyone's sole focus so much as basic support.
[+] [-] markkanof|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] tsunamifury|14 years ago|reply
Android is not the very worst one to support (that would be blackberry), but it is the worst within its own ecosystem. As a designer it infuriates me to no end to never know the Dimensions, PPI, or general experience of any given user. It makes any refined UI design nearly impossible. While I can't create great experiences on specific devices, for Android I have to make glorified web apps at best.
If I were a Android customer, I would be irritated that my platform has significantly handicapped my apps.
[+] [-] joelhaasnoot|14 years ago|reply
The article mentions video - that's directly related to either 3rd party ROMs or phone manufacturers not paying for/getting licenses for MPEG and/or other standards. Google APIs is another - there's various additional requirements that manufacturers have to deal with to get those. There is an alternative BTW to Google's maps - Mapquest (http://developer.mapquest.com/web/products/featured/android-...)
[+] [-] king_jester|14 years ago|reply
This doesn't make sense to me. Android gives you all the tools you need to scale a UI to different types of screens, so why would not having a set dimension/resolution/PPI value make it hard for design? The added challenge is thinking about how your UI may work gracefully on smaller or larger than expected screens, but those challenges can be overcome as they are on other platforms like the web.
[+] [-] daleharvey|14 years ago|reply
[+] [-] guelo|14 years ago|reply
[+] [-] sjhcockrell|14 years ago|reply
Four months ago, we were experimenting with a combination of PhoneGap and mobile website versions of an app, and that was an unholy nightmare of bugs--not because of the version of Android, but because of the custom UI that phone manufacturers added on top of the stock OS.
We got three different Android devices (running 2.2, 2.3, and 4.1), and debugging for presentation, rendering, and behavioral issues was pretty painful. Two bugs that I can recall off the top of my head are:
* the "HTC Duplicate Input Bug", where the browser inserted a second <input> or <textarea> element on top of the original element in the DOM when you apply focus to a text input element and bring up the soft keyboard
* issues with heavy caching and cookie management that resulted in failed logins (depending on the user's device) and unpredictable rollout of new versions of CSS and JS
The problem with Android fragmentation is not necessarily that it's spread across the number of devices and versions; it's that the phone manufacturers have incentives to continue using legacy versions of the software (2.2-2.3x) because they have already invested time and resources into building their proprietary UI on top of them.
[1]: http://developer.android.com/resources/dashboard/platform-ve...
[+] [-] radley|14 years ago|reply
Just from a UI perspective I'm not sure he has addressed: ActionBarSherlock, black vs. white (or any?) Option Menu icons, portrait/landscape layouts (i.e. sideways keyboards), and multiple layout folders (3x just for tablets).
He's confident now because the app is small & easy. When you get to ~100k installs you start to encounter the niche users and when you're missing something "critical" and unique to them you'll get a lot of 1-star drive-bys...
[+] [-] guelo|14 years ago|reply
[+] [-] Terretta|14 years ago|reply
(Also note other comments here about Color and Netflix apps.)
[+] [-] joshstrange|14 years ago|reply
When coding a website and dealing with different browsers/capabilities/screen sizes I can test all of the different combinations on my laptop. The times when I need to test a site on windows I either get someone else to run QA on it at work or I fire up a remote solution such as http://browserstack.com. The bottom line is I CAN test all the combinations.
Now switch to Android. I'm sorry but emulators are NO EXCUSE for the real thing. I have had code fail in an emulator and then work fine on the device. The emulators are VERY slow and trying to run them on my Macbook Air (4GB RAM) is next to impossible. iOS's Simulator is 100x better. (Emulator != Simulator)
I'm sorry but I would rather write websites all day and have to test on 4 Browsers Across 2 OS's then write one more app for Android.
[+] [-] jrockway|14 years ago|reply
iOS presents is own challenges; running emulator tests for every change is difficult because the build process is opaque and the emulator only runs on Macs, which we do not use in production.
All in all, the tools that are available to mobile developers are extremely primitive compared to what server-side Java developers get, and wasting time fighting fragmentation isn't exactly helping.
[+] [-] joelhaasnoot|14 years ago|reply
[+] [-] dshefchik|14 years ago|reply
ummm...what was your argument again?
[+] [-] aguynamedrich|14 years ago|reply
That said, I don't fully agree with the OP's argument. Fragmentation is a very real pain in a lot of subtle unexpected areas (mostly UI related).
[+] [-] ChrisClark|14 years ago|reply
And there are a few tools you can implement to have full backwards compatibility to 2.2, probably even 2.1.
It's not that hard to do at all. I have a lot more trouble supporting IE in web development than I do all the Android versions.
[+] [-] koeselitz|14 years ago|reply
[+] [-] menny|14 years ago|reply
Android dev provides some: http://android-developers.blogspot.com/2010/07/how-to-have-y... And I found some more: http://blog.evendanan.net/2011/04/Backward-compatibility-in-...
[+] [-] mchristoff|14 years ago|reply
As Android developer you have to deal with myriad of manufacturer and community developed permutations of the OS - TouchWiz, Sense, Cyanogenmod, MIUI to name a few. If you make a widget app like us, you not only have to deal with HTC, Samsung, etc's launcher you have to deal with 3rd party launchers too - ADW, Apex, Launcher Pro, GO, etc.
How about when HTC decides to break multitasking in favor of better battery life?
http://www.theverge.com/2012/5/16/3024854/htc-one-x-multitas...
Personally, I think it's a bit of a double edged sword. A lot of the issues that make Android hard to develop good apps for make it a fun platform, ie the ability to choose whatever launcher or rom you want. That said, you're kidding yourself if you think fragmentation is not a major issue.
[+] [-] rdg|14 years ago|reply
[+] [-] nalybuites|14 years ago|reply
[+] [-] fdr|14 years ago|reply
Anecdotal? Yes. But until it is more or less unheard of (especially for an application that "just" renders text and images), there is a fragmentation problem.
"Ice Cream Sandwich" has been available for months.
[+] [-] jcromartie|14 years ago|reply
And only about 5% of phones have it.
Devs have to prioritize. Obviously, power-users are going to be up-to-date, but the vast majority of customers are probably not affected. I would imagine the customers of The Economist on Android are less likely to fit the power-user profile than other apps.
[+] [-] THEM|14 years ago|reply
Price of testing on multiple android devices: Thousands of dollars to purchase new phones without a contract.
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] aiscott|14 years ago|reply
It's a grand experiment with many competing designs, all striving to become the best and biggest (sounds like Osmos ;).
iPhone iterates down a closeted path. Innovation for iphone depends solely on the creativity at Apple. And while that is nothing to sneeze at, if some really left-field neato must-have innovative feature occurs, I think it's going to be found on Android first.
[+] [-] taligent|14 years ago|reply
PCs have been doing this for decades without having the OS fragmentation problems. Why ? Because Microsoft allows OEMs to customise the experience while still allowing them the ability to upgrade the core OS.