December 22, 2014

Multiple Screen Sizes: Those Who Don't Know History...

One frequent complaint from some corners of the Android developer community is having to deal with multiple screen sizes. Cries of “Fragmentation!” rebound through discussion groups, blog comments, and the like.

It is as if these developers have never seen this before. That’s odd, since they have relied upon the same concepts for applications they use daily for a couple of decades now.

For example, there’s a very good likelihood that you are viewing this page right now in a Web browser on a desktop or notebook computer. If you are, the odds are very high that the computer in question runs a so-called “windowed” operating system, such as Windows, OS X, or most installations of Linux.

(my apologies in advance to those of you viewing this page via lynx from a shell prompt in Linux)

So, as a test, grab the lower-right corner of  your browser window and drag it to a new position. Assuming your window is not maximized, your window should resize to new dimensions. Perhaps it was 749×403 before and now it is 840×590, or something.

This feature — resizable windows — has been around for quite some time. Application developers for the desktop and the Web have had to deal with the fact that their windows will run at different sizes, based on user preferences, monitor resolutions, and the like. In fact, the number of combinations of possible resolutions is huge.

Some developers simply ignore the problem, by either fixing the window size in code or just not really doing anything with the available space. Generally, these apps seem to have fared worse in the marketplace than have apps that do a nice job of resizing to look decent on all resolutions. The best are the ones that take additional space and become more effective: offering a bigger editing area, showing more toolbar icons, and such.

So, if developers have been successfully handling this on the desktop for a couple of decades and the Web for years, why are there complaints about handling this on Android?

After all, Android greatly simplifies matters. There are only a half-dozen or so official screen sizes, and the size of a given device is unlikely to change while the app is running. Desktop and Web developers have it much worse, with a seemingly infinite number of possible resolutions that can change at any moment.

Android developers can learn from how others have handled resizable windows in other environments. For developers that have done other GUI work before — whether it is .NET or AJAX or whatever — there should be lessons that can be re-learned and transferred over from those past experiences.

Without a doubt, mobile introduces different challenges. For example, changes in screen density is not something desktop or Web developers have had to worry about much, but is a bigger issue on Android devices. But even here, desktop developers have had to have multiple icon sets to handle 15″ 800×600 displays and 19″ 1280×1024 displays, so their toolbar buttons and the like do not wind up being too small on newer screens.

