The Activity Lifecycle

Once you have the basic structure of an Android application down, the next step is to understand the intricacies behind constructing and destroying Activity objects. We already saw how onCreate() can be used to initialize an Activity, but this is only one aspect of managing an activity’s lifecycle. In this chapter, we’ll learn how to minimize CPU, memory, and battery usage, handle phone call interruptions, save user state, and switch between landscape and portrait orientations by properly implementing an activity’s lifecycle. This is a very important aspect of Android app development, as a failure to do so will cause your application to regularly crash (and that’s a very bad user experience). The following figure shows you the activity lifecycle of an application.

19. The activity lifecycle

An activity lifecycle consists of the following six states:

• Created: The activity has been created and is ready to be displayed.
• Started: The activity is visible, but the user cannot interact with it yet. This state is typically followed immediately by the resumed state.
• Resumed: The activity is running in the foreground and the user can interact with it.
• Paused: The activity has been interrupted by a phone call or dialog message (e.g., a low-battery alert). This often leads immediately into the stopped state. The activity is usually still visible while paused, but obscured by a dialog so the user cannot interact with it.
• Stopped: The activity has been moved to the background and is no longer visible, but the instance still exists in memory. An activity can be re-launched from this state without re-creating it.
• Destroyed: The activity has been released by the system and no longer exists. This will happen automatically when the Android operating system deems it necessary.

When an activity is being created, it passes through the first three states, and when it is being destroyed, it passes through the latter half of the states. However, this rarely happens in a strictly linear fashion. The typical application will switch between the started, resumed, paused, and stopped state as the user interacts with the other activities in your application and gets interrupted by important alerts.

To manage the transitions between these states, the Activity class provides several methods. To define custom startup and teardown behavior, all you have to do is override these methods in an Activity subclass. All of the Activity transition methods are listed below, along with common examples of when they should be used:

• onCreate() – Called when the activity is entering the created state. As we saw in the last chapter, this is where you want to initialize UI elements and otherwise prepare the activity for use.
• onStart() – Called when the activity is entering the started state. This is a good place to load data that needs to be displayed to the user, though this can also be done in onResume() depending on the type of data and how you’re using it.
• onResume() – Called when the activity is entering the resumed state. This is the best place to initialize sensor input (e.g., GPS, cameras) and begin any animations required by your user interface.
• onPause() – Called when the activity is entering the paused state. This is where you should stop using scarce system resources (e.g., animations, GPS, cameras) to maximize the device’s battery life and to reduce your application’s memory footprint. This is the teardown counterpart to the onResume() method.
• onStop() – Called when the activity is entering the stopped state. This is called right before the application enters the background, so it’s a good place to save user data that needs to be re-used later on (e.g., an email draft). Note that onPause() can also be an appropriate time to do this, as it is always called immediately before onStop(). Whether you want to use onPause() or onStop() largely depends on your specific application requirements. onStop() is the teardown counterpart to the onStart() method.
• onDestroy() – Called when the activity is entering the destroyed state. This is the last chance you have to clean up any resources that would otherwise leak when your application is destroyed. This is the teardown counterpart to the onCreate() method; however, the system will automatically release class references when the activity is destroyed, so you usually won’t need to implement onDestroy() unless you started a background thread or created a memory buffer in onCreate().

As you can see, there is a symmetry between the above transition methods. Anything that happens in onStart() should be undone in onStop(), and anything done in onResume() should be undone in onPause().

When overriding any of the above methods, remember that you must call the superclass’s version for your application to work correctly.

Common Activity Transition Events

If you’re feeling a little confused about all of these transitions, it might help to discuss them from the perspective of the user. In this section, we’ve included a few of the most common events that can trigger an activity state transition below. Again, all of these occur frequently in the normal usage of an application, so it’s imperative to ensure that the corresponding transition methods consume and release system resources efficiently.

Pressing the Power Button

When the user presses the device’s power button to put it in standby, the current activity will be moved to the background (that is, it will pause, then stop). As you might expect, the opposite process occurs when they exit standby: the current activity will start, then resume.

If you think about how many times you’ve entered standby on your own Android device while in the middle of an activity, you’ll quickly understand how important it is to properly manage the onPause(), onStop(), onStart(), and onResume() methods. For example, if you left the accelerometer sensor running after the device entered standby, the user would find their battery unexpectedly low when they turned their phone back on.

Rotating the Device

The way the Android system handles device orientation changes can be somewhat counterintuitive, especially for new developers. When the screen rotates, the foreground activity is actually destroyed and re-created from scratch. This is because some layouts need to load different resources for portrait vs. landscape modes, and using the same instance is potentially wasteful.

Tapping the Back Button

When the user taps the Back button, the operating system interprets this as no longer needing the current activity, so it destroys it instead of just sending it to the background. This means that if the user navigates back to the destroyed activity, it will be created from scratch. If you’re trying to record the user’s progress in the destroyed activity, this means that you need to store that information outside of the activity and reload it in onCreate(), onStart(), or onResume(). If you try to store any data as instance variables, it will be lost when the activity is destroyed.

Recreating Destroyed Activities

An activity that is destroyed when the user taps the Back button or when it manually terminates itself is gone forever; however, this is not the case when an activity is destroyed due to system constraints. For example, if an activity is about to be destroyed because the Android OS needs the memory, it first archives the instance state of the Activity in a Bundle object, saves it to disk, and associates the Bundle with the Activity subclass.

This Bundle object can then be used to create a new Activity object with the same state as the destroyed one. Essentially, this makes it appear as though the original Activity instance is always in a stopped state without consuming any resources whatsoever.

Restoring Instance State

If there is an associated Bundle for an Activity, it gets passed to its onCreate() method. For instance, if you were developing an email client and stored the email body in an instance variable called message, your onCreate() method might look something like the following: