Android Reference Sheet

An activity is a single, focused thing that the user can do.
Almost all activities interact with the user,

so the Activity class takes care of creating a window for you in which you can place your UI
with setContentView(View). While activities are often presented to the user as full-screen windows,
they can also be used in other ways: as floating windows (via a theme with windowIsFloating set)
or embedded inside of another activity (using ActivityGroup). There are two methods almost all
subclasses of Activity will implement:
onCreate(Bundle) is where you initialize your activity. Most importantly, here you will usually
call setContentView(int) with a layout resource defining your UI, and using findViewById(int) to
retrieve the widgets in that UI that you need to interact with programmatically.
onPause() is where you deal with the user leaving your activity. Most importantly, any
changes made by the user should at this point be committed (usually to

the ContentProvider holding the data).
To be of use with Context.startActivity(), all activity classes must have a
corresponding <activity> declaration in their package'sAndroidManifest.xml.
Fragments
Starting with HONEYCOMB, Activity implementations can make use of the Fragment class to better
modularize their code, build more sophisticated user interfaces for larger screens, and help scale
their application between small and large screens.
Activity Lifecycle
Activities in the system are managed as an activity stack. When a new activity is started, it is placed
on the top of the stack and becomes the running activity -- the previous activity always remains
below it in the stack, and will not come to the foreground again until the new activity exits.
An activity has essentially four states:
If an activity in the foreground of the screen (at the top of the stack), it is active or running.
If an activity has lost focus but is still visible (that is, a new non-full-sized or transparent
activity has focus on top of your activity), it is paused. A paused activity is completely alive (it
maintains all state and member information and remains attached to the window manager), but
can be killed by the system in extreme low memory situations.
If an activity is completely obscured by another activity, it is stopped. It still retains all state
and member information, however, it is no longer visible to the user so its window is hidden and it
will often be killed by the system when memory is needed elsewhere.
If an activity is paused or stopped, the system can drop the activity from memory by either
asking it to finish, or simply killing its process. When it is displayed again to the user, it must be
completely restarted and restored to its previous state.
The following diagram shows the important state paths of an Activity. The square rectangles
represent callback methods you can implement to perform operations when the Activity moves
between states. The colored ovals are major states the Activity can be in.
There are three key loops you may be interested in monitoring within your activity:
The entire lifetime of an activity happens between the first call

to onCreate(Bundle) through to a single final call to onDestroy(). An activity will do all setup of
"global" state in onCreate(), and release all remaining resources in onDestroy(). For example, if it
has a thread running in the background to download data from the network, it may create that
thread in onCreate() and then stop the thread in onDestroy().
The visible lifetime of an activity happens between a call to onStart() until a corresponding
call to onStop(). During this time the user can see the activity on-screen, though it may not be in
the foreground and interacting with the user. Between these two methods you can maintain
resources that are needed to show the activity to the user. For example, you can register
a BroadcastReceiver in onStart() to monitor for changes that impact your UI, and unregister it in
onStop() when the user no longer sees what you are displaying. The onStart() and onStop()
methods can be called multiple times, as the activity becomes visible and hidden to the user.
The foreground lifetime of an activity happens between a call to onResume() until a

corresponding call to onPause(). During this time the activity is in front of all other activities and
interacting with the user. An activity can frequently go between the resumed and paused states -for example when the device goes to sleep, when an activity result is delivered, when a new
intent is delivered -- so the code in these methods should be fairly lightweight.
The entire lifecycle of an activity is defined by the following Activity methods. All of these are hooks
that you can override to do appropriate work when the activity changes state. All activities will
implement onCreate(Bundle) to do their initial setup; many will also implement onPause() to
commit changes to data and otherwise prepare to stop interacting with the user. You should always
call up to your superclass when implementing these methods.
public class Activity extends ApplicationContext {

protected void onCreate(Bundle savedInstanceState);
protected void onStart();
protected void onRestart();
protected void onResume();
protected void onPause();
protected void onStop();
protected void onDestroy();
}
In general the movement through an activity's lifecycle looks like this:
Method
Description
Killable?
Next
onCreate()
Called when the activity
No
onStart()
No
onStart()
No
onResume()or onSt
is first created. This is

