Cue Inigo Montoya: "You keep using that word. I do not think it means what you think it means."

And even if you ignore the poor choice of words and the inane anti-iPhone spin (what, the iPhone OS won't run on products besides iPhones? I'm typing on the iMac that disproves that point!) what I see here is Google trying to put a positive spin on one of their platform's big problems: Android not only can run on a thousand kinds of hardware, but that appears to be the official plan. Some of that hardware will have physical keyboards. Some of it will not. Some of that hardware will have screens the size of a dinner plate. Some will not. The result is a loss of coherency: What kind of hardware is an Android app for? What is Android for?

If you build an Android app, you have to decide if you'll optimize it for a physical keyboard on the long edge, or a physical keyboard on the short edge, or a software keyboard. You'll have to decide how much of the screen you can take up with your control panel. You can't optimize for everything at once.

The likely outcome is that you'll have to support your Android software on a divergent set of hardware, and you'll inevitably disappoint a subset of your customers. If the customer base breaks into thirds and you can only please one-third at a time, you will routinely disappoint a majority of the customer base no matter what you do.

The fact that the iPhone has one consistent hardware platform is a big advantage for Apple. The newest iPhone OS runs great on my two-year-old original-edition iPhone. The phone is getting better by the month: The interface works better, the crashes are fewer. This is presumably because Apple's engineering team can focus on refining the current platform rather than on porting their OS to a dozen different platforms.

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

    setContentView.(R.layout.main);

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...

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.

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.

That's all I was trying to get at.

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".

I'm more interested in something that's free and open because I'd rather see a big advantage for consumers, not for Apple:-)

Ok, so Apple's approach does have its strengths, but phones are not one-size-fits-all devices.

I'm happy to have Apple with their share of the market, turning out cool products that push the envelope. That makes things better for everyone. I would be a lot less happy if they owned the market. I think they'd be 'worse' monopolists than Microsoft.

We already know they're worse monopolists than Microsoft. Whenever Apple has ever owned, or nearly owned, a market, it's been bad for consumers. Apple charges higher prices, has egregiously bad license agreements, has notoriously poor interoperability (ever tried to integrate Mac OS X into a heterogeneous network with LDAP or NIS? I have, and it was not pleasant, and it was at least as bad as integrating Windows into the same network, and in many ways much worse...at least we could buy products to make the pain go away on Windows, not so on Mac OS X; this from an OS claiming to be a UNIX I found particularly galling), and one-size fits all product lines.

Apple makes beautiful products, but if they ever really won in any particular market, I suspect we'd all come to rue the day. And, of course, Microsoft did eventually fall...nobody outside of a few small niches realizes it yet, but Microsoft is no longer the dominant monster they once were. They now have to compete just like the rest of us to hang on to those revenues.

Microsoft's arrogance was borne of market strength. Apple's arrogance is baked right in, and never goes away, no matter how well or badly Apple is faring in the market.

Even BlackBerry, with only half a dozen current handsets (and maybe a couple of dozen in actual use in the wild) forces a lot of compromises. Android could be on hundreds of different devices, and Google can't possibly put its reputation on the line for all of them.

So don't.

It's perfectly OK to say your app is intended for, say, the G1, and leave it at that. If and when some other Android device looks more promising, build a version intended for it.

One of the biggest problems with WAP was that a page that rendered fine on one mobile browser would fail badly on a second one. WAP never took off and today, very few people pay attention to it - so we know that the so-called "scaling" effect didn't help at least one mobile platform in the past.

Add touch-screen capabilities to this list, and you have the mess that was software for Windows mobile. Add multi-touch if you want to make it really messy.

In the end, 90% of your software's code is going to be dealing with different types of user-input, user-input capabilities and how to interface with the actual code that does stuff.

I'm definitely going to agree with you on this being a problem that needs solving before Android being on thousands on devices can be considered a good thing.

Which, of course, may also be a symptom of the problem. (Though perhaps it is just a symptom of my poor memory.)

http://www.youtube.com/watch?v=fZRcYS88BwQ

Oh, wait.

Most of it might be crap, but there are sure to be some wicked ideas.

That Android over time may get a higher market adaptation has nothing to do with scaling. If I were to take on Google's interpretation here, Symbian would seem to scale better than any other mobile OS, and I'm not even sure what that would mean.