Handling Activity Lifecycle Events

While this may sound like a broken record please remember that 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 is playing Sudoku. And, since it is a phone, it probably has less RAM than does your current desktop or notebook.

As a result, 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 lifecycle will affect your own application logic. This chapter covers the various states and callbacks that make up an activity’s lifecycle and how you can hook into them appropriately.

Schroedinger’s Activity

An activity, generally speaking, is in one of four states at any point in time:

• Active : The activity was started by the user, is running, and is in the foreground. This is what you’re used to thinking of in terms of your activity’s operation.

• Paused : The activity was started by the user, is running, and is visible, but a notification or something is overlaying part of the screen. During this time, the user can see your activity but may not be able to interact with it. For example, if a call comes in, the user will get the opportunity to take the call or ignore it.

• Stopped : The activity was started by the user, is running, but it is hidden by other activities that have been launched or switched to. Your application will not be able to present anything meaningful to the user directly, only by way of a .

• Dead : Either the activity was never started (e.g., just after a phone reset) or the activity was terminated, perhaps due to lack of available memory.