That's not to say it was playable on all of them--the Covia SmartQ5, for example, has no keyboard, trackball, or even orientation sensors, and you have to use a stylus on the screen (it also has no GPU so the game runs extremely slowly). And some devices (like the LG Eve) have directional pads that are really poor for games.
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.
You can target specific hardware features (keypad, touchscreen, etc.) in the package manifest. The Android Market uses this to filter out apps that can't be run on your phone.
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.
The Android Market filters out apps that are incompatible with your device, sure if you have a direct link you can install those apps anyway but then that's your problem.
I can deal with hardware fragmentation, but I am still concerned with software fragmentation. For instance, we (Bump) have different contacts code for Android 1.x, Android 2.x (yes they were supposed to be compatible), and HTC. Bump is not stable on several devices that have changed the contacts subsystem but that we do not have time to support individually (and we can't compile to install on only a subset of known working devices). And I am sure there are problems on handsets we don't know about (there seems to be a new Android handset that we have never heard of on our servers every week). This may be a bigger problem for us since we are so tied to the contacts database and it seems to be a popular subsystem to change but an unpopular one to developers. In the end it means more time bug fixing than feature developing which is too bad.
That being said we are extremely excited about the openness of the platform and the features that enables us to build. :)
The fears about Android fragmentation are, in some cases, overblown. The point that concerns me is that this guy has, or has gotten his hands, on every one of those Android devices.
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.
> "The cool thing is, Replica Island ran on all of them without complaint. That's not to say it was playable on all of them"
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.
No, a game is an entirely different beast.
Specially when using OpenGL. You start breaking things when you don't use the higher level classes and functions.
Meaning, the lower you get, the more you'll have to write code to support different platforms.
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.
Yes, yes, I get the point about not having to write a huge amount of code to account for multiple platforms because of, say, differing levels of OpenGL support.
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.
Well, that is a fundamental problem, not a problem specific to Android.
For years, pc game makers have complained about the costs of developing for PC due to varying support from graphic cards.
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.
A good point. Amateur developers can't afford multiple devices to test on (Android), but they also can't afford to be rejected indefinitely (Apple). So really, there is no good platform for developing mobile games on.
Saw the author of Replica Island talk at Google IO. He's worked for nintendo among other handheld companies and really knows his stuff. He works for Google now and developed Replica Island as his 20% project. I'm glad that his software runs well on all the various android capable devices because if he can't get it portable, chances are not many can. One thing not mentioned in this particular article is the fact that he's not only open sourcing replica island but also the engine he's developed to create it, so it should make game development easier on the rest of us.
The idea that the iPhone platform doesn't suffer from "fragmentation" is wrong, it does and it's getting worse. Developers already have to deal with iPhone 3Gs, iPhone orig, iPod touch, and now the iPad. I'm sure there will be many more devices coming down the pike over the years, each with different capabilities.
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.