Every instance of Activity has a lifecycle. During this lifecycle, an activity transitions between four states: resumed, paused, stopped, and nonexistent. For each transition, there is an Activity function that notifies the activity of the change in its state. Figure 3.4 shows the activity lifecycle, states, and functions.
Figure 3.4 indicates for each state whether the activity has an instance in memory, is visible to the user, or is active in the foreground (accepting user input). Table 3.1 summarizes this information.
Table 3.1 Activity states
| State | In memory? | Visible to user? | In foreground? |
|---|---|---|---|
|
nonexistent |
no |
no |
no |
|
stopped |
yes |
no |
no |
|
paused |
yes |
yes/partially* |
no |
|
resumed |
yes |
yes |
yes |
(* Depending on the circumstances, a paused activity may be fully or partially visible.)
Nonexistent represents an activity that has not been launched yet or an activity that was just destroyed (by the user pressing the Back button, for example). For that reason, this state is sometimes referred to as the “destroyed” state. There is no instance in memory, and there is no associated view for the user to see or interact with.
Stopped represents an activity that has an instance in memory but whose view is not visible on the screen. This state occurs in passing when the activity is first spinning up and re-occurs any time the view is fully occluded (such as when the user launches another full-screen activity to the foreground, presses the Home button, or uses the overview screen to switch tasks).
Paused represents an activity that is not active in the foreground but whose view is visible or partially visible. An activity would be partially visible, for example, if the user launched a new dialog-themed or transparent activity on top of it. An activity could also be fully visible but not in the foreground if the user is viewing two activities in multi-window mode (also called “split-screen mode”).
Resumed represents an activity that is in memory, fully visible, and in the foreground. It is the activity the user is currently interacting with. Only one activity across the entire system can be in the resumed state at any given time. That means that if one activity is moving into the resumed state, another is likely moving out of the resumed state.
Subclasses of Activity can take advantage of the functions named in Figure 3.4 to get work done at critical transitions in the activity’s lifecycle. These functions are often called lifecycle callbacks.
You are already acquainted with one of these lifecycle callback functions – onCreate(Bundle?). The OS calls this function after the activity instance is created but before it is put onscreen.
Typically, an activity overrides onCreate(Bundle?) to prepare the specifics of its UI:
-
inflating widgets and putting them on screen (in the call to setContentView(Int))
-
getting references to inflated widgets
-
setting listeners on widgets to handle user interaction
-
connecting to external model data
It is important to understand that you never call onCreate(Bundle?) or any of the other Activity lifecycle functions yourself. You simply override the callbacks in your activity subclass. Then Android calls the lifecycle callbacks at the appropriate time (in relation to what the user is doing and what is happening across the rest of the system) to notify the activity that its state is changing.