android-supporting-multiple-devices

There are a few common questions asked whenever development begins on a new Android app. What assets will be needed? Which devices should be supported and how many can be supported with the team’s available resources? As an Android developer, my goal is to support the majority of devices and reach the broadest audience.

Specifically, when developing a UI for an Android app, the team must consider assets (backgrounds, buttons, etc.) and layouts (the actual XML UI code). To develop the app efficiently, we want to create the lowest multiple of assets while still supporting a wide range of devices. We also want to avoid having to creating the same layout more than once.
When I first began looking into this, I searched the Internet for best practices for supporting as many devices as possible without having to reproduce the same assets multiplied by the growing number of Android devices. Internet documentation seemed to lack any direct answers. I felt a growing concern that the Android architecture was rigid, and that every asset/layout would have to be perfectly defined for every resolution we wanted to support. This could have been ridiculously time consuming.

However, after further research I discovered that Android architecture was actually rather robust. If properly prepared, it was relatively simple for a developer to handle current and future Android devices. This is how it breaks down: when dealing with Android devices we are worried about more than just the resolution, we need to know the Dots Per Inch (DPI). The DPI is the number of individual dots that can be placed in a line within the span of 1 inch. DPI is considered more important than resolution because Android devices come in so many shapes and sizes. Devices are usually grouped by size or by DPI.

I found it easiest to work with the DPI groupings:

Devices Categorized by Dots Per Inch (DPI), Source: http://developer.android.com/guide/practices/screens_support.html

As you can see, the DPI ranges are overlapping.  I recommend generalizing the ranges by the following values:

• low-dpi = 120
• med-dpi = 160
• high-dpi = 240
• extra high-dpi = 320

These groups also share generally the same relative aspect ratio.  Below is a table of the most common screen configurations.

Common Android Device Screen Configurations, Source: http://developer.android.com/guide/practices/screens_support.html

Which DPIs should you support?  Here is a great way to decide:http://developer.android.com/resources/dashboard/screens.html

Let’s say you have decided you want to support low, medium and high density devices.  How will you create, for example, a background image?  How are we going to support all low density devices when in the table above there are 6 different low-dpi resolutions listed?  This is whereNine-Patch images come into play.  Nine-patch images allow you to define the stretchable areas of a bitmap so that if your bitmap doesn’t already fill a space Android will stretch only these areas to fill the space.

When using Nine-Patch images I would suggest using the lowest resolution so that the image always has room to grow when adjusting for other resolutions.

• Low-dpi (240×320) at 120 dpi
• Med-dpi (320×480) at 160 dpi
• High-dpi (480×800) at 240 dpi

Now that we have these images, where do we put them?  Android has many configuration qualifiers to allow the system to select to correct asset for a device.  In this example we would have 4 folders:

• drawable-ldpi
• drawable-mdpi
• drawable-hdpi
• drawable-nodpi

In each we would have the corresponding “background.png” which we reference only once in our layout code and Android takes care of which folder to grab the image from.

When dealing with an asset like a button image it is best to use medium DPI as your baseline.  Then define your low and high asset sizes as a factor of the medium DPI asset.

• Low DPI – 75% Size (120 dpi)
• Med DPI – 100% Size (160 dpi)
• High DPI – 150% Size (240 dpi)

When it comes to layouts in most cases, it works to use one layout file for all resolutions.  This works because we define the dp (density-independent pixel) size of the UI elements in our layout. This way the layout scales nicely when switching densities.  There are cases where layouts must be defined for each density.  This is due to the physical screen size between devices varying too much.  It is also possible to apply the ldpi/mdpi/hdpi  configuration qualifiers to the layout folders.

It’s impossible to test your app on every device so be sure to use the emulator extensively to test your assets and layouts.

By applying these steps, your app can efficiently support the majority of Android devices.  Good