Android is not fragmented by multiple screen sizes any more than Windows has fragmented because of resizable windows or OS X has fragmented because Apple came out with many different size screens on their iMac line. It is something developers have had to address in their applications since the dawn of the GUI. Savvy developers will learn from the past and apply it using Android’s tools of the day (e.g., RelativeLayout). Other developers…well, in the words of Edmund Burke, “Those who don’t know history are destined to repeat it.”



  • http://twitter.com/velazcod @velazcod

    Agreed.
    Bringing up screen sizes to the fragmentation problem is not really a valid argument for it, because, as you say, it's not a big issue, and the SDK already provides VERY EASY ways to deal with this.

    I say the fragmentation "problem" is more related with dealing with new APIs in the latest SDK and having to support those without breaking old devices. Yes you can use many ways of dealing with this like SDK checks and reflection, but its not as "easy" as dealing with different screen sizes. Can't complain though, developers just need to get educated on all this stuff, stop complaining and use the tools at hand.

    • Mark Murphy

      Agreed, APIs are a bigger deal for fragmentation, as are device manufacturers who break the API.

      • http://twitter.com/velazcod @velazcod

        can't agree with you more on this! if manufacturers implement their own UI's, they need to PLEASE PLEASE test and keep supporting all the official android APIs…enough said.

  • JohnnyBGood

    Sounds to me like you have never had to deal with the issue yourself, because if you had, you would be less glib about the situation.

    The browser I am using displays the site fine – but with huge green borders to the left and right on the site content. Would you like your android apps to do the same?
    No?
    Well how would you suggest an app written for a 320×480 screen (HTC Hero for example) be displayed on a 800×480 screen? I imagine all the art assets will be scaled up to match the increase in screen resolution which will probably look horrid.
    There are lots of problems associated with writing apps for devices with different display sizes and resolutions. It's one of the things that made J2ME development a pain and ultimately a waste of time.

    • Mark Murphy

      "Sounds to me like you have never had to deal with the issue yourself, because if you had, you would be less glib about the situation."

      Actually, I have. I've been doing software development for over a quarter-century, mobile development off and on for 14 years.

      "Well how would you suggest an app written for a 320×480 screen (HTC Hero for example) be displayed on a 800×480 screen?"

      I would recommend the developer not write for a 320×480 screen, but write to work on a range of screen sizes, just like developers write for resizable windows on the desktop and the Web. This is simply not a new problem.

      "There are lots of problems associated with writing apps for devices with different display sizes and resolutions."

      Which you are welcome to cite. In particular, please be sure to cite how they are radically different than what developers have had to address since the invention of the GUI, since that is the point of this post, and it would be nice if the comments could stay on topic.

    • http://twitter.com/codesector @codesector

      "I imagine all the art assets will be scaled up to match the increase in screen resolution which will probably look horrid. I imagine all the art assets will be scaled up to match the increase in screen resolution which will probably look horrid."

      So put bigger images in the "hdpi" folder. It's that easy. If you have 32×32 icons, add 48×48 icons to your project.

  • Brian Douglas Hayes

    I'm not a developer, but it makes sense to me that a wide variation in screen sizes is harder to develop for. Perhaps not so much when you're sticking to built-in APIs and UI elements, but when you're coding a game with graphics and textures, seems to me that's where things become a bit tricky. Not only do they have to create graphics that work the screen of each handset (and probably some fail-safe options for future devices) but then there's the issue of storage space as well.

    In any case, the fact that "fragmentation" is often brought up in dev circles means to me that the solution isn't obvious, isn't elegant, or just doesn't exist.

    From a consumer standpoint, it makes me less likely to purchase an app. I currently have a T-Mobile G1, but since I'm looking at getting a new phone soon, I do have some concern that an app I purchase today might not work properly or might look weird on a handset with a larger screen. This hurts the developers–they're losing business.

  • Mark Murphy

    "but when you're coding a game with graphics and textures, seems to me that's where things become a bit tricky"

    I didn't say that it is always easy. I said that it is a problem that developers have encountered for a very long time, is not new to Android, and does not represent fragmentation of a platform any more than resizing a window fragments a platform. Trust me, there have been plenty of games written for other platforms that handle more than one resolution.

    "In any case, the fact that 'fragmentation' is often brought up in dev circles means to me that the solution isn't obvious, isn't elegant, or just doesn't exist."

    Or that they haven't tried. Or that they ignored the problem, boxed themselves in a corner, and would prefer to complain. Or that it isn't easy — but it's not easy on any other platform, either. Or that they lack experience in GUI development and therefore are surprised by things that graybeards like me have dealt with for a long time. There are lots of possibilities here.

    "This hurts the developers–they're losing business. "

    By your argument, there is very little software written for Windows, or OS X, or Linux, because developers are "losing business" by having to deal with resizable windows on those platforms.

    Creating an application that supports multiple screen sizes on Android is no more difficult than it is for Windows, etc. That's not to say it's easy, but it's a well-understood problem with time-tested techniques, many of which (e.g., RelativeLayout) were built into Android from the beginning.

    Now, there is no question that because some screen-size-related stuff showed up only in 1.6, that life is somewhat rougher right now, because there are still many 1.5 devices out there. However, that's a problem related to API versions (see other comments on this post), not because multiple screen sizes exist.

    • Brian Douglas Hayes

      "Or that they haven't tried. Or that they ignored the problem, boxed themselves in a corner, and would prefer to complain. Or that it isn't easy — but it's not easy on any other platform, either. Or that they lack experience in GUI development and therefore are surprised by things that graybeards like me have dealt with for a long time. There are lots of possibilities here."

      That's a pretty arrogant view, in my not-so-humble opinion. Okay, I get it–you've been in the industry a long time. You're forgetting (or perhaps not acknowledging) that with Apple's App Store and Android Market, a new mobile developer community was born. Apple, especially, lowered the entry bar to writing apps. They set up the sales and marketing infrastructure (App Store), published all sorts of documentation for the SDK (in plain English, German, French, etc, no less), and kept the hardware changes minimal and consistent. With the exception of the questionable approval process, Apple's been great to their developers, and it has paid off. How many apps do they have now–100k+?

      Android has some similar goals, but as you admit there's an additional challenge with supporting a wide variety of hardware. Personally, I'd say that memory constraints are a bigger issue, but that's immaterial here.

      I can understand frustration with a bunch of newbies getting into the field, but come on–they're working for the same goal. Without the developers, Android is nothing, and I mean that in all seriousness. Palm and Microsoft had a mobile dev community, but those companies did such a lousy job of promoting it. And now look who's in charge–it's Apple, who came out of nowhere. Android is catching up, but there's a lot of work to be done–and it's not just the developer community that has some learning to do.

      Again, I think I make a very valid point that the subject of fragmentation (especially related to screen sizes) keeps coming up, and developers of all sorts seem to be getting stuck on it. If you want to go ahead and blame the community that's new to this thing, go right ahead. But I'm blaming the teachers. Google needs to acknowledge these issues and come forward with some better and easier solutions.

      • http://twitter.com/codesector @codesector

        'How many apps do they have now–100k+?"

        Developers will have to rewrite ALL of these 100k+ apps when new iPhone with bigger screen will be released. Because all iPhones have consistent resolution (320×480) and UI dimensions is based on pixels.

  • http://schwiz.net schwiz

    dealing with multiple screen sizes is no big deal, even for newbs like me. The big issue is multiple sdks for ranging from 1.5-2.1 all pretty much equally divided. So in order for your app to work across the range of devices you can't use the cool new features added in the latest sdk's, or anything past 1.5 for that matter.

  • Mark Murphy

    Yup, those all definitely represent axes of potential fragmentation, just as Web browser idiosyncrasies represent axes of browser fragmentation. Just as the Web developer community created frameworks to address these things, so too will the Android developer community.

    • Josh

      The closest to something like that in the Web dev community is jQuery, and we all spent a very long time, and a lot of money battling incosistencies before that. Even now, IE6 alone continues to add a lot of cost to any given web project.

      The issue isn't that fragmentation is an insurmountable problem. It's possible to overcome it, but comparing the rewards of developing for the iPhone, (even with the draconian approval process and long wait times) vs. the (current) meager rewards of Android's market, and the additional cost of fragmentation, the issue becomes that people won't want to put time and money into a really promising platform.

  • Josh

    Fragmentation isn't just about screen sizes, though Android actually handles that relatively well. Things like differing keyboard layouts, differing hardware specs, MOTOBLUR, Sense UI, and having to buy devices to test all these things out on contribute to Android following the same path as JavaME.

    If you have a bug that can only be replicated on the Droid for instance, how are you going to figure out what it is unless you have access to the device?

    • http://twitter.com/codesector @codesector

      1) Test app in the emulator. 2) Borrow device from a friend or co-worker 3) Ask user to send error log. 4) Test app remotely on a real device (DeviceAnywhere offers this service).

  • hazydave

    This is hardly a new problem… you had resize-able windows in MacOS in 1984 and AmigaOS in 1985. Linux/UNIX, Web developers, etc. all have had to deal with this — dynamically, in a running application. PalmOS didn't start out this way, but made the transition to variable screen sizes at least ten years ago. There are not may platforms that haven't had to deal with this… iPhone and the Commodore 64 come to mind. And Apple's going to have to fix this problem, or the iPhone will be left behind in the dust from all the modern phones, PDAs, tablets, and other devices. And the rumor mill suggests they will, perhaps next week — the rumors claim the "iSlate" or "iPad" or whatever tablet computer they're working on will be a fat iPod, not a skinny Mac.

  • http://www.thedietsolutionprogramreviewed.org/ diet solution

    It is an interesting and useful article about multiple screen in website. Though, this feature — resizable windows — has been around for quite some time, application developers for the desktop and the Web have had to deal with the fact that their windows will run at different sizes, based on user preferences, monitor resolutions, and the like. Thanks for the information.

  • http://www.ps3yellowlightofdeathfix.net/ PS3 Yellow Light

    dealing with multiple screen sizes is no big deal, even for newbs like me. The big issue is multiple sdks for ranging from 1.5-2.1 all pretty much equally divided. So in order for your app to work across the range of devices you can’t use the cool new features added in the latest sdk’s, or anything past 1.5 for that matter.

  • http://www.bsiproductdevelopment.com/ design engineering

    It is great to see android supports multiple screen sizes and densities.  I appreciate it for providing consistent development environment across devices.  It is really interesting to learn about these interesting features. Thanks for sharing.