4 ms·

Marketers use the word "scale" the way Star Trek writers used the word "phase". Cue Inigo Montoya: "You keep using that word. I do not think it means what you

Marketers use the word "scale" the way Star Trek writers used the word "phase". 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.

trezor 17y ago
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.
- mechanical_fish 17y ago
  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.)
gaius 17y ago
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.
nuclear_eclipse 17y ago
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/resources-i18n.html#AlternateResources http://developer.android.com/guide/topics/resources/resource...
- mechanical_fish 17y ago
  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.
davidw 17y ago
> 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.
- SwellJoe 17y ago
  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.
credo 17y ago
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.
- blasdel 17y ago
  No, the biggest problem with WAP was that it was Gopher over Telegram.
jamesbritt 17y ago
"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.

trezor 17y ago

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.

mechanical_fish 17y ago
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.)

gaius 17y ago

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.

nuclear_eclipse 17y ago

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/resources-i18n.html#AlternateResources http://developer.android.com/guide/topics/resources/resource...

mechanical_fish 17y ago
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.

davidw 17y ago

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

SwellJoe 17y ago
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.

credo 17y ago

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.

blasdel 17y ago
No, the biggest problem with WAP was that it was Gopher over Telegram.

jamesbritt 17y ago

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