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

chulavistajuniorΚινητά – Ασύρματες Τεχνολογίες

10 Δεκ 2013 (πριν από 3 χρόνια και 6 μήνες)

109 εμφανίσεις


Design Considerations for Android Application User Interfaces

Introduction

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:

-

Small,

-

Normal,

-

Large

-

Xlarge.

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
s
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
-
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 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
l’
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
-
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 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
ments

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.

NinePatch

Introduction to NinePatch

NinePatch (or stretchable) images are PNG files that mark the parts of an image that can be
stre
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
NinePatch




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.

contact_button_
send_
selected
.jpg

Where the colours above represent:

1.

The current feature of the
project

2.

The action of the feature

3.

The status of the action

4.

The filetype



F
urther Reading

http://developer.android.com/design/patterns/pure
-
android.html

http://developer.androi
d.com/resources/dashboard/screens.html

http://developer.android.com/guide/topics/graphics/2d
-
graphics.html#nine
-
patch

http://developer.android.com/guide/topics/graphics/2d
-
graphics.html

http://developer.android.com/guide/practices/ui
_guidelines/index.html

http://developer.android.com/guide/practices/screens_support.html

http://coding.smashingmagazine.com/2011/06/30/designing
-
for
-
android/