I was excited when he started talking about the resolution differences but then quickly bummed that he didn't even scratch the surface to talk about just how the changes affected the development.
He did talk about it. He says that the declarative XML layouts make it easy to iterate the UI, but hard to make it pixel perfect, and is therefore akin to web design.
I am the author of the article. What aspects do you think I missed that you'd like to know more about? My first draft was much longer with a lot more details but I was worried about a writing a book instead of an essay :-)
I've been kicking around the idea of rewriting some of my apps for Android and the resolution differences has always been a big worry of mine. As another commenter pointed out you did allude to the Android UI being more like a scalable interface you don't always have control over but sometimes we still have to use pixel perfect designs, even on the web. For using the standard UI elements it makes sense to fit in with a scalable design but I've thought at length about games and how that would work across different resolutions without being able to rely on using high and low res graphics. iOS gives me a lot of crutches to just know what systems I have to support and the shear variety of screens and systems gives me a lot of pause for the layout or number of versions I'll have to package up.
Honestly I should be researching this myself, I just got excited when the topic came up in your article and was sad to see that it didn't answer my every question I've been mulling over for some months now. It was my expectations what were unreasonable and not your articles content.
I am not sure how it helps to game developers but it is pretty concise guide for general app development.
We have gone through the screen size adjustments and minor incompatibilites across versions when porting to Galaxy Tab (I have summarized the experience in the blog: http://touchqode.com/blog/008_developing_for_galaxy_tab.htm ) and then when Honeycomb came out.
But more often than not it is our hackiness or vendor fancy tweaks that cause problems rather than the android itself.
If you have an application that runs only on cell phones, you shouldn't be worrying about different screen sizes. Have you used layouts in Qt or any other UI toolkit? UIs on Android work in a similar way. Android will properly scale your UI to different screen sizes, just like a Qt window can be resized without crapping up its layout.
About graphics: Google defines 4 screen densities: XHDPI, HDPI, MDPI and LDPI. You create separate graphics for each of them and import them into your project. Android will automatically pick the appropriate version of your artwork depending on the device your app is running on. No manual work required.
See that @drawable/slate in there? Android will try to find the appropriate version of "slate.jpg" (or "slate.png", or whatever) from one of these directories: res/drawable-hdpi, res/drawable-mdpi or res/drawable-ldpi. If it can't, it'll try to look for the file in res/drawable[1]. So you have 3 versions of the file residing in 3 separate directories.
Don't worry about screen sizes. They don't vary too much anyway. Phones these days lie somewhere between the 3" to 5" spectrum. Not much of a difference for most apps, unless your UI is doing something very special.
---
[1] This is the default project structure; you can probably change it.
I actually really meant this from a UI perspective where the _screens_ from different applications can flow back and forth between each other. But data is an equally important point to bring up.
There's a negative aspect to the multi app ui history model as well though in that its easy to create confusing app launch and back button behaviors. Example: if I jump from my app to the browser then hit home then later relaunch the app and I'm confused because I start in the browser.
Having the ui stack capability across apps is great but as a developer it requires some extra effort to avoid confusing incidents like this for users.
