A good understanding of the Activity lifecycle is vital to ensure that your application provides a seamless user experience and properly manages its resources.
Activity Stacks
The state of each Activity is determined by its position on the Activity stack, a last-in–first-out collection of all the currently running Activities. When a new Activity starts, it becomes active and is moved to the top of the stack. If the user navigates back using the Back button, or the foreground Activity is otherwise closed, the next Activity down on the stack moves up and becomes active
Activity States
As Activities are created and destroyed, they move in and out of the stack
Active — When an Activity is at the top of the stack it is the visible, focused, foreground Activity that is receiving user input. Android will attempt to keep it alive at all costs, killing Activities further down the stack as needed, to ensure that it has the resources it needs. When another Activity becomes active, this one will be paused
Paused — In some cases your Activity will be visible but will not have focus; at this point it’s paused. This state is reached if a transparent or non-full-screen Activity is active in front of it. When paused, an Activity is treated as if it were active; however, it doesn’t receive user input events. In extreme cases Android will kill a paused Activity to recover resources for the active Activity. When an Activity becomes totally obscured, it is stopped
Stopped — When an Activity isn’t visible, it “stops.” The Activity will remain in memory, retaining all state information; however, it is now a candidate for termination when the system requires memory elsewhere. When an Activity is in a stopped state, it’s important to save data and the current UI state, and to stop any non-critical operations. Once an Activity has exited or closed, it becomes inactive.
Inactive — After an Activity has been killed, and before it’s been launched, it’s inactive. Inactive Activities have been removed from the Activity stack and need to be restarted before they can be displayed and used
State transitions are nondeterministic and are handled entirely by the Android memory manager. Android will start by closing applications that contain inactive Activities, followed by those that are stopped. In extreme cases, it will remove those that are paused
Monitoring State Changes
To ensure that Activities can react to state changes, Android provides a series of event handlers that are fi red when an Activity transitions through its full, visible, and active lifetimes
Activity state event handlers
package com.paad.activities;
import android.app.Activity;
import android.os.Bundle;
public class MyStateChangeActivity extends Activity {
// Called at the start of the full lifetime.
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// Initialize Activity and inflate the UI.
}
// Called after onCreate has finished, use to restore UI state
@Override
public void onRestoreInstanceState(Bundle savedInstanceState) {
super.onRestoreInstanceState(savedInstanceState);
// Restore UI state from the savedInstanceState.
// This bundle has also been passed to onCreate.
// Will only be called if the Activity has been
// killed by the system since it was last visible.
}
// Called before subsequent visible lifetimes
// for an Activity process.
@Override
public void onRestart(){
super.onRestart();
// Load changes knowing that the Activity has already
// been visible within this process.
}
// Called at the start of the visible lifetime.
@Override
public void onStart(){
super.onStart();
// Apply any required UI change now that the Activity is visible.
}
// Called at the start of the active lifetime.
@Override
public void onResume(){
super.onResume();
// Resume any paused UI updates, threads, or processes required
// by the Activity but suspended when it was inactive.
}
// Called to save UI state changes at the
// end of the active lifecycle.
@Override
public void onSaveInstanceState(Bundle savedInstanceState) {
// Save UI state changes to the savedInstanceState.
// This bundle will be passed to onCreate and
// onRestoreInstanceState if the process is
// killed and restarted by the run time.
super.onSaveInstanceState(savedInstanceState);
}
// Called at the end of the active lifetime.
@Override
public void onPause(){
// Suspend UI updates, threads, or CPU intensive processes
// that don’t need to be updated when the Activity isn’t
// the active foreground Activity.
super.onPause();
}
// Called at the end of the visible lifetime.
@Override
public void onStop(){
// Suspend remaining UI updates, threads, or processing
// that aren’t required when the Activity isn’t visible.
// Persist all edits or state changes
// as after this call the process is likely to be killed.
super.onStop();
}
// Sometimes called at the end of the full lifetime.
@Override
public void onDestroy(){
// Clean up any resources including ending threads,
// closing database connections etc.
super.onDestroy();
}
}
Understanding Activity Lifetimes
Within an Activity’s full lifetime, between creation and destruction, it goes through one or more iterations of the active and visible lifetimes. Each transition triggers the method handlers previously described. The following sections provide a closer look at each of these lifetimes and the events that bracket them
The Full Lifetime
The full lifetime of your Activity occurs between the first call to onCreate and the final call to onDestroy. It’s not uncommon for an Activity’s process to be terminated without the onDestroy method being called
Use the onCreate method to initialize your Activity: inflate the user interface, get references to Fragments, allocate references to class variables, bind data to controls, and start Services and Timers. If the Activity was terminated unexpectedly by the runtime, the onCreate method is passed a Bundle object containing the state saved in the last call to onSaveInstanceState. You should use this Bundle to restore the UI to its previous state, either within the onCreate method or onRestoreInstanceState.
Override onDestroy to clean up any resources created in onCreate, and ensure that all external connections, such as network or database links, are closed
The Visible Lifetime
An Activity’s visible lifetimes are bound between calls to onStart and onStop. Between these calls your Activity will be visible to the user, although it may not have focus and may be partially obscured. Activities are likely to go through several visible lifetimes during their full lifetime because they move between the foreground and background. Although it’s unusual, in extreme cases the Android run time will kill an Activity during its visible lifetime without a call to onStop
The Active Lifetime
The active lifetime starts with a call to onResume and ends with a corresponding call to onPause
An active Activity is in the foreground and is receiving user input events. Your Activity is likely to go through many active lifetimes before it’s destroyed, as the active lifetime will end when a new Activity is displayed, the device goes to sleep, or the Activity loses focus. Try to keep code in the onPause and onResume methods relatively fast and lightweight to ensure that your application remains responsive when moving in and out of the foreground.
Android Activity Classes
The Android SDK includes a selection of Activity subclasses that wrap up the use of common UI widgets. Some of the more useful ones are listed here:
MapActivity — Encapsulates the resource handling required to support a MapView widget within an Activity.
ListActivity — Wrapper class for Activities that feature a ListView bound to a data source as the primary UI metaphor, and expose event handlers for list item selection.
ExpandableListActivity — Similar to the ListActivity but supports an ExpandableListView.