Developing for Multiple Screens on Android – Part 1: Design
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 creating 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 scaled down to the iPhone 3G/S.
For some reason, the fragmented manufacturers of Androids do not give us that same luxury. This leaves businesses with two choices – 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? With my help, you will see that it’s not THAT bad. There is common ground when designing and 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.
Popular Android Devices
Let me start by sharing a list of the most popular Android devices on the market today, with 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 is still a hefty number of Nexus One owners out there. Second, did you notice the 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.
Below is a diagram showing the comparison of screen resolutions on 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 the Android Developers Page.
Some of you 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 Solution
The good news is that application developers can do most of the problem solving. Not to delve too far into the technical side of things, which I will be covering in Part 2 of this series, the Android Platform provides the ability to use Density Independent Pixels (dip, as opposed to px) to define sizes of elements. By using these units 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. Curious? 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 – Is this an easy solution? Depends on the complexity of the design. Does it result in beautiful, eye-catching apps? Probably not. Is using code 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 screen.
Nine-Patch Images
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!
