Android Recipes 2nd edition docx

COMPANION eBOOK
US $44.99
Shelve in
Mobile Computing
User level:
Intermediate
www.apress.com
BOOKS FOR PROFESSIONALS BY PROFESSIONALS
®
A
ndroid Recipes teaches you how to develop top-notch apps using a proven
problem-solution approach. First, a problem is identified. Then a clear expla-
nation of the solution is given, supported by a fully worked code sample. Best of
all, you can apply all the code examples found in the book directly to your own
projects—saving you time and a great deal of work!
This new edition offers more than 100 down-to-earth recipes that will teach
you how to:
•
Use external libraries to save time and effort
•
Boost app performance by using the Android NDK and Renderscript
•
Design apps for performance, responsiveness, and seamlessness
•
Send data between devices and other external hardware
•
Persist application data and share it between applications
•
Capture and play back various device media items
•
Communicate with web services

•
Get the most out of your user interface
•
Develop a unit conversion app in the context of the command-line/
Android SDK and Eclipse/Android SDK environments
Crammed with insightful instruction and helpful examples, this second edi-
tion of Android Recipes is your guide to writing apps for one of today’s hottest
mobile platforms. It offers pragmatic advice that will help you get the job done
quickly and well.
Dave Smith
|
Jeff Friesen
A valuable coding reference for creating
all kinds of Android apps
Companion
eBook
Available
Smith
Friesen
Android Recipes
SOURCE CODE ONLINE
SECOND EDITION
SECOND
EDITION
Android Recipes
A Problem-Solution Approach

www.it-ebooks.info
For your convenience Apress has placed some of the front
matter material after the index. Please use the Bookmarks

and Contents at a Glance links to access them.
www.it-ebooks.info
iii

Contents at a Glance
 Foreword xviii
 About the Authors xix
 About the Technical Reviewer xx
 Acknowledgments xxi
 Preface xxii
 Chapter 1: Getting Started with Android 1
 Chapter 2: User Interface Recipes 99
 Chapter 3: Communications and Networking 323
 Chapter 4: Interacting with Device Hardware and Media 421
 Chapter 5: Persisting Data 501
 Chapter 6: Interacting with the System 581
 Chapter 7: Working with Libraries 689
 Chapter 8: Working with Android NDK and Renderscript 743
 Appendix A: Scripting Layer for Android 805
 Appendix B: Android Tools Overview 821
 Appendix C: App Design Guidelines 855
 Appendix D: Univerter Architecture 867
 Index 911
www.it-ebooks.info

1
1
Chapter
Getting Started with
Android

