Android: Fragmentation? More like Fragmentawesome.
replicaisland.blogspot.com
replicaisland.blogspot.com
In other words: Fragmentation is a bit of a problem on the Android platform.
Sure, your software doesn't crash on any Android hardware. Good for you! But there's a big difference between does not crash and is useable.
Fortunately, your software is also usable on "average" Android hardware. Great! But there's a big difference between usable and useful, and an even bigger difference between useful and elegantly designed.
The problem is least-common-denominator design: You can't assume a hardware keyboard, and you can't assume a software keyboard, and you can't assume multitouch, and you can't assume an orientation sensor, and you apparently can't assume a minimum level of graphics performance. So you design something that runs well on some hardware, but not so well on others, in a way that's not necessarily easy for a potential software customer to understand or anticipate in advance. And you're careful not to accidentally take too much advantage of some hardware feature that isn't widely available, lest you box yourself into a niche.
It's not a really a matter of 'least-common-denominator' design; it's a trade off between how wide of an audience you want to reach and how many features you want to use.
That being said we are extremely excited about the openness of the platform and the features that enables us to build. :)
This is a feat that most Amateur developers cannot afford to pull off. It is, however, a feat that any iPhone developer can manage (there are only a handful of devices)
My fear, with platform fragmentation, isn't for the people who do this for a living (I do, and platform fragmentation is just one of the many problems we already have systems in place to handle) My fear is for the people who want to do it as a hobby.
So for us professional folks, the platform fragmentation issue is very over-blown. But if you're a one-man shop who wants to make some mobile software in his/her spare time (for which there is a thriving market on the iPhone) then this is actually a huge hurdle to get over.
Sure, if you have access to all the Android devices, you might or might not have to make code changes to support specific handsets (yet). But if you can't get your hands on every Android device...and you want to develop a paid app in the evenings, get ready for a deluge of angry users for whom your application is just too slow to work. Further, these will be problems you won't be able to debug _until_ you get that email from an angry user.
But wait, isn't that the entire point of a standardized platform? The ability to guarantee some minimum of user experience quality?
The splintering problem is real, and add it to the propensity for OEMs to add all kinds of (mostly poorly thought out) UI tweaks to Android, and what you have is something that really shouldn't be advertised under a single brand name.
The Android API is indeed standardized accross all platforms. Also, what's standardized is the java methods you use and the libraries provided.
Making a game, usually means you're rendering to hardware and you have to handle things like screen resizing, etc, yourself.
However, there isn't a standard UI definition yet like the iPhone has. If that's what you mean.
But IMHO this is a pretty narrow definition of cross-platform success. In this case shipping this wonderful cross-platform package on multiple phones results in many customers being unable to play - either due to excessive poor performance or just plain lack of input devices.
So, what's a dev to do at this point? Well, that's easy, start writing device-specific code. That phone has a convoluted direction pad that doesn't work for the game? Well, switch to something else. This one has a poor graphics chip? Let's gracefully degrade quality to get some speed.
But wait, we just nuked the primary benefit of standardization!
This is my original point: when you standardize it can't just be half-assed, and that's what I see on Android right now.
So, you end up having to write various rendering engines with a lot of conditionals and the ability to change the setup via a menu.
Now, add to this a crap-load of varying input devices, single/multi touch screen, and you've got the same problem that PC game makers have but worse.
It's not the API that needs to be standardized, but the hardware. The only reason that the iphone doesn't have this problem is because they only have 2 or 3 devices and they're all pretty standard hardware-wise.
Most console game makers site the reason of developing for a console is the standardized hardware. However, you get lock-in with that. So, it really is a fundamental flaw/problem.
Beside, that's why programming languages have 'if/else'.
Yes, you have to do a lot of testing on your end, but you're not stuck to one platform.
Also, if you want to program your run of the mill program, then the standardized API is more than capable. But like I said, if you're making a (high-performance) game, you have to sacrifice things, this is true for ALL platforms.