Hmm, the whole write-up doesn't really disprove the screen fragmentation issue. Mostly downplays it. That there are layout tools to help you cater for multiple screens for example, doesn't mean they do that work for you. Or that the "slight variation in width" he mentions should not also be taken care of.
(Which is just part of the whole problem -- there's also the hardware features and OS version issues which are even more important).
> Or that the "slight variation in width" he mentions should not also be taken care of.
What exactly is the issue with this? Just like with any other sane widget toolkit designed since the 80's for varying screen or window sizes, Android's layouts and widgets work perfectly fluid to occupy more or less space. One layout works just as well on a 4-inch phone as it does on a 5.5-inch phone, and it will naturally fit more content on the bigger screen.
The only problem is with tablet screens where blowing up a user interface designed for a small phone screen technically works but is pretty terrible to use. This is no different from another unnamed mobile platform where you also need to design a separate tablet layout.
>What exactly is the issue with this? Just like with any other sane widget toolkit designed since the 80's for varying screen or window sizes, Android's layouts and widgets work perfectly fluid to occupy more or less space.
It becomes an issue if you're not a sloppy kind of designer/programmer, who just lets the widget flow to occupy more available space. It's not like design only use things like a text entry boxes or a web-views (widgets that just letting them get more space is usually fine and natural).
Second, it becomes an issue for every app where you want to have a custom interface -- so the built-in Android widget and layout are of no use to you. This holds for most games, customly designed apps, etc.
It becomes an issue if you're not a sloppy kind of
designer/programmer, who just lets the widget flow to
occupy more available space.
So it's sloppy to build your UI in the exact way it was intended to be built? Not hard-coding every widget sizes is somehow... sloppy? Because the impression I get is that if you can make your app handle different screen sizes appropriately without having to meticulously hand code for every resolution, you're coming out way ahead of the game. That way you present a nice, consistent UX across all devices, and don't have to scramble every time a new resolution or device size comes out.
It's also possible to do this with custom interfaces - a little extra attention to your layout engine will net huge benefits in terms of time saved in designing layouts for each of the possible resolutions.
Hardware variations, vendor customizations, capabilities variance - these are real issues. Building a UI that flows well across most resolutions and sizes? Not so much.
> It becomes an issue if you're not a sloppy kind of designer/programmer, who just lets the widget flow to occupy more available space.
What? In most cases, that is exactly the right thing to do. Your content should be the center of the app in the first place.
> It's not like design only use things like a text entry boxes or a web-views (widgets that just letting them get more space is usually fine and natural).
Why don't you name some actual, concrete examples instead of making vague statements like this? Where do you think that this is an issue?
> Second, it becomes an issue for every app where you want to have a custom interface -- so the built-in Android widget and layout are of no use to you. This holds for most games, customly designed apps, etc.
What does a "customly designed app" even mean? There are countless examples of Android applications designed beyond the norm (http://androidniceties.tumblr.com/) and they don't seem to have any problem doing so - and guess what: they're using the Android frameworks just like everybody else.
And just like application developers, game developers have been working with a myriad of different screen resolutions for ages now. The only people having a problem with this are those exclusively developing for a certain fruit device that has shot itself in the foot by not designing for varying resolutions in the first place.
There are two main parameters in screen geometry: Size and density. You can deal with the major size differences across tablets and handsets with Fragment objects and two or three different layouts per Activity, keyed to screen size, and two or three sets of assets, keyed to density. So at most you have 9 combinations, usually 6 or fewer, to test. This will cover 90%+ of non-game cases. Portability for OpenGL games is a whole other universe.
Also: Use RelativeLayout. Get your designer to design directly in the layout editor, and test them on screens he finds important and representative. That way he won't specify designs that can't be implemented.
Well, we can't have only two phone manufacturers with their own OS, Apple with maybe 3 different aspect ratios and Google with another two or three. Everybody wants its share of the cake so we'll inevitably end up with many different screens and OS, basically how it has been until 2007. I prefer to have designers and developers clever enough to adapt to variable aspect ratios on two OS than an ecosystem fragmented into a zillion of technologies. I think we've been lucky.
(Which is just part of the whole problem -- there's also the hardware features and OS version issues which are even more important).