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?
There are some new devices (I'm looking at a Huawei M835 running 2.1) that don't have 2.0 support.
As for "OpenGL is hard" - I think a major point here is that Apple has made it far less so. Because of their extreme curation of devices (re: only Apple produced devices), and the ease of software updates (well over 30% of phones are upgraded to the latest iOS version [1], with > 80% on a 5.x version [2]), iOS has continued to be a remarkable homogenous platform.
As far as Apple choosing a new graphics chip for the new device, it's certainly possible. With iOS, though, you can support a known list of devices and have 100% coverage rate. On Android you either have to whitelist phones (and therefore exclude users), or try to do feature detection at runtime to enable the correct codepaths.
It's deeper than "OpenGL is hard." Right out of the gate, you are hit with the one-two punch of different texture compression formats being supported on different devices combined with a maximum APK size on Google's store. The only standard Android texture format with compression is ETC which doesn't support alpha. So right at square one, if you want to use compressed textures for maximum performance and resolution, you have to release 3 separate APK's with a different supports-OpenGL-texture tag in each manifest. One for DXT, one for PVRTC, and one for ATC. Or dynamically download megabytes of textures after detecting which GPU you are running on.
That's a sharp contrast with iOS's unified, simple developer story: all PVRTC without any maximum app size.
That's not iOS's story, it's Imagination Technologies' story. The story from Apple will change the moment they ship a device on someone else's GPU. If this is something you expect to rely on, you're in the position of someone writing Altivec code in 2005.
But yes: texture compression formats and hardware support are a terrible, terrible mess. Happily I believe the early patents on S3TC are set to expire soon.
A minor addition: Android supports OpenGL ES 2.0 since Version 2.0, but JNI bindings to access the library from Java code are only available since Android 2.2 (API Level 8).
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.
Agreed. In my experience, there are so many points of change/breakage that fragmentation is absolutely a problem if you're doing anything remotely complicated. We do voice and use SSL - both get broken from time to time on a subset of devices for a multitude of reasons...a phone manufacturer re-introduces a bug they fixed two full releases ago, an OS update adds incorrect proxies that break SSL, some models introduce flaky over-sensitive touchscreens or enable a vibrate feature that's a bit off-the-charts, and so on. Troubleshooting these issues take time & serious investigative work (not to mention awesome, helpful users), too. And you can't anticipate what's going to break ahead of time the way you can with iOS - you don't have access to carrier updates across the board and you can't possibly test every device/OS combo or upgrade case. You could take, for instance, ICS straight from Google, but that's missing all the breakage that gets added from the carriers and phone manufacturers...you basically have to await the screams, then apply the tourniquet. There's not much "preventative care" available.
One of the great things Google has done to help in this regard (whether intended or not) is the ability to push out releases to customers within minutes without review. While there are many reasons this lack of review can be dangerous for users, from the development side, it's really fantastic to be able to push out fixes to affected users as soon as you've got them implemented and tested. I.e., at least you can apply pressure to that gaping wound quickly.
Very much looking forward to what the Motorola acquisition has in store and am staying optimistic--one thing I've noticed is that the "dominant handset" changes fast - for us, sometimes, in a matter of months. And when we have a pretty stable dominant handset, life gets easier (the HTC era and the calm before the ICS storm was kind of nice). If a stable, Google-controlled and well-tested Motorola phone becomes the dominant for a significant amount of time, this has the potential to be a very good thing for developers.
I know, right? I'm going through the list of issues that happen for Android, and these aren't common PC issues. Resolution issues and render capabilities per screen size? Games pick resolutions and settings dynamically for best performance. We crossed these bridges long ago.
But at any rate, it seems like the OP is trying to equivocate "well it's natural when you do things like this", but I'm not buying it. When your direct competitor doesn't have that problem, you can't wave it away by saying "it's inherent in the model".
iOS is not a direct competitor of Android.
Apple is selling iOS devices.
Google is distributing the Android platform to hardware manufacturers so they can sell mobile/connected devices.
So yes, there is no way that Android hardware & software fragmentation is going away.
Just like there is no way that web browsers fragmentation is going away (hello HTML5 moving standard!).
I'm also pretty sure that iOS fragmentation will become more and more important (new iPhone screen... Apple TV ...).
I disagree. I would even say that it is as least as easy to support most Android-based devices than it is to support most Hardware running Windows.
In both platforms you run into very little issues for most apps, and you need to add support for lot's of different configurations if you write on the system level (Game developers can tell you a tale or two about this).
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.
You're slipping your terminology here and achieving some pretty clever spin: It's only four browsers if you don't care about Opera users. It's only two OSes if you don't care about Linux users. If that's your standard for support, then why not look solely at the successful Android devices, which takes you from "dozens" of handsets to maybe seven at most, which is less than the web world.
And of course the 4/2 argument is bunk anyway. Web developers test ever major version of every browser (especially with IE) and every version of every OS. So for example it's {XP,Vista,7} cross {ChromeN,ChromeN-1,IE7,IE8,IE9,FirefoxN,FirefoxN-1} plus {Lion,Snow Leopard,Leopard} cross {Safari,ChromeN,ChromeN-1,FirefoxN,FirefoxN-1}, etc...
You can't have your argument both ways, basically: either the small market platform variants matter or they don't. If they don't, Android support is easier than the web by a significant margin.
I disagree. Testing is STILL much easier for web development, the android emulators are no replacement for the real thing. Yeah, if you want to give me the top 7 Android phones then yes, development becomes easier (I'm sorry but still no where near as "easy" as it is in the world of web development). We normally will test Win/OSX and the latest FF+Chrome and then IE7/IE8/IE9/Soon-IE10. This in total means testing 6 different combos (No IE on OS X and only test FF/Chrome in one OS). I might throw the site in safari just to double check but since it runs on webkit I usually can trust that if it works in Chrome it will work in Safari.
At the end of the day we have to much less checking in web development than we do in mobile because while browsers are different that are more alike than they are different. That cannot be said for Android/iOS, they differ down to their very core and most cross-platform attempts fall hopelessly short of a usable app.
This seems to be a digression. The point isn't that the "task" of development is easier than web development. Of course it's not, that's ridiculous. It might be done with fancy Java IDEs, but it's still embedded systems development on physically disjoint hardware.
The point was that the added cost to development due to platform incompatibilities is less than it is in the web world. And I think that's largely inarguable. Where is the list of Android incompatibilities that is anywhere near as complicated or exhaustive as http://caniuse.com for example? People in this thread are having a lot of trouble coming up with any specifics at all, in fact. Mostly just a list of apps that break somewhere; no one seems to actually remember any real bugs or workarounds.
Most people can update their desktop browser for free at any time. Most (85%) of the Android users out there are stuck on something <= 2.3.
And it depends on your audience. For instance, if you're Reddit (or are targeting the Reddit users) you're looking at 7% on IE, and 2% on Opera. You can practically ignore those browsers in that case.
Most people could update their browser for free but that doesn't mean that they will update it. I regularly encounter Firefox 3.x users. Fortunately, Firefox 3.x is still a decent browser in terms of standards support but it certainly isn't anywhere near the latest available version.
I bet the Reddit crowd are almost all up-to-date with whatever browser they are running. A stodgy enterprise or gov't office might mandate a certain outdated version for internal apps. I'd bet that a small slice of the vast number of websites out there actually target the average user. The ones that do are likely generic portal ("start page") sites, stores with broad appeal (Amazon, Target, B&N), or public services that everybody would access.
And all of the mobile browsers with their different operating systems. And what purpose would testing an app on different carriers have? The carriers have no impact on how well an app runs, whatsoever.
> The carriers have no impact on how well an app runs, whatsoever.
Not true. Each carrier has their own build of the OS, and they have different sets of bugs. For example, on one of the Samsung phones (I don't remember which one) on one carrier there's a loopback interface, and on another carrier there is none.
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).
In a strict sense I have a ton of different browser options on the same piece of hardware, so if one app doesn't work in Safari say, I can use Chrome or FF. Annoying? Yes, but not world shattering. In a sense you're correct, I've had to invest money to even get to the browser, but I think this difference is more emotional / psychology than anything else.
In a sense the "browser" is a different part of the overall experience.
I know that I've become accustomed to have different expectations of web apps, because they are web apps.
I feel like when it comes to more native apps you have fewer excuses for something being wonky or broken.
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.
It's tough to tell if you are talking specifically about web apps for browsers or the platforms themselves. But in either case your comment is short sighted. Android has over 50% of smartphone market share, and that's only going to increase. Android support and Android versions of apps should be standard for companies and startups going forward.
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'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.
Chrome (doesn't work on pre-ICS).
Grand Theft Auto 3 (and most games - don't work on particular devices due to graphics).
Firefox Native (only supports ARMv6 devices in unofficial builds)
The Chrome bit misses the point entirely. Of course some software requires the latest version of the OS, if it didn't, there would have been no need to release the new version of the platform. You might as well talk about how terribly fragmented iOS is because Siri doesn't work on the iPhone 4.
The GPU thing is legitimate. If you let the market differentiate on graphics performance then software vendors will choose to optimize their platform compatibility in ways that don't include everyone. That's "fragmentation", though I'm hard pressed to see how you avoid it without making everyone code to a single core SGX 540 like iOS does.
And Firefox ships an app that doesn't support the native ABI of the platform (which, to be clear: has a slow ABI precisely to avoid fragmentation. iOS has the same backwards-compatible floating point issue, btw). Again, I don't see how preventing software vendors from making these decisions is helping anyone.
You can't expect that a game with 3D graphics will run on some random 50$ device. If you want 3D graphics on your mobile device, then you'll have to pay for adequate hardware. (like you do for your PC if you want to run Crysis 2 or something like that)
Prior to a few days ago, it was incompatible with the Galaxy Nexus. Upon visiting it now, it says its compatible.
The NetFlix example was not specifically referring to the Galaxy Nexus or ICS. Upon its initial launch it was only compatible with selected devices.
What Color? may be an "obscure" app, but like I said, it's a case example of what I run into time and time again. And that's where I see the bulk of the fragmentation problem (however large the fragmentation problem is).
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.
I've been told the concept of scaling a UI is akin to the concept of "write once, run anywhere".
That is, it works fine in theory. It just hasn't ever worked as advertised in reality. And trying has often generated more pain than it's saved.
It's worth noting that much of modern web design moved to a place of fixed minimum widths and white-space taking up the remainder. Responsive design promises to change that a bit toward scaling UI, but thus far is just a mechanism by which designers can incorporate a few hand-tuned minimum-width variants.
Right from the start Android has been designed with a form of Responsive Design. With scalable XML layouts, and selectors to choose which layout is loaded for different DPI devices, one could argue that even early versions of Android are at least as design-friendly as modern HTML5.
That's not to say there aren't challenges. But the whole point of Android was always to create an industry standard for a wide range of devices. This requires - by definition - support for a variety of screen sizes, DPIs, hardware features, etc. When most people talk about fragmentation as a negative point of Android, they're forgetting what Android is. A common platform, running on an unlimited number of devices. That's by design, not accident.
Sencha touch does scalable UI across tablet and phone form factors. They even resize controls so they have the same physical dimensions on different dpi screens, and this is all in the browser. I'm sure when you go native the possibilities only increase.
The reality of the matter is, the more you scale and stretch, the less you actually design for any given sized platform.
Compare a Galaxy Note to a Droid Razr. They have different sizes, dimensions, pixel densities and various other factors. The UI doesn't just 'stretch' and fix all that. It stretches and looks terrible, feels too large or too small on some devices, and makes fonts et al a mess.
Then throw in a Galaxy Tab, a Kindle, and a more tablet/phone 'tweeners'. Its a total mess. Then throw in operating system versioning and various hardware support and you see why many developers build for iOS first, then consider an Android app.
Edit: I support roughly 200 apps multiplied across all platforms on 20+ app stores. (Roughly 1000 app builds). I see more problems that your average developer sees.
I've commented on this before, but I am a soft keyboard hater. I have a hard keyboard on my phone and tablet, and won't buy a device without the option.
I'm incredibly glad that Android doesn't go with the dogmatic 'our choice is the best choice' approach. It means I can use things as I want them, not as Google wants me to.
precisely. people like choice. some designers wish it weren't so, that we would just all get in line with their "one true design", but people like choice. that's why there are dozens to hundreds of models of tv, car, dishwasher, shaver, ice cream maker, flashlight, battery, dvd player, chocolate bar, and yes, smart phone.
this whole "fragmentation is a problem" argument falls on this one point alone. fragmentation isn't a problem, its a fact. as a pro android dev for a few years now, android is resoundingly the best sdk/os that I've ever used for mitigating such an insanely diverse set of hardware (tv, watch, dumb phone, smartphone, tablet, laptop, no problem)
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...
It usually takes the market a month or two to add new devices to the list. By that time you'll already be nailed by users of a popular new device with an odd screen. We went through that with the Galaxy Note. (Our solution was to express ship one via Amazon.)
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 don't know how to put this more polite, but if those are the only fragmentation issues he's had on Android, his applications are either fairly simple or they just don't have much users yet.
I don't have an opinion on whether it's worse on iOS (prolly not) or Windows, but it sure is a pain.
Couldn't agree with this more. Once a bunch of people start using your Android app you will get buried under support issues. The company I wrote some apps for will email me all the time saying X device on Y.Z version of Android doesn't work... Most of the time it's just a dead end. Unless I get one of those phones in my hands to test it or if it is spitting out an error code that I know how to fix then there is no easy way to debug the problem. It's frustrating as a developer because I WANT to provide the best experience in my mobile apps but that is a very hard to do as the Android platform seems to be in a constant state of flux with countless new devices hitting stores all the time.
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...
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.
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.
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 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.
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.
This is a statement of the fact that seems reasonable.
> 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.
This is a justification I entirely agree with. It doesn't mean that there isn't a fragmentation problem that annoys customers.
I understand why this is, there was never to be doubt about it. Just because it is understandable doesn't get to the heart of my disagreement with the headline: there is a fragmentation problem.
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.
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.