Of late it seems to have become fashionable among tech writers to complain about the "fragmentation" of Android hardware, and to blame this for perceived weaknesses in the platform, or to explain away their preference for something else. With several screen sizes, input methods, and UI customizations available, these writers say, Android developers face the insurmountable obstacle of rewriting their code for each new device running the OS.
Take, for example, Crunchgear's John Biggs, who's entirely typical of the tech pundit conventional wisdom. In a post on the size of Apple's App Store, he claims:
In Android's case you have multiple "branches" of the OS for multiple devices. HTC and Motorola have their own UI tweaks and these branches for programmers to recompile for multiple devices. This, obviously, is a big issue for mom and pop shops run by a few developers and even worse for the 14-year-olds out there building apps in their basements.Yeah, all that recompiling would be a real hassle--if it were true. It's not, any more than I have to get a special version of every Windows program to work with my specific model Thinkpad. In fact, the "fragmentation" claim is a myth, and one that's frankly idiotic if you think about it at all. To understand why, let's take a detour into programming metaphor.
As much as anything else, programming is based on metaphors of nested abstractions. Take your browser, for example. The programmers of Firefox don't have to write code that manually changes the electrical current in your network cable or wireless card. Instead, they can take advantage of the layers in the TCP/IP stack and write at a higher level of abstraction--using concepts like packets and ports. Even better, if you're writing a Firefox plugin, you can build on their work at a higher level of abstraction: HTTP page requests. These high-level program calls get translated down through the layers until, eventually, some code somewhere takes care of the actual electrical signaling. But for the programmer, all that is abstracted away. Abstraction is the miracle that makes increasingly complex software development possible.
Programming for Android is no different. In fact, abstraction is a major feature of the platform. Almost all Android software is written in Java (which was originally pitched to programmers as a highly-abstracted, cross-platform language) and compiled to a virtual machine instead directly to ARM code. That's why you can actually run Android applications on Ubuntu without recompilation. Technically, they're hardware-independent by design (the downside being that execution speed--until Google adds Just-In-Time compilation to the Dalvik VM--is relatively sluggish).
Even when it comes to interacting with hardware like the screen or input devices, Android provides libraries and abstractions to handle this kind of thing. One platform has a trackball while another has a d-pad? To an Android program, they both look like identical directional commands. Different screen sizes? There's no need to recompile: programs just ask for a resolution and adjust to fit, or use the platform's excellent XML-based layout kit and let the OS scale UI elements to fit ("wrap_content" and "fill_parent" attributes, combined with a RelativeLayout, can do impressive things). Again, this isn't a new idea. Hardware abstraction layers and flexible layout tools are a given on every modern OS--you didn't think developers wrote windowing and display code all over again for every video card on the market, did you? Of course not.
I'm no big-time developer on par with something like Twidroid or ShopSavvy, but I've had no reports that Underground is having problems running on different Android devices. And I'm not aware of any developer who's complaining about having to compile a completely new build in order to run on new Android devices. They may be fixing isolated problems (cameras in particular can be tricky), or adding code to take full advantage of features like the Motorola Droid's high-res screen. But for 99% of applications, and 99% of developers, it doesn't even enter the picture. Given the design of Android's abstraction layer, the fragmentation myth makes no sense at all. There's no evidence for it. It's literally something that the pundit community just invented out of thin air.
The irony of this myth, of course, is in the rhetorical strategy behind its deployment. When Biggs and his fellow tech pundits typically evoke the "fragmentation" of Android, it's usually in contrast to development for the iPhone, which supposedly has only one hardware configuration to target. Nothing could be further from the truth: after all, the iPod Touch (which accesses the same software as the iPhones) does not have a camera or GPS (the original iPhone also lacked GPS functionality). The iPhone 3GS exposes several hardware features missing from the other models, including video recording, digital compass, MMS, and better 3D hardware. And among the entire range of products connected to Apple's application store, there are at least three variations in CPU speed and architecture.
The iPhone is hardly unified--indeed, it's split by the most of the same distinctions bemoaned on Android, and they're solved by developers in exactly the same way: a robust hardware abstraction layer and careful, defensive programming. To claim fragmentation in either case would be absurd. But for the tech punditry to make that cognitive leap, they'd have to know what they were talking about. If the current state of affairs is any indication, there's little chance of that happening.
Update: In a hilarious coda to this, one of Wired's front-page articles this morning is "Android's Rapid Growth Has Some Developers Worried." "Some" developers, apparently, means three people from two companies, one of which explains in comments that he was misquoted and that "I honestly haven't had a lot of trouble with the fragmentation issue on Android, apart from some differences in the way Android 2.0 handles font sizes vs. earlier versions."
Tech writers: hacks, plain and simple.