Android is hot, and many people are developing Android applications (apps for
short). Perhaps you too would like to develop apps but are unsure about how to
get started. Although you could study Google’s online
Android Developer’s
Guide
( to acquire the needed
knowledge, you might be overwhelmed by the guide’s vast amount of
information. In contrast, this chapter presents just enough theory to help you
grasp the basics. Following this theory are recipes that teach you how to
develop apps and prepare them for publication on Google Play
(
What Is Android?
The
Android Developer’s Guide
formerly defined
Android
as a
software stack

a s e t o f s oft wa re s u bs ys te ms n e ed e d to d e li ve r a f u ll y f unc ti on a l s ol ut io n for
mobile devices. This stack includes an operating system (a modified version of
the Linux kernel),
middleware
(software that connects the low-level operating
system to high-level apps) that’s partly based on Java, and key apps (written in
Java) such as a web browser (known as Browser) and a contact manager
(known as Contacts).
Android offers the following features:
 Application framework enabling reuse and replacement of app
components (discussed later in this chapter)

www.it-ebooks.info
CHAPTER 1: Getting Started with Android
2
 Bluetooth, EDGE, 3G, and WiFi support (hardware dependent)
 Camera, GPS, compass, and accelerometer support
(hardware dependent)
 Dalvik virtual machine optimized for mobile devices
 GSM Telephony support (hardware dependent)
 Integrated browser based on the open source WebKit engine
 Media support for common audio, video, and still image
formats (MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF)
 Optimized graphics powered by a custom 2D graphics library;
3D graphics based on the OpenGL ES 1.0, 1.1, or 2.0
specification (hardware acceleration optional)
 SQLite for structured data storage
Although not part of an Android device’s software stack, Android’s rich
development environment (including a device emulator and a plug-in for the
Eclipse integrated development environment [IDE]) could also be considered an
Android feature.
History of Android
Contrary to what you might expect, Android did not originate with Google.
Instead, Android was initially developed by Android, Inc., a small Palo Alto,
California-based startup company. Google bought this company in the summer
of 2005 and released a beta version of the Android SDK in November 2007.
On September 23, 2008, Google released Android 1.0, whose core features
included a web browser, camera support, Google Search, and more. Table 1-1
outlines subsequent releases. (Starting with version 1.5, each major release
comes under a code name that’s based on a dessert item.)
Table 1-1. Android Releases
Version Release Date and Changes

1.1 Google released SDK 1.1 on February 9, 2009. Changes included
showing/hiding the speakerphone dialpad and saving attachments in
messages.
1.5 (Cupcake)
Based on Linux
Kernel 2.6.27
Google released SDK 1.5 on April 30, 2009. Changes included
recording and watching videos in MPEG-4 and 3GP formats, populating
the home screen (a special app that is a starting point for using an
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
3
Android device) with widgets (miniature app views), and animated
screen transitions.
1.6 (Donut)
Based on Linux
Kernel 2.6.29
Google released SDK 1.6 on September 15, 2009. Changes included an
expanded Gesture framework and the new GestureBuilder development
tool, an integrated camera/camcorder/gallery interface, support for
WVGA screen resolutions, and an updated search experience.
2.0/2.1 (Éclair)
Based on Linux
Kernel 2.6.29
Google released SDK 2.0 on October 26, 2009. Changes included live
wallpapers, numerous new camera features (including flash support,
digital zoom, scene mode, white balance, color effect, and macro
focus), improved typing speed on virtual keyboard, a smarter dictionary
that learns from word usage and includes contact names as
suggestions, improved Google Maps 3.1.2, and Bluetooth 2.1 support.

Google subsequently released SDK update 2.0.1 on December 3, 2009,
and SDK update 2.1 on January 12, 2010. Version 2.0.1 focused on
minor API changes, bug fixes, and framework behavioral changes.
Version 2.1 presented minor amendments to the API and bug fixes.
2.2 (Froyo)
Based on Linux
Kernel 2.6.32
Google released SDK 2.2 on May 20, 2009. Changes included the
integration of Chrome’s V8 JavaScript engine into the Browser app,
voice dialing and contact sharing over Bluetooth, Adobe Flash support,
additional app speed improvements through JIT compilation, and USB
tethering and WiFi hotspot functionality.
Google subsequently released SDK update 2.2.1 on January 18, 2011,
to offer bug fixes, security updates, and performance improvements. It
then released SDK update 2.2.2 on January 22, 2011, to provide minor
bug fixes, including SMS routing issues that affected the Nexus One.
Finally, Google released SDK update 2.2.3 on November 21, 2011, and
this contained two security patches.
2.3
(Gingerbread)
Based on Linux
Kernel 2.6.35
Google released SDK 2.3 on December 6, 2010. Changes included a
new concurrent garbage collector that improves an app’s
responsiveness, support for gyroscope and barometer sensing, support
for WebM/VP8 video playback and AAC audio encoding, support for
near field communication, and enhanced copy/paste functionality that
lets users select a word by press-hold, copy, and paste.
Google subsequently released SDK update 2.3.3 on February 9, 2011,
offering improvements and API fixes. SDK update 2.3.4 on April 28,

2011, added support for voice or video chat via Google Talk. SDK
update 2.3.5 on July 25, 2011, offered system enhancements, shadow
animations for list scrolling, improved battery efficiency, and more. SDK
update 2.3.6 on September 2, 2011, fixed a voice search bug. SDK
update 2.3.7 on September 21, 2011, brought support for Google
Wallet to the Nexus S 4G.
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
4
3.0
(Honeycomb)
Based on Linux
2.6.36
Google released SDK 3.0 on February 22, 2011. Unlike previous
releases, version 3.0 focuses exclusively on tablets, such as Motorola
Xoom, the first tablet to be released (on February 24, 2011). In addition
to an improved user interface, version 3.0 improves multitasking,
supports multicore processors, supports hardware acceleration, and
provides a 3D desktop with redesigned widgets.
Google subsequently released SDK updates 3.1, 3.2, 3.2.1, 3.2.2, 3.2.4,
and 3.2.6 throughout 2011 and in February 2012.
4.0 (Ice Cream
Sandwich)
Based on Linux
Kernel 3.0.1
Google released SDK 4.0.1 on October 19, 2011. SDK 4.0.1 and 4.x
successors unify the 2.3.x smartphone and 3.x tablet SDKs. Features
include 1080p video recording and a customizable launcher.
Google subsequently released SDK updates 4.0.2, 4.0.3, and 4.0.4 in
late 2011 and in March 2012.

4.1 (Jelly Bean) Google released SDK 4.1 on June 27, 2012. Features include vsync
timing, triple buffering, automatically resizable app widgets, improved
voice search, multichannel audio, and expandable notifications. An
over-the-air update (version 4.1.1) was released later in July.

In early October, Google released SDK 4.1.2, which offers lock/home
screen rotation support for the Nexus 7, one-finger gestures to
expand/collapse notifications, and bug fixes/performance
enhancements. Then, in late October, Google released SDK 4.2, which
offers Photo Sphere panorama photos, multiple user accounts (tablets
only), a “Daydream” screensaver that activates when the device is idle
or docked, notification power controls, support for a wireless display
(Miracast), and more.
Android Architecture
The Android software stack consists of apps at the top, middleware (consisting
of an application framework, libraries, and the Android runtime) in the middle,
and a Linux kernel with various drivers at the bottom. Figure 1-1 shows this
layered architecture.
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
5

Figure 1-1. Android’s layered architecture consists of several major parts.
Users care about apps, and Android ships with a variety of useful core apps,
which include Browser, Contacts, and Phone. All apps are written in the Java
programming language. Apps form the top layer of Android’s architecture.
NOTE: Apps are written in a nonstandard Java implementation that combines
Android-specific APIs with Java 5 APIs and a small amount of Java 6 (such as the
java.io.File class’s boolean setExecutable(boolean executable,
boolean ownerOnly) method). Because Android does not support most Java 6

and all Java 7 APIs, you cannot leverage newer Java APIs and dependent features.
For example, you cannot use Java 7’s try-with-resources statement, which depends
upon Java 7’s java.lang.AutoCloseable interface.
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
6
Each Android version (including updates) is assigned an API level, an integer value
uniquely identifying the framework API revision offered by that version of the Android
platform. For example, Android 4.1 is assigned API Level 16 and Android 2.3.4 is
assigned API Level 10. APIs with higher API levels typically cannot be used on devices
with lower API levels. (Google’s support library, which is discussed in Chapter 7,
makes certain newer APIs available to older platform versions.) For example, you
typically cannot use an API at Level 16 on a device that supports only API Level 10
(and lower). API-level constants are available in the
android.os.Build.VERSION_CODES class. Consult “Android API Levels”
( />element.html#ApiLevels) in the Android Developer’s Guide to learn more about
API levels.
Directly beneath the app layer is the
application framework
, a set of high-level
building blocks for creating apps. The application framework is preinstalled on
Android devices and consists of the following components:

Activity Manager
: This component provides an app’s
life cycle

and maintains a shared activity stack for navigating within and
among apps. Both topics are discussed later in this chapter.


Content Providers
: These components encapsulate data (such
as the Browser app’s bookmarks) that can be shared among
apps.

Location Manager
: This component makes it possible for an
Android device to be aware of its physical location.

Notification Manager
: This component lets an app notify the
user of a significant event (such as a message’s arrival)
without interrupting what the user is currently doing.

Package Manager
: This component lets an app learn about
other app packages that are currently installed on the device.
(App packages are discussed later in this chapter.)

Resource Manager
: This component lets an app access its
resources, a topic that’s discussed later in this chapter.

Telephony Manager
: This component lets an app learn about a
device’s telephony services. It also handles making and
receiving phone calls.
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
7


View System
: This component manages user interface
elements and user interface-oriented event generation. (These
topics are briefly discussed later in this chapter.)

Window Manager
: This component organizes the screen’s real
estate into windows, allocates drawing surfaces, and performs
other window-related jobs.
The components of the application framework rely on a set of C/C++ libraries to
perform their functions. Developers interact with the following libraries by way of
framework APIs:

FreeType
: This library supports bitmap and vector font
rendering.

libc
: This library is a BSD-derived implementation of the
standard C system library, tuned for embedded Linux-based
devices.

LibWebCore
: This library offers a modern and fast web
browser engine that powers the Android browser and an
embeddable web view. It’s based on WebKit
( and is also used by
the Google Chrome and Apple Safari browsers.


Media Framework
: These libraries, which are based on
PacketVideo’s OpenCORE, support the playback and
recording of many popular audio and video formats, as well as
working with static image files. Supported formats include
MPEG4, H.264, MP3, AAC, AMR, JPEG, and PNG.

OpenGL | ES
: These 3D graphics libraries provide an OpenGL
implementation based on OpenGL ES 1.0/1.1/2.0 APIs. They
use hardware 3D acceleration (where available) or the included
(and highly optimized) 3D software rasterizer.

SGL
: This library provides the underlying 2D graphics engine.

SQLite
: This library provides a powerful and lightweight
relational database engine that’s available to all apps and
that’s also used by Mozilla Firefox and Apple’s iPhone for
persistent storage.

SSL
: This library provides secure sockets layer‒based security
for network communication.
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
8

Surface Manager

: This library manages access to the display
subsystem, and it seamlessly composites 2D and 3D graphic
layers from multiple apps.
Android provides a runtime environment that consists of core libraries
(implementing a subset of the Apache Harmony Java version 5 implementation)
and the
Dalvik virtual machine
(a non-Java virtual machine that’s based on
processor registers instead of being stack-based).
NOTE: Google’s Dan Bornstein created Dalvik and named this virtual machine after an
Icelandic fishing village where some of his ancestors lived.
Each Android app defaults to running in its own Linux process, which hosts an
instance of Dalvik. This virtual machine has been designed so that devices can
run multiple virtual machines efficiently. This efficiency is largely due to Dalvik
executing Dalvik Executable (DEX)-based files. DEX is a format that’s optimized
for a minimal memory footprint.
NOTE: Android starts a process when any part of the app needs to execute, and it
shuts down the process when it’s no longer needed and system resources are
required by other apps.
Perhaps you’re wondering how it’s possible to have a non-Java virtual machine
run Java code. The answer is that Dalvik doesn’t run Java code. Instead,
Android transforms compiled Java classfiles into the DEX format via its dx tool,
and it’s this resulting code that gets executed by Dalvik.
Finally, the libraries and Android runtime rely on the Linux kernel (version 2.6.x
or 3.0.x) for underlying core services, such as threading, low-level memory
management, a network stack, process management, and a driver model.
Furthermore, the kernel acts as an abstraction layer between the hardware and
the rest of the software stack.
ANDROID SECURITY MODEL
Android’s architecture includes a security model that prevents apps from performing operations

considered harmful to other apps, Linux, or users. This security model, which is mostly based on
process level enforcement via standard Linux features (such as user and group IDs), places
processes in a security sandbox.
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
9
By default, the sandbox prevents apps from reading or writing the user’s private data (such as
contacts or e-mails), reading or writing another app’s files, performing network access, keeping
the device awake, accessing the camera, and so on. Apps that need to access the network or
perform other sensitive operations must first obtain permission to do so.
Android handles permission requests in various ways, typically by automatically allowing or
disallowing the request based upon a certificate or by prompting the user to grant or revoke the
permission. Permissions required by an app are declared in the app’s manifest file (discussed
later in this chapter) so that they are known to Android when the app is installed. These
permissions won’t subsequently change.
App Architecture
Android app architecture differs from desktop application architecture. App
architecture is largely based upon components that communicate via intents,
resources that are often used in user interface contexts, a manifest that
describes the app’s components (and more), and an app package that stores
components, resources, and the manifest.
Components
An app consists of
components
(activities, services, broadcast receivers, and
content providers) that run in a Linux process and that are managed by Android:
 Activities present user interface screens.
 Services perform lengthy jobs (such as playing music) in the
background and don’t provide user interfaces.
 Broadcast receivers receive and react to broadcasts from

Android or other components.
 Content providers encapsulate data and make them available
to apps.
Each component is implemented as a class that’s stored in the same Java
package, which is known as the
app package
. From the Android SDK
perspective, each class’s source file is stored under a package directory
hierarchy that is situated underneath an src directory. (You will learn about the
Android SDK later in this chapter.)
Not all of these components need to be present in an app. For example, one
app might consist of activities only, whereas another app might consist of
activities and a service.
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
10
NOTE: An app’s activities, services, broadcast receivers, and/or content providers
share a set of system resources, such as databases, preferences, a filesystem, and
the Linux process.
Android communicates with activities, services, and broadcast receivers via
intents
, which are messages that describe operations to perform (such as
launch an activity) or (in the case of broadcasts) that provide descriptions of
external events that have occurred (a device’s camera being activated, for
example) and are being announced. Activities, services, and broadcast receivers
can also use intents to communicate among themselves.
Intents are implemented as instances of the android.content.Intent class. An
Intent object describes a message in terms of some combination of the
following items:


Action
: A string naming the action to be performed or, in the
case of broadcast intents, the action that took place and is
being reported. Actions are described by Intent constants
such as ACTION_CALL (initiate a phone call), ACTION_EDIT
(display data for the user to edit), and ACTION_MAIN (start up as
the initial activity). You can also define your own action strings
for activating the components in your app. These strings
should include the app package as a prefix
("com.example.project.GET_NEWSFEEDS", for example).

Category
: A string that provides additional information about
the kind of component that should handle the intent. For
example, CATEGORY_LAUNCHER means that the calling activity
should appear in the device’s app launcher as a top-level app.
(The app launcher is briefly discussed in Recipe 1-4.)

Component name
: A string that specifies the fully qualified
name (package plus name) of a component class to use for
the intent. The component name is optional. If set, the Intent
object is delivered to an instance of the designated class. If
not set, Android uses other information in the Intent object to
locate a suitable target.

Data
: The uniform resource identifier of the data on which to
operate (such as a person record in a contacts database).
www.it-ebooks.info

CHAPTER 1: Getting Started with Android
11

Extras
: A set of key-value pairs providing additional
information that should be delivered to the component
handling the intent. For example, given an action for sending
an e-mail message, this information could include the
message’s subject, body, and so on.

Flags:
Bit values that instruct Android on how to launch an
activity (for example, which task the activity should belong
t o tasks are discussed later in this chapter) and how to treat
the activity after launch (for example, whether the activity can
be considered a recent activity). Flags are represented by
constants in the Intent class; for example,
FLAG_ACTIVITY_NEW_TASK specifies that this activity will
be co me t he s tar t o f a n ew t as k o n t hi s a ct iv i ty s tac k the
activity stack is discussed later in this chapter.

Type
: The MIME type of the intent data. Normally, Android
infers a type from the data. By specifying a type, you disable
that inference.
Intents can be classified as explicit or implicit. An
explicit intent
designates the
target component by its name (the previously mentioned component name item
is assigned a value). Because component names are usually unknown to the

developers of other apps, explicit intents are typically used for app-internal
messages (such as an activity that launches another activity located within the
same app). Android delivers an explicit intent to an instance of the designated
target class. Only the Intent object’s component name matters for determining
which component should get the intent.
An
implicit intent
doesn’t name a target (the component name is not assigned a
value). Implicit intents are often used to start components in other apps. Android
searches for the best component (a single activity or service to perform the
requested action) or components (a set of broadcast receivers to respond to the
broadcast announcement) to handle the implicit intent. During the search,
Android compares the contents of the Intent object to
intent filters
, manifest
information associated with components that can potentially receive intents.
Filters advertise a component’s capabilities and identify only those intents that
the component can handle. They open up the component to the possibility of
receiving implicit intents of the advertised type. If a component has no intent
filters, it can receive only explicit intents. In contrast, a component with filters
can receive explicit and implicit intents. Android consults an Intent object’s
action, category, data, and type when comparing the intent against an intent
filter. It doesn’t take extras and flags into consideration.
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
12
NOTE: Android widely uses intents, which offers many opportunities to replace
existing components with your own components. For example, Android provides the
intent for sending an e-mail. Your app can send this intent to activate the standard
mail app, or it can register an activity that responds to the intent, replacing the

standard mail app with its own activity.
This component-oriented architecture lets an app reuse the components of
other apps, provided that those other apps permit reuse of their components.
Component reuse reduces the overall memory footprint, which is very important
for devices with limited memory.
For example, you’re creating a drawing app that lets users choose a color from
a palette, and another app contains a suitable color chooser and permits this
component to be reused. In this scenario, the drawing app can call upon that
other app’s color chooser to have the user select a color rather than provide its
own color chooser. The drawing app doesn’t contain the other app’s color
chooser or even link to this other app. Instead, it starts up the other app’s color
chooser component when needed.
NOTE: Android starts a process when any part of the app (such as the
aforementioned color chooser) is needed, and it instantiates the Java objects for that
part. This is why Android’s apps don’t have a single entry point (no C-style main()
function, for example). Instead, apps use components that are instantiated and run as
needed.
Activities in Depth
An
activity
is a component that presents a user interface screen with which the
user interacts. For example, Android’s Contacts app includes an activity for
entering a new contact, its Phone app includes an activity for dialing a phone
number, and its Calculator app includes an activity for performing basic
calculations (see Figure 1-2).
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
13

Figure 1-2. The main activity of Android’s Calculator app lets the user perform basic calculations.

Although an app can include a single activity, it’s more typical for apps to
include multiple activities. For example, the Calculator app also includes an
‘‘advanced panel’’ activity that lets the user calculate square roots, perform
trigonometry, and carry out other advanced mathematical operations.
Activities are described by subclasses of the android.app.Activity class, which
is an indirect subclass of the android.content.Context class.
NOTE: Context is an abstract class whose methods let apps access global
information about their environments (such as their resources and filesystems), and
let apps perform contextual operations, such as launching activities and services,
broadcasting intents, and opening private files.
Activity subclasses override various Activity
life cycle callback methods
that
Android calls during the life of an activity. For example, the SimpleActivity
class in Listing 1-1 extends Activity and also overrides the void
onCreate(Bundle bundle) and void onDestroy() life cycle callback methods.
Listing 1-1. A Skeletal Activity
import android.app.Activity;
import android.os.Bundle;

public class SimpleActivity extends Activity
{
@Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState); // Always call superclass method
first.
System.out.println("onCreate(Bundle) called");
}
@Override

www.it-ebooks.info
CHAPTER 1: Getting Started with Android
14
public void onDestroy()
{
super.onDestroy(); // Always call superclass method first.
System.out.println("onDestroy() called");
}
}
The overriding onCreate(Bundle) and onDestroy() methods in Listing 1-1 first
invoke their superclass counterparts, a pattern that must be followed when
overriding the void onStart(), void onRestart(), void onResume(), void
onPause(), and void onStop() life cycle callback methods.
 onCreate(Bundle) is called when the activity is first created.
This method is used to create the activity’s user interface,
create background threads as needed, and perform other
global initialization. onCreate() is passed an
android.os.Bundle object containing the activity’s previous
state, if that state was captured (via void
onSaveInstanceState(Bundle outState)); otherwise, the null
reference is passed. Android always calls the onStart()
method after calling onCreate(Bundle). All meaningful
activities override onCreate(Bundle).
 onStart() is called just before the activity becomes visible to
the user. Android calls the onResume() method after calling
onStart() when the activity comes to the foreground, and
calls the onStop() method after onStart() when the activity
becomes hidden.
 onRestart() is called after the activity has been stopped, just
prior to it being started again. Android always calls onStart()

after calling onRestart().
 onResume() is called just before the activity starts interacting
with the user. At this point the activity has the focus and user
input is directed to the activity. Android always calls the
onPause() method after calling onResume(), but only when the
activity must be paused.
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
15
 onPause() is called when Android is about to resume another
activity. This method is typically used to persist unsaved
changes, stop animations that might be consuming processor
cycles, and so on. It should perform its job quickly, because
the next activity won’t be resumed until it returns. Android
calls onResume() after calling onPause() when the activity
starts interacting with the user, and it calls onStop() when the
activity becomes invisible to the user. Many activities
implement onPause() to commit data changes and otherwise
prepare to stop interacting with the user.
 onStop() is called when the activity is no longer visible to the
user. This may happen because the activity is being destroyed
or because another activity (either an existing one or a new
one) has been resumed and is covering the activity. Android
calls onRestart() after calling onStop(), when the activity is
coming back to interact with the user, and it calls the
onDestroy() method when the activity is going away.
 onDestroy() is called before the activity is destroyed, unless
memory is tight and Android is forced to kill the activity’s
process. In this scenario, onDestroy() is never called. If
onDestroy() is called, it will be the final call that the activity

ever receives. Android can kill the process hosting the activity
at any time after onPause(), onStop(), or onDestroy() returns.
An activity is in a killable state from the time onPause() returns
until the time onResume() is called. The activity won’t again be
killable until onPause() returns.
Figure 1-3 illustrates an activity’s life cycle in terms of these seven methods.
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
16

Figure 1-3. The life cycle of an activity reveals that there’s no guarantee of onDestroy() being called.
Figure 1-3 reveals that an activity is started by calling startActivity(). More
specifically, the activity is started by creating an Intent object describing an
explicit or implicit intent and by passing this object to Context’s void
startActivity(Intent intent) method (launch a new activity; no result is
returned when it finishes).
Alternatively, the activity could be started by calling Activity’s void
startActivityForResult(Intent intent, int requestCode) method. The
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
17
specified int result is returned to Activity’s void onActivityResult(int
requestCode, int resultCode, Intent data) callback method as an argument.
NOTE: The responding activity can look at the intent that caused it to be launched by
calling Activity’s Intent getIntent() method. Android calls the activity’s
void onNewIntent(Intent intent) method (also located in the Activity
class) to pass any subsequent intents to the activity.
Suppose that you’ve created an app named SimpleActivity, and that this app
consists of SimpleActivity (described in Listing 1-1) and SimpleActivity2
classes. Now suppose that you want to launch SimpleActivity2 from

SimpleActivity’s onCreate(Bundle) method. The following example shows you
how to start SimpleActivity2:
Intent intent = new Intent(SimpleActivity.this, SimpleActivity2.class);
SimpleActivity.this.startActivity(intent);
The first line creates an Intent object that describes an explicit intent. It
initializes this object by passing the current SimpleActivity instance’s reference
and SimpleActivity2’s Class instance to the Intent(Context packageContext,
Class<?> cls) constructor.
The second line passes this Intent object to startActivity(Intent), which is
responsible for launching the activity described by SimpleActivity2.class. If
startActivity(Intent) was unable to find the specified activity (which shouldn’t
happen), it would throw an android.content.ActivityNotFoundException
instance.
Figure 1-3 also reveals that onDestroy() might not be called before the app is
terminated. As a result, you should not count on using this method as a place
for saving data. For example, if an activity is editing a content provider’s data,
those edits should typically be committed in onPause().
NOTE: onDestroy() is usually implemented to free system resources (such as
threads) that were acquired in onCreate(Bundle).
The seven life cycle callback methods define an activity’s entire life cycle and
describe the following three nested loops:
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
18
 The
entire lifetime
of an activity is defined as everything from
the first call to onCreate(Bundle) through to a single final call
to onDestroy(). An activity performs all of its initial setup of
‘‘global’’ state in onCreate(Bundle), and it releases all

remaining resources in onDestroy(). For example, if the
activity has a thread running in the background to download
data from the network, it might create that thread in
onCreate(Bundle) and stop the thread in onDestroy().
 The
visible lifetime
of an activity is defined as everything from
a call to onStart() through to a corresponding call to
onStop(). During this time, the user can see the activity
onscreen, although it might not be in the foreground and
interacting with the user. Between these two methods, the
activity can maintain system resources that are needed to
show itself to the user. For example, it can register a
broadcast receiver in onStart() to monitor for changes that
impact its user interface, and it can unregister this object in
onStop() when the user can no longer see what the activity is
displaying. The onStart() and onStop() methods can be
called multiple times, as the activity alternates between being
visible to and being hidden from the user.
 The
foreground lifetime
of an activity is defined as everything
from a call to onResume() through to a corresponding call to
onPause(). During this time, the activity is in front of all other
activities onscreen and is interacting with the user. An activity
can frequently transition between the resumed and paused
states; for example, onPause() is called when the device goes
to sleep or when a new activity is started, and onResume() is
called when an activity result or a new intent is delivered. The
code in these two methods should be fairly lightweight.

ACTIVITIES, TASKS, AND THE ACTIVITY STACK
Android refers to a sequence of related activities as a task and provides an activity stack (also
known as history stack or back stack) to remember this sequence. The activity starting the task
is the initial activity pushed onto the stack and is known as the root activity. This activity is
typically the activity selected by the user via the device’s app launcher. The activity that’s
currently running is located at the top of the stack.
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
19
When the current activity starts another, the new activity is pushed onto the stack and takes
focus (becomes the running activity). The previous activity remains on the stack but is stopped.
When an activity stops, the system retains the current state of its user interface.
When the user presses the device’s BACK key, the current activity is popped from the stack (the
activity is destroyed), and the previous activity resumes operation as the running activity (the
previous state of its user interface is restored).
Activities in the stack are never rearranged, only pushed and popped from the stack. Activities
are pushed onto the stack when started by the current activity, and they are popped off the stack
when the user leaves them by pressing the BACK key. As such, the stack operates as a “last in,
first out” object structure.
Each time the user presses BACK, an activity in the stack is popped off to reveal the previous
activity. This continues until the user returns to the home screen or to whichever activity was
running when the task began. When all activities are removed from the stack, the task no longer
exists.
Check out the “Tasks and Back Stack” section in Google’s online Android documentation to learn
more about activities and tasks. You’ll find this documentation located at

Views, View Groups, and Event Listeners
An activity’s user interface is based on
views
(user interface components),

view
groups
(views that group together related views), and
event listeners
(objects
that listen for events originating from views or view groups).
NOTE: Android refers to views as widgets. Don’t confuse widget in this context with
the widgets that are shown on the Android home screen. Although the same term is
used, user interface widgets and home screen widgets are different. User interface
widgets are components; home screen widgets are miniature views of running apps.
Views are described by subclasses of the concrete android.view.View class
and are analogous to Java Swing components. The android.widget package
contains various View subclasses, such as Button, EditText, and TextView (the
parent of EditText).
View groups are described by subclasses of the abstract
android.view.ViewGroup class (which subclasses View) and are analogous to
Java Swing containers. The android.widget package contains various
subclasses, such as LinearLayout.
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
20
NOTE: Because ViewGroup is a subclass of View, view groups are a kind of view.
This arrangement lets you nest view groups within view groups to achieve screens of
arbitrary complexity. Don’t overdo it, however, because users typically don’t want to
navigate screens that are overly complex.
Event listeners are described by nested interface members of View and
ViewGroup (and various subclasses). For example, View.OnClickListener
declares a void onClick(View v) method that’s invoked when a clickable view
(such as a button) is clicked.
The following onCreate(Bundle) method uses Button, EditText, and

LinearLayout to create a screen where the user enters text and subsequently
clicks the button to display this text via a pop-up message:
@Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
LinearLayout layout = new LinearLayout(this);
final EditText et = new EditText(this);
et.setEms(10);
layout.addView(et);
Button btnOK = new Button(this);
btnOK.setText("OK");
layout.addView(btnOK);
View.OnClickListener ocl;
ocl = new View.OnClickListener()
{
@Override
public void onClick(View v)
{
Toast.makeText(class.this, et.getText(),
Toast.LENGTH_SHORT).show();
}
};
btnOK.setOnClickListener(ocl);
setContentView(layout);
}
After calling its superclass counterpart, onCreate(Bundle) instantiates
LinearLayout. This container arranges its children in a single column or row. Its
default behavior is to arrange the children in a row.
The keyword this is passed to LinearLayout’s constructor, a practice followed

by other widget constructors. The current context object referenced by this lets
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
21
a widget load and access resources (discussed later in this chapter) when
necessary.
Next, EditText is instantiated and its inherited (from TextView) void setEms(int
ems) method is called to set the widget’s width to 10
ems
(a relative
measurement unit; one em equals the height of the capital letter ‘‘M’’ in the
default font size).
At this point, LinearLayout’s inherited (from its ViewGroup parent) void
addView(View child) method is called to add the EditText widget instance to
the LinearLayout widget container instance.
Having finished with EditText, onCreate(Bundle) instantiates Button, invokes its
inherited (from TextView) void setText(CharSequence text) method to set the
button label to OK, and adds the Button instance to the LinearLayout instance.
onCreate(Bundle) now instantiates an anonymous class that implements the
View.OnClickListener interface, overriding onClick(View) to display a
toast
(a
message that pops up on the surface of the window for a short period of time).
CAUTION: The code fragment demonstrates a problem where efficiency is
concerned. Consider the approach to creating the click listener that is subsequently
attached to the button. This approach is inefficient because it requires that a new
object (an instance of an anonymous class that implements the
View.OnClickListener interface) be created each time onCreate(Bundle) is
called. (This method is called each time the device orientation changes.) A more
efficient approach makes ocl an instance field and instantiates the anonymous class

only when ocl does not contain the null reference. However, an even better solution
exists. This solution is presented later in this chapter where resources are discussed.
The toast is created by invoking the android.widget.Toast class’s Toast
makeText(Context context, CharSequence text, int duration) factory
method, where the value passed to duration is one of Toast.LENGTH_SHORT or
Toast.LENGTH_LONG. After the Toast instance has been created, Toast’s void
show() method is called to display the toast for the specified period of time. (The
message fades in when this method is called and fades out after the duration
expires.)
Following listener creation, onCreate(Bundle) invokes Button’s inherited (from
View) void setOnClickListener(View.OnClickListener l) method to register
the previously created listener object with the button.
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
22
Finally, onCreate(Bundle) invokes Activity’s void setContentView(View view)
method. This method is used to install the LinearLayout instance into the
activity’s
view hierarchy
so that the edittext and button widgets can be
displayed in a single row.
NOTE: Although you can create user interfaces by instantiating widget classes, there
are advantages to using resources for this task. This topic is discussed later in this
chapter.
Fragments
Android 3.0 introduced the concept of
fragments
, which are objects that
represent parts of an activity’s user interface. A fragment serves as a modular
section of an activity with its own life cycle and the ability to receive its own

input events, and which you can add or remove while the activity is running. You
can combine multiple fragments into a single activity to build a multipane user
interface (typically in a tablet context) and reuse the fragment in multiple
activities.
NOTE: You must always embed a fragment in an activity.
Google introduced fragments in Honeycomb mainly to support more dynamic
and flexible user interfaces on tablets and other large screens. Because a
tablet’s screen is much larger than that of a handset, there’s more room to
combine and interchange widgets. Fragments allow such designs without
forcing you to manage complex changes to the view hierarchy. By organizing an
activity’s layout into fragments, you can modify its appearance at runtime and
preserve changes in the activity-managed back stack.
TIP: You should design each fragment as a modular and reusable activity component.
Because each fragment defines its own layout and its own behavior with its own life
cycle callbacks, you can include one fragment in multiple activities, so you should
strive to design for reuse and avoid directly manipulating one fragment from another
fragment. This is especially important because a modular fragment lets you change
fragment combinations for different screen sizes.
www.it-ebooks.info