As you know, Android devices, by and large, are phones. As such, some activities are more important that others—taking a call is probably more important to users than playing Sudoku. And, since it is a phone, it probably has less RAM than your current desktop or notebook possesses.
As a result of the device's limited RAM, your activity may find itself being killed off because other activities are going on and the system needs your activity's memory. Think of it as the Android equivalent of the circle of life: Your activity dies so others may live, and so on.
You cannot assume that your activity will run until you think it is complete, or even until the user thinks it is complete. This is one example—perhaps the most important example—of how an activity's life cycle will affect your own application logic.
This chapter covers the various states and callbacks that make up an activity's life cycle, and how you can hook into them appropriately.
An activity, generally speaking, is in one of four states at any point in time:
)
.Android will call into your activity as the activity transitions between the four states listed in the previous section, using the methods described in this section. Some transitions may result in multiple calls to your activity, and sometimes Android will kill your application without calling it. This whole area is rather murky and probably subject to change, so pay close attention to the official Android documentation as well as the information here when deciding which events deserve attention and which you can safely ignore.
Note that for all of these methods, you should chain upward and invoke the superclass's edition of the method, or Android may raise an exception.
We have been implementing onCreate()
in all of our Activity
subclasses in all the examples. This method will be called in three situations:
onCreate()
will be invoked with a null
parameter.onCreate()
will be invoked with the Bundle
from onSaveInstanceState()
as a parameter.onCreate()
will be called. Resources are covered in Chapter 20.Here is where you initialize your UI and set up anything that needs to be done once, regardless of how the activity is used.
On the other end of the life cycle, onDestroy()
may be called when the activity is shutting down, either because the activity called finish()
(which “finishes” the activity) or because Android needs RAM and is closing the activity prematurely. Note that onDestroy()
may not be called if the need for RAM is urgent (e.g., an incoming phone call), and that the activity will still be shut down. Hence, onDestroy()
is mostly for cleanly releasing resources you obtained in onCreate()
(if any).
An activity can come to the foreground because it is first being launched, or because it is being brought back to the foreground after having been hidden (e.g., by another activity or by an incoming phone call). The onStart()
method is called in either of those cases.
The onRestart()
method is called in the case where the activity had been stopped and is now restarting.
Conversely, onStop()
is called when the activity is about to be stopped.
The onResume()
method is called just before your activity comes to the foreground, after being initially launched, being restarted from a stopped state, or a pop-up dialog (e.g., an incoming call) is cleared. This is a great place to refresh the UI based on things that may have occurred since the user was last looking at your activity. For example, if you are polling a service for changes to some information (e.g., new entries for a feed), onResume()
is a fine time to both refresh the current view and, if applicable, kick off a background thread to update the view (e.g., via a Handler
).
Conversely, anything that steals your user away from your activity—usually, the activation of another activity—will result in your onPause()
being called. Here, you should undo anything you did in onResume()
, such as stopping background threads, releasing any exclusive-access resources you may have acquired (e.g., a camera), and the like.
Once onPause()
is called, Android reserves the right to kill off your activity's process at any point. Hence, you should not be relying on receiving any further events.
Mostly, the aforementioned methods are for dealing with things at the application-general level (e.g., wiring together the last pieces of your UI in onCreate()
or closing down background threads in onPause()
).
However, a large part of the goal of Android is to have a patina of seamlessness. Activities may come and go as dictated by memory requirements, but ideally, users are unaware that this is occurring. If, for example, a user was working with a calculator, and came back to that calculator after an absence, he should see whatever number he was working on originally, unless he actually took some action to close down the calculator.
To make all this work, activities need to be able to save their application-instance state, and to do so quickly and cheaply. Since activities could be killed off at any time, activities may need to save their state more frequently than you might expect. Then, when the activity restarts, the activity should get its former state back, so it can restore the activity to the way it appeared previously.
Saving instance state is handled by onSaveInstanceState()
. This supplies a Bundle
, into which activities can pour whatever data they need (e.g., the number showing on the calculator's display). This method implementation needs to be speedy, so do not try to be fancy—just put your data in the Bundle
and exit the method.
That instance state is provided to you again in two places: in onCreate()
and in onRestoreInstanceState()
. It is your choice when you wish to reapply the state data to your activity; either callback is a reasonable option.