38

CHAPTER 2 GTTING STARTE

DEVICES
DEVELOPING FOR MOBILE AND EMBEDDED
ndrod does a lot to simplify mobile- or embedded-devIce software development, but vou
understand the reasons behind the conventions. There are several tactors to accoun
Iroid in for
particular,
wh need
g software for mobile and embedded devices, and when develop1ng for Android in

In this chapter you'll learn some of the techniques and best practices for writ
ng efhcient Android code. In later examples, efficiency is sometimes compro-
mised for clarity and brevity when new Android concepts or functionality are
Introduced. In the best tradition of "Do as I say, not as I do, the examples are
designed to show the simplest (or easiest-to-understand) uway of doing some-
thing, not necessarily the best way of doing it.

Hardware-Imposed Design Considerations

Small and portable, mobile devices offer exciting opportunities for software development. Their lin.
ited screen size and
reduced memory, storage, and are far less
processor power exciting, and instead
present some unique challenges.

Compared to desktop or notebook computers, mobile devices have relatively:

Low processing power

Limited RAM
Limited permanent storage capacity
Small screens with low resolution

High costs associated with data transfer

Intermittentconnectivity, slow data transter rates, and high latency
Unreliable data connections
Limited battery life

Each new generation of phones improves many of these

have dramatically improved screen resolutions and
restrictipns. In particular, newer phones
significantly cheaper data costs.
The introduction of tablet devices and Android-powered televisions has expanded the range ot
devices on which your applicatIon may be running and
eliminating some of these restrictions.
However, given the range of devices available, it s always good practice to design to accommodate
the worst-case scenario to ensure your application provides a great user experience no matter wnat
the hardware platform it's installed on.

Be Efficient
Manufacturers of embedded devices, particularly mobile devices, generally value small size and long
hattery life over potential improvecn n processor speed. For developers, that means losing the
 Developing for Mobile and Embedded Devices 39

head si,art dttonaliy attorded thanks to Moore's law

traditionali

(the doubling of the umber of

tegrated circuit every two years). In
ntegra transistors
|accd
on an

s s o r
desktop
pertormance mprOvements; for mobile
11 rocCSsOr pert
and server
hardware, this usually results
d r c t h

br
mobiles. with brighter, higher
mobiles,
devices, it instead means
thinner, more
nwer-cfheient resolution screens. By comparison, improvements
power take a back seat. in
process

means that you always need to

ts
optimize your code so that it runs
In p r a c t n
sSLming that hardware improvements over the quickly and
r e s p o n s i v c

lifetime of your software are uniikely

tavors.
do vou any

ethciency is a big topic Waic CugCerlng, s0

I m not going to try and
a t e r in this chapter you it Icarn some Androd-specihc etfhiciency tips, but for now note that
cover it extensively
6ency is particularly important tor resource-constrained platforms.

Expect Limited Capacity

i n flash memory and solid-state disks have led to a dramatic increase in mobile-device
corage capacities. (MP3 collections still tend to expand to fill the available storage.) Although an
CGB flash drive or SD card is no longer uncommon in mobile devices, optical disks offer more than
2GB. and terabyte drives are now commonly available for PCs. Given that most of the available
srarage on a mobile device is likely to be used to store nmusic and movies, many devices offer rela-

Ively limited storage space for your applications.

