Understanding Activities

An activity is a single, focused action that a user can take. For example, an activity might present a list of menu items that a user can choose from, or it might display photographs along with captions. An application may consist of only one activity or (like most applications in the Android system) several. Though activities may work together to appear to be one cohesive application, they work independently from each other.

An activity in Android is an important part of an application’s overall life cycle, and the way the activities are launched and put together is a fundamental aspect of the Android application model. Every activity is implemented as an implementation of the Activity base class.

Almost all activities interact with the user, so the Activity class creates for you the window in which you can place your user interface (UI). Activities are most often presented in full-screen mode, but in some instances you can find an activity floating in a window or embedded inside another activity — known as an activity group.

Working with methods, stacks, and states

Two important methods that almost all activities implement are

onCreate: Where the activity is initialized. Most importantly, it’s where you tell the activity which layout to use by using a layout resource identifier — considered the entry point of your activity.

onPause: Where you deal with the user leaving your activity. Any changes made by the user should be committed at this point (if you need to save them).

Activities in the system are managed as an activity stack. When a new activity is created, it’s placed on top of the stack and becomes the running activity. The previous running activity always remains below it in the stack and returns to the foreground only when the new activity exits.

To be a successful programmer, you must understand the importance of how and why the activity works behind the scenes. You can not only better understand the Android platform but also accurately troubleshoot your application’s odd behavior at runtime.

An activity has essentially four states, as described in Table 5-1.

Table 5-1 Essential States of an Activity

Activity State	Description
Active/running	The activity is in the foreground of the screen (at the top of the stack).
Paused	The activity has lost focus but is still visible. (A new, non-full-size or transparent activity has the focus on top of your activity.) Because a paused activity is completely alive, it can maintain state and member information and remains attached to the window manager in Android. However, up through Gingerbread (3.0) the activity can be killed by the Android system in extreme low-memory conditions.
Stopped	If an activity becomes obscured by another activity, it’s stopped. It retains all state and member information, but isn’t visible to the user. Therefore, the window is hidden and will often be killed by the Android system when memory is needed elsewhere.
Created and resumed	The system has either paused or stopped the activity. The system can reclaim the memory by asking it to finish, or it can kill the process. When it displays the activity to the user, it must resume by restarting and restoring to its previous state.

Tracking an activity’s life cycle

Figure 5-1 shows the important paths of an activity — the activity life cycle.

The rectangles represent callback methods you can implement to respond to events in the activity. The shaded ovals represent the major states of the activity.

The activity life cycle is a large and complex topic, and the following sections cover only the basics. If you want to read more about activity life cycles, check out the “Activity Life Cycle and Process Life Cycle” article in the Android documentation at http://d.android.com/reference/android/app/Activity.html#ProcessLifecycle .

Monitoring key loops

You may be interested in monitoring these three loops in your activity:

The entire lifetime takes place between the first call to onCreate() and the final call to onDestroy(). The activity performs all global setup in onCreate() and releases all remaining resources in onDestroy(). For example, if you create a thread to download a file from the Internet in the background, it may be initialized in the onCreate() method. That thread can be stopped in the onDestroy() method.

The visible lifetime of the activity takes place between the onStart() and onStop() methods. During this time, the user can see the activity onscreen (though it may not be in the foreground interacting with the user, which can happen when the user is interacting with a dialog box). Between these two methods, you can maintain the resources that are needed to show and run your activity. For example, you can create an event handler to monitor the state of the phone. The phone state can change, and this event handler can inform the activity of the phone entering Airplane mode and react accordingly. You would set up the event handler in onStart() and tear down any resources you’re accessing in onStop(). The onStart() and onStop() methods can be called multiple times as the activity becomes visible or hidden to the user.

The foreground lifetime of the activity begins at the call to onResume() and ends at the call to onPause(). During this time, the activity is in front of all other activities and is interacting with the user. An activity normally toggles between onResume() and onPause() multiple times, for example, when the device goes to sleep or when a new activity handles a particular event — therefore, the code in these methods must be fairly lightweight.

Viewing activity methods

The entire activity life cycle boils down to these methods:

public class Activity extends ApplicationContext {

protected void onCreate(Bundle savedInstanceState);

protected void onStart();

protected void onRestart();

protected void onResume();

protected void onPause();

protected void onStop();

protected void onDestroy();

}

All methods can be overridden, and custom code can be placed in all of them. All activities implement onCreate() for initialization and may also implement onPause() for clean-up. You should always call the superclass (base class) when implementing these methods.

Following an activity’s path

The movement of an activity throughout its life cycle looks like this:

onCreate(): Called when the activity is first created. You initialize most of your activity’s class-wide variables here. onStart() is always called next. Killable: No. Next: onStart().

onRestart(): Called after your activity has been stopped before being started again. onStart() is always called next. Killable: No. Next: onStart().

onStart(): Called when your activity is becoming visible to the user. Followed by onResume() if the activity is brought to the foreground or onStop() if it becomes hidden from the user. Killable: No. Next: onResume() or onStop().

onResume(): Called when the activity will be available for interacting with the user. The activity is at the top of the activity stack at this point. Killable: No. Next: onPause().

onPause(): Called when the system is about to resume a previous activity or if the user has navigated away to another portion of the system, such as by pressing the Home key. This stage is typically used to commit unsaved changes to data that needs to be persisted. If the activity is brought back to the foreground, onResume() is called; if the activity becomes invisible to the user, onStop() is called. Killable: Yes, but only on Gingerbread (2.3) or earlier. Next: onResume() or onStop().

onStop(): Called when the activity is no longer visible to the user because another activity has resumed and is covering this one. This may happen because another activity has started or a previous activity has resumed and is now in the foreground of the activity stack. It’s followed by onRestart() if this activity is returning to interact with the user or by onDestroy() if this activity is going away. Killable: Yes. Next: onRestart() or onDestroy().

onDestroy(): The final call you receive before your activity is destroyed. This method gets called either because the activity is finishing (such as someone calling finish() on it) or because the system is temporarily destroying the activity to reclaim space. You can distinguish between these two with the isFinishing() method, which helps identify whether the method is finishing or the system is killing it. The isFinishing() method is often used inside onPause() to determine whether the activity is pausing or being destroyed. Killable: Yes. Next: Nothing.

The killable indicator at the end of each activity method description notes the activities the Android system can kill at any time and without notice. You should therefore use the onPause() method to complete any clean-up to write persistent data (such as user edits to data) to your storage mechanism.

Recognizing configuration changes

A configuration change is a change that’s made to the screen orientation (for example, if the user moves the screen to the side and back or moves it from portrait to landscape mode or vice versa), the language, or an input device. A configuration change causes your activity to be destroyed while completing the normal activity life cycle: onPause() followed by onStop() and then onDestroy(). After the onDestroy() method is called, the system creates a new instance of the activity to be created, which takes place because resources and layout files and other elements might need to change depending on the current system configuration. For example, an application may look completely different if the user is interacting with it in Portrait mode, as compared to being displayed in Landscape mode (on its side).