Hacker News Reader

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.

[1] http://developer.android.com/guide/topics/resources/resource...

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.

That's all I was trying to get at.

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

> a big advantage for Apple.

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.

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.

It's like the old argument of games console vs PC. Why is it that the original X-box with its puny 733Mhz processor and 64M of main memory was delivering a credible gaming experience against PCs 4x faster with 16x the memory? Because from the developer's perspective it was a stationary target.

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.

"You can't optimize for everything at once."

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.

absolutely, the biggest advantage of Apple's strategy is that you have one consistent hardware platform and the variations (iPod vs iPhone, video-recording support or not, etc.) are clearly defined and understood.

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.

No, the biggest problem with WAP was that it was Gopher over Telegram.

Some of that hardware will have physical keyboards. Some of it will not. .... 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.

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.

I only left the touch-screen out of my argument because I frankly can't remember what kind of touch screen the typical Android phone has.

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