Actually, the Android SDK makes it supremely easy to build applications that are built specifically for different types of devices with minimal effort. The implemented separation of XML resources, combined with the ability to further refine/subdivide resources based on phone capabilities, without having to write any code to make the choices at runtime, is incredibly useful and powerful.
For a simple example, let's say I want to optimize my application's interface layout for whether the phone is in portrait or landscape mode. I simply make two copies of the layout definition and place them in specially-named resource folders, like such:
res/
layout/
main.xml # basic layout
layout-port/
main.xml # optimized for portrait mode
layout-land/
main.xml # optimized for landscape mode
Then all my application needs to do to load the layout is:
setContentView.(R.layout.main);
Android then takes care of loading the appropriate layout element on the fly based on the device's capabilities and state. All I have to do is include optimized versions of the layout for whatever I think in important.
This capability not only covers screen orientation, but screen resolution, screen DPI, touch versus stylus input, hardware or software keyboard, and more [1]. And it all comes basically for "free" because my actual code doesn't have to know about any of it; it just asks for the base resource, and Android does all the selection for me.
So yes, running on lots of devices is part of Android's plan, and they've been working from day 1 to mitigate all of the problems inherent with targeting a divergent platform, and it works. So yes, Android will "scale" to any number of devices, and it's trivial for developers to stay on top of everything if they use the SDK the way it was designed.
All of this is great, and very informative, but it will make Mac software developers and critics -- guys like John Gruber -- laugh and laugh.
The problem with this analysis is that it embodies the Java Desktop Fallacy -- the idea that the primary problem with getting your application to work on every hardware platform is getting the code to compile and the libraries to load. Sun once thought like this. They built a cross-platform set of libraries and released them to the world. They were dutifully ported to every hardware platform. They still work. But Java desktop applications sank into the swamp and died, because the average Java application didn't act quite like a Mac app, or quite like a Windows app. It looked and acted like a crappy compromise, built by someone who was jack of all trades and master of none.
The problem with getting your app to work with or without a multitouch screen, or a built-in accelerometer, or a hardware keyboard, is that an app designed for a multitouch screen is a completely different beast. Making the iPhone's photo album software work on a device without the iPhone screen would require a complete redesign of the app -- you don't have pinch-to-expand, you might not have the same smooth scrolling when the user waves their fingers across the screen. But maybe you can mitigate those missing features by designing some shortcuts for the handy hardware keyboard. But -- oops -- some phones don't have that keyboard, so now you need to design one app for multitouch, one app for single-touch but no keyboard, one app for single-touch with a keyboard...
If you have the time and the budget you can just design eight separate apps for eight separate combinations of hardware and sell them all. And if you're lucky, and Android is that good, you might not need eight times as many coders to pull that off. But you might still need 8x the design budget, and/or 8x the QA budget. If you're not careful you'll need 8x the marketing budget. So there's an inevitable pressure to try the typical strategy: design one app, with one name, aimed at the lowest common denominator of hardware. Or design an app that runs great on the hardware used by one-eighth of the market, but looks kind of crappy to the other seven-eighths of the market. And the Windows Mobile folks have seen the result of that approach: At any moment, a team of Apple developers can come along and wipe the floor with your reputation.
I understand, and agree with your overall point, and trust me when I say I'm not a Google fanboy or Apple-hater. But I honestly can't imagine any smartphone being released in the future without a proper touchscreen. It's become such an integral part of the smartphone experience, and as you said, completely changes the way a user can interact with a device or an application.
The rest of the divergence in hardware is not a total gamechanger though: the screen resolution/DPI, screen orientation, etc. Those aren't gamechangers like a touchscreen is, and touchscreens are here to stay anyways.
If devices like the G1 and iPhone can sell with a great multitouch screen for $100, then there's no point in selling a smartphone without one, and a consumer would be stupid (IMO) to pay for one without it.
So if we take the touchscreen as a done-deal, then everything else divergent is a non-issue. Android makes it a piece of cake to optimize for them, without having to redesign or rewrite your entire application. And at that point, the variety of hardware is your friend, helping to increase your potential market.
(Replying to myself because I don't have time to wait for a stupid AI to give me a reply link.)
If it's true that most future phones will be so much like the iPhone hardware that the differences in software design are moot... Why is Google trying to proclaim that being able to run on all kinds of hardware is some sort of great advantage?
This is a rhetorical question, BTW. I don't think that Google is being stupid. I think they know what they're doing, and if I were their PR guy I'd probably say the same thing. But I'm not, so I can afford to chuckle out loud. :)
One thing to remember about Google is that their core business is promotion. It doesn't matter, ultimately, if a fight promoter's boxers win or lose. What matters is that they fill the arena and the promoter gets a big cut of the ticket sales. If Google gets a piece of the action every time some poor hardware company puts out an "iPhone killer", that will be a "scalable business".
For a simple example, let's say I want to optimize my application's interface layout for whether the phone is in portrait or landscape mode. I simply make two copies of the layout definition and place them in specially-named resource folders, like such:
Then all my application needs to do to load the layout is: Android then takes care of loading the appropriate layout element on the fly based on the device's capabilities and state. All I have to do is include optimized versions of the layout for whatever I think in important.This capability not only covers screen orientation, but screen resolution, screen DPI, touch versus stylus input, hardware or software keyboard, and more [1]. And it all comes basically for "free" because my actual code doesn't have to know about any of it; it just asks for the base resource, and Android does all the selection for me.
So yes, running on lots of devices is part of Android's plan, and they've been working from day 1 to mitigate all of the problems inherent with targeting a divergent platform, and it works. So yes, Android will "scale" to any number of devices, and it's trivial for developers to stay on top of everything if they use the SDK the way it was designed.
[1] http://developer.android.com/guide/topics/resources/resource...