Before you read on through this blog post, check out this post on Slashdot from a disgruntled Android programmer who is fed up with having to maintain multiple different code paths to deal with the out of control fragmentation in the Android market.

First, as great as Java may be, it has never been, nor will it ever be, the "write-once-run-anywhere" language that its original creators envisioned. So that's already 1 strike against keeping fragmentation at bay - developers might be writing Java code, but the underlying JVM and the hardware availability of Java method calls is going to vary from device to device. With Android, we have a completely uncontrolled ecosystem. Any hardware manufacturer can run Android, and they can do whatever they feel like doing with the hardware and whatever else they feel like doing. This means that now every Android developer has to worry about unforeseen resolutions and screen sizes and unknown capabilities of the underlying device. In the case of the Slashdot poster, you also have to worry about whether or not the device on which your app is running can do hardware accelerated graphics. In the short time that Android has been out, Google has released multiple new versions with widely varying capabilities, and dozens of potential hardware targets have been introduced - each with varying size, shape, capabilities, and vendor customizations.

In short, ensuring that your Android app works on all Android devices and has a consistent look, feel, and response is quite simply a pain in the ass.

You're probably thinking something along the lines of, "Suck it up Kevin... that's life. That's reality. Everybody has to deal with this kind of fragmentation." Actually, no, we don't. That's just what the apologists want us to think. For the first time in Microsoft's history, they are actually making demands of hardware manufacturers who intend to support Windows Phone 7 Series. There are only two possible screen size and resolution combinations to worry about - only one of which will be available at launch. Secondly, Microsoft has dictated a set of minimum requirements. If the vendor wants to put WP7 on their device, it must meet a set of minimum criteria that include speed, performance, and available platform features like a GPS, WiFi, etc. Microsoft have always been (for better or worse) the kings of backwards compatibility. You can absolutely guarantee that code written for v1.0 of a WP7 device will work (somehow) on a v2.0 device. You cannot guarantee this for Android and even Google has simply skipped trying to make multiple versions of their own apps (e.g. Twitter) because of the pain in the ass of supporting all the possible fragments and forks.

The reason I'm comparing WP7 and Android is because both of these are operating systems with multiple possible hardware vendors. Apple has (essentially) no fragmentation because they own the OS, they own the SDK, and they own the hardware. The only real fragmentation they have introduced is that iPhone apps not written to be iPad-aware look like ass on the iPad - but they still work.

Going forward, if a client asks me for a mobile application I am going to build it using WP7 and the iPhone. If they demand that I build it for Android, I will give them an hour-long lecture for why I don't like that idea but hey, its their money - if they want to pay me 3 times to deal with all the different target environments for Android as opposed to paying me once to build one iPhone app or once to build one WP7 app, that's up to them.

I know you're all going to flame me for this, but as of yet I still have not seen one single shred of evidence that makes me think I can make any kind of decent money or reach any kind of large market penetration by putting an app on Android. I can get vastly more people, with a vastly better experience (both developer and user), hitting iPhone and then WP7 and then supporting the straggler Android users with a mobile-enabled website.