Design Considerations for Android Application User ... - Code That

chulavistajuniorMobile - Wireless

Dec 10, 2013 (4 years and 7 months ago)


Design Considerations for Android Application User Interfaces


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 ‘no
rmal’ 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
martphones have ’large’ screen.

Design Considerations for Physical Screen Sizes

Due to the diversity of screen sizes, it is challenging for developers to create a one
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 lay
outs for the other screen sizes (small, large, and xlarge if we’re offering
the app to tablet users).

Screen Density

Introduction to Screen Density

Screen density is the quantity of pixels within a physical area of the screen, usually referred
to as dp
i (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 ‘norma
or ‘high’ density screen.

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 no
t available, the system prefers to scale
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 fac
tor 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 diffe
rent 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 f
or 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 scree
n (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.

Interactive UI Elements

Introduction to UI Ele

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 designer
s 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
tched. 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 o
f its native drawables, e.g. button borders.

Figure 3:

An example of hot a horizontally scaleable button can be presented with

Design Considerations for NinePatch

NinePatches are a powerful tool for creating images for the backgrounds of View
s 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.

Naming Convention

It’s not uncommon for an app to have over 500 pieces of individual graphics. Therefore, it
will defin
itely 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 whi
ch 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


The action of the feature


The status of the action


The filetype

urther Reading