It is important to create Android User Interfaces (UIs) knowing that apps will be running on a variety of different devices. The Android framework provides a number of techniques to enable developers to optimise UIs for a variety of screen sizes and pixel densities.
This article aims to help designers become familiar with what they need to know to deliver the right assets to our development team.
Physical Screen Sizes
Introduction to Physical Screen Sizes
Android breaks down physical screen sizes — measured as the screen’s diagonal length from the top-left corner to bottom-right corner — into four general sizes:
320 × 480 pixels is considered a ‘normal’ screen size by Android. ‘Xlarge’ is in the tablet screen size range. However, the most popular Android smartphones today have WVGA 800+ × 480-pixel HD displays. So, at the time of writing, we can say that most Android smartphones have ’large’ screens.
Figure 1: Android Devices come in many formats from Tablets to Handsets; the versatility of Android means there can be a wide range of screens across manufacturers and platform types.
Figure 2: HTC alone provide a range of Android Devices each with differing screen sizes and screen orientation
Design Considerations for Physical Screen Sizes
Due to the diversity of screen sizes, it is challenging for developers to create a one-size-fits-all layout. For example, on a larger screen, we might want to adjust the position and size of some elements to take advantage of the additional screen space, or on a smaller screen, we might need to adjust sizes so that everything can fit on the screen.
An approach we take is to design a set of layouts for 320 x 522 physical pixels and then to introduce custom layouts for the other screen sizes (small, large, and xlarge if we’re offering the app to tablet users).
Introduction to Screen Density
Screen density is the quantity of pixels within a physical area of the screen, usually referred to as dpi (dots per inch).
Like screen sizes, Android divides screen densities into four basic densities:
– lDPI (low),
– mDPI (medium),
– hDPI (high),
– xHDPI (extra high).
A ‘low’ density screen has fewer pixels within a given physical area compared to a ‘normal’ or ‘high’ density screen.
Figure 3: An example of an application without density support
Android will try to make the most of assets that are available for a given device. Designers should note that Android prefers to scale-down rather than scale up. For example, when looking for a low-density resource and it is not available, the system prefers to scale-down the high-density version of the resource, because it can easily scale a high-density resource down to low-density by a factor of 0.5, with fewer artefacts, compared to scaling a medium-density resource by a factor of 0.75.
Design Considerations for Screen Density
Designers should provide all graphical assets (bitmaps) in sets of different densities. To ensure your bitmaps look their best, you should include alternative versions at different resolutions for different screen densities. At the very least, designers will need to deliver mDPI and hDPI sets of assets for any smartphone app.
To create alternative bitmap drawables for different densities, designers should follow the 3:4:6:8 scaling ratio between the four generalized densities. (This differs from the iPhone, where, at the time of writing, there’s a 2:1 ratio between the iPhone 4 and 3GS.)
Using our ratios of 3:4:6:8, designers should create four different versions of a bitmap to hand off to our developer for production:
– 75 × 75 for lDPI screens (i.e. ×0.75);
– 100 × 100 for mDPI screens (our baseline);
– 150 × 150 for hDPI screens (×1.5);
– 200 × 200 for xHDPI screens (×2.0).
So, if you have a bitmap drawable that’s 48×48 pixels for medium-density screen (the size for a launcher icon), all of the different sizes should be:
– 36×36 for lDPI
– 48×48 for mDPI
– 72×72 for hDPI
– 96×96 for xHDPI
Note: for mobile apps we’re only concerned with lDPI, mDPI and hDPI.
Figure 4: An example of an application with density support
Interactive UI Elements
Introduction to UI Elements
For UI elements that may be take several different states, such as buttons, Android gives developers the option to provide several different images to represent the same graphic.
Design Considerations for Interactive UI Elements
We encourage designers to create 4 states for all interactive UI elements. This helps to make sure the effects of an action are clear & visible.
Introduction to NinePatch
NinePatch (or stretchable) images are PNG files that mark the parts of an image that can be stretched. They are similar to CS3 border-image in web design.
A NinePatch is a variation of a PNG image that uses a one-pixel border to define the area of the image that can be stretched if the image is enlarged. The Android system uses NinePatches for some of its native drawables, e.g. button borders.
Figure 5: An example of hot a horizontally scaleable button can be presented with NinePatch
Design Considerations for NinePatch
NinePatches are a powerful tool for creating images for the backgrounds of Views or Activities that may have a variable size.
To create a NinePatch, draw single-pixel black lines that represent stretchable areas along the left and top borders of your image. The unmarked sections won’t be re-sized, and the relative size of each of the marked sections will remain the same as the image size changes.
NinePatch images must be properly defined PNG files that end in .9.png.
It’s not uncommon for an app to have over 500 pieces of individual graphics. Therefore, it will definitely help to adopt a convention for naming the files.
A sensible naming convention allows a developer to quickly locate files and understand the structure of a project by grouping common or associated elements together through a shared predefined name which trails to a specific description.
Here is a naming convention that we recommend and described all elements associated with a Contact Button within a project.
Where the colours above represent:
- The current feature of the project
- The action of the feature
- The status of the action
- The filetype
Figure 6: Suggested naming convention