Android lets you specify that your application can be installed on the SD card as an alternative to
in detail in Chapter 3), but there are significant restrictions to this
using internal memory (described
approach and it isn't suitable for all applications. As a result, the compiled size of your application is
is ensuring that your application is polite in its
an important consideration, though more important
use of system resources.

data. To make lite easier, you can use

You should carefully consider how you store your application
and share large quantities of data,
the Android databases and Content Providers to persist, reuse,
as described in Chapter 8, "Databases and Content
Providers." For smaller data storage, such as
framework, as described in Chapter 7,
preterences or state settings, Android provides an optimized
"Files, Saving State, and Preferences."
when you want
O u r s e , these mechanisms won't stop you from writing directly to the fhlesystem
and ensure
structuring these hles,
eed to, but in those circumstances always consider how you're
that yours is an efhcient solution.
Part such as caching, pre-tetching, and
ng polite cleaning up after yourself. Techniques and
is
improving application respon
useful for limiting repetitive network lookups
d n g are when
records in a
no ionger
database they re
SsDut don't leave files on the filesystem or

Deeded

Sign for Different Screens particularly

intertaces,
Thesmall sie mobiles challenge for creating good
are a
dnd portability of information-rich graphical user
eNperienee.
when user an increasingly striking and ecosvstem, creating
demanding
oib1ned with the wide range of the Android device
that make up
sizes
range wIde screen

a signiticant
challenge.
i n t e r t a c e s c a n be
itutive, and pleasing user
 only la
know ing that
users will often at ance the
and reen.
atrons
appln l
Wite vour
use h redng the numbeI ol contral.
cen. Ma.
Mat
THons n t u n v e

nformathon
and
tront and
cas1 o

centet pttng, th
the ones
vou tlcreate in Chapter
er 44, are an
wntnals, situh
(oraphk al
as
Rather th excelle
a lor
anhormarnon in a wau
thats easv to understand.
than a secreen
hurtons and rext-entr boves, use colors, shapes, and graphics to
to convey intorn co.
fult
YouTi also need to consder how touch input is going affect
your interface
to affect vour nation,
svlas has passed: now it's all about hnger input, so make sure your V .

interachon using a finger on the screen.

iews are
lo support accessibility and non
g enough
desibiggn.
as Google TV, vou need to ensure your application is navigable without non-touch screen
without relying purclynde
e

Androsd devices are now

availablewith a variety of screen sizes, from
te rablets and 46" Google TVs. As display technology
10.1
advances and . small-scree
released. screen sizes and resolutions will be QVCGA
looks good and
increasingIy varied. To ensure tha.
behaves well on all the possible host devices, you need to deci. ndroid
your ap
u
cation on a variery of screens,
optimiz1ng for small screens and tablers, hut and test po
Uk scale well on any
display. al

Yow'll learn
Chapters 3 and 4.
some
techniques for optimizing your Ul for different screen sizes
ize nin

Expect Low Speeds,

The
High Latency
abiliry to incorporate some of
of online
information within your the wealth
is
incredibly
powerful. Unfortunately, the
mobile Web isn't
applications Android Target Common
Depioyment Target Selection Mode
available as we wouldfast, reliable, or readily
as
Manual
like; so, when
developing your
it's best
you're
Internet-based applications, Automatic
Select
to
assume that the
a
preferred Android Virtuat Device for
will be slow, AVD Name depioyre
network connection Target Name Platform AP Leve CPUTAB
intermittent, and My_AVD Android 4.0 40 14 RM (ar
With
anl1mited 4G data
expensive.
Wi-Fi, this is plans and
worst case changing, but citywide
ensures designing for
that you the
high-standard
making sure
user
experience. This also means
always deliver a
that your
losing (or not
hnding) applications
data
can
a handle Lmiuiator launch pararnefers
The Android
the speed and Emulator
connection Network Speed
EDCE
enables you to Network Larency EDCE
nection. Figurelatency
2-12
of
your network control Wipe User Data
work shows the con- Disable Boot Animation
connection speed and Emulator's net Additionai Emulator
a
distinctly suboprimal latency, Command tine up
EDGE simulating
connection.
FIGURE 2-12
 Developing for Mobile and Embedded Devices M

ensure scamiessness and responsveness no matter what the

e r m e

peed, Jatenc y, aG aya

blit of work access. Some techniqucs mcude iimmg the functonality of your
etwork lookups to cached bursts, wlhen the avalable network connecton applicat,
transter capabilities. supprtsoiy
ltiled data

e Chapter 6. "Usng lnternet Resources," vou "'l learn how to use Internet
resources In VOHT afplications

Further details. inclhdng how to detect the kind of network connections avail
abic at run time, are included n Chapler 16, "Bluetooth, NFC, Networks, and
Wi-Fi.

At What Cost?

t vou're a mobile device owner, you know all too well that some of your device's functionality can
igerally come at a price. Services such as SMS and data transfer can incur additional fees from your
service provider.

Ir's obvious why any costs associated with functionality in your applications should be minimized,
and rhat users should be made aware when an action they perform might result in their being
charged.
Ir's a good approach to assume that there's a cost associated with any action involving an interac
tion with the outside world. In some cases (such as with GPS and data transfer), the user can toggle
Android settings to disable a potentially costly action. As a developer, it's important that you use
and respect those settings within your application.

In any case, it's important to minimize interaction costs by doing the following

Transterring as little data as possible

Caching data and geocoding results to eliminate redundant or repetitive lookups
Stopping all data transfers and GPS updates when your Activity is not visible in the fore-
ground (provided they're only used to update the UI)
Keeping the refresh/update rates for data transters (and location lookups) as low as
practicable

Scheduling big updates or transfers at off-peak times or when connected via Wi-Fi by using
Alarms and Broadcast Receivers, as shown in Chapter 9

Respecting the user's preferences for background data transfers

C n the best solution is to use a lower-quality option that comes at a lower cost.

When
USing location-based services, as described in Chapter 13, *Maps, Geocoding, and Location-
cdServices," you can select a location provider based on whether there is an associated cost.
Withir
n your location-based applications, consider giving users the choice of lower cost or greater
accuracy.
 Developing for Mebile and Embedded Devices

nt to
ensure seamlessness and
responsiveness no matter what the speed, latenc y, and ava
b l t y of network access. Some techniques include limiting the functionality of your applc at0, or
tnetwork
ne nerwork lookups to cached bursts, when the ava1lable network connecton supports onily
r l i ng network

nited data transter capabilities.

In Chapter 6. "Using Internet Resources," you'll learn how to use Internet

resources In your applications.

Further details, including bow to detect the kind of network connections avail
able at run time, are included in Chapter 16, "Bluctooth, NFC, Networks, and
Wi-Fi."

At
What Cost?
if vou're a mobile device owner, you know all too well that some of your device's functionality can
Iiterally come at a price. Services such as SMS and data transfer can incur additional fees from your
service provider.

It's obvious why any costs associated with functionality in your applications should be minimized,
and that users should be made aware when an action they perform might result in their being
charged.
Ir's a good approach to assume that there's a cost associated with any action involving an interac-
tion with the outside world. In some cases (such as with GPS and data transfer), the user can toggle
Android settings to disable a potentially costly action. As a developer, it's important that you use
and respect those settings within your application.

In any case, it's important to minimize interaction costs by doing the following:

Transferring as little data as possible

Caching data and geocoding results to eliminate redundant or repetitive lookups

Sropping all data transfers and GPS updates when your Activity is not visible in the tore-
ground (provided they're only used to update the Ul)
Keeping the refresh/update rates for data transters (and location lookups) as low as
practicable

Scheduling big updates or transfers at of-peak times or when connected via Wi-Fi by us1ng
Alarms and Broadcast Receivers, as shown in Chapter 9

Kespectung the user's preferences for background data transters

Often the best solution is to use a lower-quality option that comes at a lower cost.

when using location-based services, as described in Chapter 13, "Maps, Geocoding, and Location
bascd Services," you can select a location provider based on whether there is an associated cost.
wthin your location-based applications, consider giving users the choice of lower cost or greater
accuracy.
42 CHAPTER 2

t o dehn
or
different
f.
different user
people wll h
suw
hard Although
either plan5.
are
osts contract
c n w m e r a n e r s

provider
and
SA15.
insrime s e r e

free
have
which seems cheaper, consil
rherwren

will wh
orhers
R t r a n s t e r s ,

technique
based on
ading data from the lnternet, ask t
Ted
dara
particular download
times whes
Rathe
her
than
enfon

For
ing a

example,
when
users
are

limit
their
transters
to
hey're cO
choose or
available
tses
nerwork

wa
re

7sr ans

E n v i r o n m e n t

User's
Considering
the a p p l i c a t i o n as the most iportant
me

vour
users
will think of your
assume
that
cant
You
rheir devi roots as a mobile phone platf..

Android has already

expandcd beyond
its

a device s fhirst and for.

m, inos
Although such
devices. kor most people, 0st a
phones or tablet and four
devices are

SMS and email communicator, thirdly a camera, MP3 player. T

secondh an
be in the htth category of "useful stuff.
write will most likely
applications you

with others, including Google hi.

That's bad thing- they'll be in good company
not a
Maps a
That said, cach user's usage model will be different; some people will neu
web browser.
deviceto listen to music, some devices don't support telephony, and some don't include ca.
but the multitasking principle inherent in a device as ubiquitous as it is indispensable is an i came
consideration for usability design.

Ir'salso important to consider when and how your users will use your applications.
People us
mobiles all the time- on the train,
walking down the street, or even while driving their cars, i
can't make
people use their phones appropriately, but you can make sure that
don't distract them any more than your applications
necessary.
What does this mean in terms
of software design? Make sure that your
Is
predictable and well behaved-Start application:
they Te not in the by ensuring that your Activities
foreground. Android fires event handlers when
suspend wnen
resumed, you can so
pause Ul updates and your Activity is pa SeD
ble-there's no point network lookups when
Or updating your Ul if no one can see your applicatiou
processing
withour the Ul
in the
background, Android provides a it. If you need
to ue up.
overheads. Service class designed tor tns
Switches seamlessly pa
of mobile from the
devices, it's likely that background to the foregroun
ground- With the multitaskg
background. It's important your
that they applications will regularly move
terministic process to life" "come nd out ofthe
every chance management
will get it means quickly and seamlesslv.
quickly seamiessiy Android snol
ensure killed to free that if your
seamlessness by
don't notice saving resources. This applicat in the background,there
the should be in visible to the Youc
should bedifference between application state and queuing updates
user.
to it
seamless, with usersrestarting and queuing update so that youri
Is resuming
politeYour
Instead, application should being shown the Ul andyour application. Switc? ate they lasts

your
use
Notihcations
application isn't in the (detailed in
ne
never steal focus or application
Chapter 10) to interru a user's curren
toreground. There are request your use User's a t t e n t i o n v

several ways o alerr users-

- for rx
 Developing for Mobile and Embedded Devices 43

mingcalls are announced by a rimgtone and/or vibration, when you have unread mes
t h e ED flashes;, and when you have new voice mail, a small unread mail icon appears
g he status bar. All these fechniques and more are available to your application using the
in the
Notihcanons mechanism

Deescnts an attractive and intutive Ul- Your application is likely to be one of several in
rue at any time, so it s important that the Ul you present is easy to use. Spend the time and
resources necessary to produce a Ul that is as attractive as it is functional, and don't force
ers fo interpret and relearn your application every time they load it. Usng it should be
imnle, easy, and obviousparticularly given the limited sereen space and distracting user
environment.

t responsive- Responsiveness is one of the most critical design considerations on a mobile

device. You've no doubt experienced the trustration of a "frozen" piece of software; the mul-
of a mobile makes this even more annoying. With the possibility of delays
rifunctional nature

caused by slow and unreliable data connections, it's important that your application use

worker threads and background Services to keep your Activities responsive and, more impor

tant, to stop them

from preventing other applications from responding promptly.

Developing for Android

to Android; the preceding design
considerations just are as

Nothing covered so far specihc

is
for any mobile device. In addition to these general guidelines,
important in developing applications
considerations.
Android has some particular
included in Google's Android Dev Guide
at
Take a minutes to read the design best practices
few
android.com/guide/index.html.
http://developer.
The Android design philosophy demands that applications be designed for:

Pertormance

Responsiveness
Freshness
Security
Seamlessness

Accessibility

Being Fast and Efficient A lot of what you already

environment, being fast means being ethcient.
SOurce-constrained
Android, but the
limitations ofembedded
to
will be applicable
b o u t writing effhicient code take things for granted.
syste VM mean you can't
and the use ofthe Dalvik
team has published some specific
The The Android
nart bet for advice is to go to the source. rehash of its advice, visit
rather than reading a
guidanc
On writing efficient code for
Android, so
html for suggestions.
/per formance.
tp/developer .androi
eveloper.
a n d r o i d . c o m / g u i d e / p r a c t i c e s / d e s i g n