Unlike iPhones, Android devices do not have the same company developing both the software and hardware.
This leads to different combinations of screen sizes, resolutions and DPIs and creates quite a challenge when designing and developing for these devices. While the iPhone 3G/S and iPhone 4 have different resolutions and DPI, they share the same screen size and the resolutions follow the same aspect ratio. Therefore, an image can be created to fit the iPhone 4’s specifications and be nicely down-scaled to the iPhone 3G/S. Credit to Steve Jobs for planning ahead and designing his phone with developers in mind.
For some reason, manufactures using the Android OS on their phones did not give us the same luxury. This leaves businesses with two choices – they can either choose not to develop for Android, and willfully miss out on a quarter of the market, OR push forward and learn. Sounds like a necessary evil, doesn’t it? But don’t worry! There is common ground when designing & developing for the extremely versatile world of Android.
Diving into the Problem
We can spend all day comparing “Apples to Androids”, but instead let’s jump right into what we’re dealing with here. If you’re already aware of the problem at hand and would prefer to jump straight into how to handle it, go ahead and jump down to The Solution. Or stay with us for a more detailed explanation.
Popular Android Devices
I thought it best to share a list of the most popular Android devices out in the market today and a few of their specifications.
Looking at this list, two things should jump out at you. First, that Google’s Nexus One is highlighted with an ugly, pale red. This is because this phone has been discontinued. However, even though it is no longer in production, there are still a hefty amount of owners out there. Second, do you notice some inconsistencies between screen sizes and resolutions? They’re not exactly following a perfect pattern. Take special note of how our friends at Motorola throw us a curve ball by adding a few extra pixels in their Droid line. Thanks guys.
Screen Resolutions & Densities
Below is a diagram showing the comparison of screen resolutions in Android Devices.
Because there are devices with different screen sizes that share the same resolution, we run into different densities (DPI/PPI). Refer back to the popular device list and compare the HTC Evo and HTC Droid Incredible to see this difference. The inconsistencies between the two aren’t so large that it’ll ruin the design one way or the other, but it does give you a good idea as to what DPI to choose when you begin designing. So will Android Developers Page.
Some of you right now are probably thinking, “This is old news. We have been dealing with this issue on desktops and laptops for years.” True, but the Android Platform gives us a few nifty tools to solve it this time. Segue!
The good news is that most of the problem solving can be done by application developers. Not to delve too far into the technical side of things, the Android Platform provides the ability to use Density Independent Pixels (dip, as opposed to px) to define sizes of elements. Making sure developers use these units will ensure that anything rendered through code will scale dynamically, ensuring a perfect fit no matter which screen is being used. There are a few more suggestions on units like this; if you’re curious you can check them out on the Supporting Multiple Screens documentation on the Android Developer’s page.
But what about pre-rendered assets, like images? There are a few choices:
- Use code for everything – Easy solution? Depends on the complexity of the design. Result in beautiful, eye-catching apps? Probably not. Limited? Oh yeah!
- Render separate images for all device/density scenarios – This is the easy way out. Sure it’s the simplest way to make sure your images work on multiple screens, but it also increases the size of the application and slows it down.
- Design everything with the idea of Nine-Patch or tiled images in mind – An ideal solution for developers, but very limiting for designers. See below for information on Nine-Patching.
- Render images for most used resolutions with the ability to stretch/tile cleanly – This is the most versatile solution. Because the resolutions of Android devices do not share the same aspect ratio, using the same image for all devices will not work perfectly. So, we worry about the most common, 240×340, 320×480, and 480×800. Then we use Nine-Patch or tiled to make sure these images will fit properly for taller/wider screens.
Nine-Patch is a tool that comes with the Android Development kit that allows us to specify which areas of our images are safe to stretch.
The easiest way to understand this concept is through examples. Here is an example of nine-patch in action.
The corners and logo stay intact as the rest of the image is stretched. An important thing to remember is that you’re not limited to the perfect grid I used in the example; you can be creative with your nine-patching. Nine patches can be as skewed as necessary to accommodate your design. To learn more about Nine-Patch images, see the Draw 9-Patch documentation on the Android Developer’s page.
I’m not going to get into tiling images, since the point of this article is to give designers an understanding of things to keep in mind when designing for Android’s multiple screens, not a “How-To” guide.
Even though all of these solutions will work, I strongly discourage rendering images for every possible screen size unless there is no possible way to nine-patch or tile your images. If you can somehow work around the design limitations of solutions #1 or #3, that would be utopia for developers and the clients who want their app(s) on as many screens as possible. With that, happy Android App designing!