where you should do all
of your normal static set
up: create views, bind
data to lists, etc. This
method also provides
you with a Bundle
containing the activity's
previously frozen state, if
there was one.
Always followed
by onStart().
onRestart()
Called after your activity

has been stopped, prior
to it being started again.
Always followed
by onStart()
onStart()

is becoming visible to the
op()
user.
Followed
by onResume() if the
activity comes to the
foreground,
or onStop() if it becomes
hidden.
onResum
e()
will start interacting with

the user. At this point
your activity is at the top
of the activity stack, with
user input going to it.
Always followed
No
onPause()
by onPause().
onPause(
Called when the system
Pre-
onResume()or
is about to start
HONEYC
onStop()
resuming a previous
OMB
activity. This is typically

used to commit unsaved
changes to persistent
data, stop animations
and other things that
may be consuming CPU,
etc. Implementations of
this method must be very
quick because the next
activity will not be
resumed until this
method returns.
Followed by
either onResume() if the
activity returns back to
the front, or onStop()if it
becomes invisible to the
user.
onStop()

is no longer visible to the
user, because another
activity has been
resumed and is covering
this one. This may
happen either because a
new activity is being
started, an existing one
is being brought in front
of this one, or this one is
being destroyed.
Followed by
Yes
onRestart()or
onDestroy()
either onRestart() if this

activity is coming back to
interact with the user,
or onDestroy() if this
activity is going away.
onDestroy()
The final call you receive
Yes
nothing
before your activity is

destroyed. This can
happen either because
the activity is finishing
(someone
called finish() on it, or
because the system is
temporarily destroying
this instance of the
activity to save space.
You can distinguish
between these two
scenarios with
the isFinishing() method
.
Note the "Killable" column in the above table -- for those methods that are marked as being killable,
after that method returns the process hosting the activity may be killed by the system at any
time without another line of its code being executed. Because of this, you should use
the onPause() method to write any persistent data (such as user edits) to storage. In addition, the
method onSaveInstanceState(Bundle) is called before placing the activity in such a background
state, allowing you to save away any dynamic instance state in your activity into the given Bundle, to
be later received in onCreate(Bundle) if the activity needs to be re-created. See the Process
Lifecycle section for more information on how the lifecycle of a process is tied to the activities it is
hosting. Note that it is important to save persistent data in onPause() instead
of onSaveInstanceState(Bundle) because the latter is not part of the lifecycle callbacks, so will not
be called in every situation as described in its documentation.
Be aware that these semantics will change slightly between applications targeting platforms starting
with HONEYCOMB vs. those targeting prior platforms. Starting with Honeycomb, an application is not
in the killable state until its onStop() has returned. This impacts
when onSaveInstanceState(Bundle)may be called (it may be safely called after onPause() and
allows and application to safely wait until onStop() to save persistent state.
For those methods that are not marked as being killable, the activity's process will not be killed by
the system starting from the time the method is called and continuing after it returns. Thus an activity
is in the killable state, for example, between after onPause() to the start of onResume().

Android Reference Sheet

Uploaded by

Copyright:

Available Formats

Android Reference Sheet

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Android Reference Sheet

Uploaded by

Copyright:

Available Formats

An activity is a single, focused thing that the user can do.

Almost all activities interact with the user,

changes made by the user should at this point be committed (usually to

The entire lifetime of an activity happens between the first call

The foreground lifetime of an activity happens between a call to onResume() until a

public class Activity extends ApplicationContext {

In general the movement through an activity's lifecycle looks like this:

Called when the activity

is first created. This is

Called after your activity

Called when the activity

Called when the activity

will start interacting with

Called when the system

activity. This is typically

Called when the activity

either onRestart() if this

The final call you receive

before your activity is

You might also like

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.