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