Android Programming: The Activity Lifecycle
This chapter is from the book
This chapter is from the book
This chapter is from the book
Every instance of Activity has a lifecycle. During this lifecycle, an activity transitions between three states: running, paused, and stopped. For each transition, there is an Activity method that notifies the activity of the change in its state. Figure 3.1 shows the activity lifecycle, states, and methods.
){kind=link}
Figure 3.1 Activity state diagram
Subclasses of Activity can take advantage of the methods named in Figure 3.1 to get work done at critical transitions in the activity’s lifecycle.
You are already acquainted with one of these methods – onCreate(Bundle). The OS calls this method after the activity instance is created but before it is put on screen.
Typically, an activity overrides onCreate(...) to prepare the specifics of its user interface:
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(...) or any of the other Activity lifecycle methods yourself. You override them in your activity subclasses, and Android calls them at the appropriate time.
Logging the Activity Lifecycle
In this section, you are going to override lifecycle methods to eavesdrop on QuizActivity’s lifecycle. Each implementation will simply log a message informing you that the method has been called.
Making log messages
In Android, the android.util.Log class sends log messages to a shared system-level log. Log has several methods for logging messages. Here is the one that you will use most often in this book:
public static int d(String tag, String msg)
The d stands for “debug” and refers to the level of the log message. (There is more about the Log levels in the final section of this chapter.) The first parameter identifies the source of the message, and the second is the contents of the message.
The first string is typically a TAG constant with the class name as its value. This makes it easy to determine the source of a particular message.
In QuizActivity.java, add a TAG constant to QuizActivity:
Listing 3.1 Adding TAG constant (QuizActivity.java)
public class QuizActivity extends AppCompatActivity {
private static final String TAG = "QuizActivity";
...
}
Next, in onCreate(...), call Log.d(...) to log a message.
Listing 3.2 Adding log statement to onCreate(...) (QuizActivity.java)
public class QuizActivity extends AppCompatActivity {
...
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
Log.d(TAG, "onCreate(Bundle) called");
setContentView(R.layout.activity_quiz);
...
}
}
Now override five more methods in QuizActivity by adding the following after onCreate(Bundle) and before onCreateOptionsMenu(Menu):
Listing 3.3 Overriding more lifecycle methods (QuizActivity.java)
@Override
public void onStart() {
super.onStart();
Log.d(TAG, "onStart() called");
}
@Override
public void onPause() {
super.onPause();
Log.d(TAG, "onPause() called");
}
@Override
public void onResume() {
super.onResume();
Log.d(TAG, "onResume() called");
}
@Override
public void onStop() {
super.onStop();
Log.d(TAG, "onStop() called");
}
@Override
public void onDestroy() {
super.onDestroy();
Log.d(TAG, "onDestroy() called");
}
...
}
Notice that you call the superclass implementations before you log your messages. These superclass calls are required. Calling the superclass implementation before you do anything else is critical in onCreate(...); the order is less important in the other methods.
You may have been wondering about the @Override annotation. This asks the compiler to ensure that the class actually has the method that you are attempting to override. For example, the compiler would be able to alert you to the following misspelled method name:
public class QuizActivity extends AppCompatActivity {
@Override
public void onCreat(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_quiz);
}
...
The Activity class does not have an onCreat(Bundle) method, so the compiler will complain. Then you can fix the typo rather than accidentally implementing QuizActivity.onCreat(Bundle).
Using LogCat
To access the log while the application is running, you can use LogCat, a log viewer included in the Android SDK tools.
When you run GeoQuiz, you should see LogCat appear at the bottom of Android Studio, as shown in Figure 3.2. If LogCat is not visible, select the Android tool window near the bottom of the screen and ensure that the Devices | logcat tab is selected.
)
Figure 3.2 Android Studio with LogCat
Run GeoQuiz and messages will start materializing in LogCat. By default, log statements that are generated with your app’s package name are shown. You will see your own messages along with some system output.
To make your messages easier to find, you can filter the output using the TAG constant. In LogCat, click the filter drop-down box in the top right of the LogCat pane. Notice the existing filter, which is set up to show messages from only your app. Selecting No Filters will show log messages generated from all over the system.
In the filter dropdown, select Edit Filter Configuration. Use the + button to create a brand-new filter. Name the filter QuizActivity and enter QuizActivity in the by Log Tag: field (Figure 3.3).
)
Figure 3.3 Creating a filter in LogCat
Click OK, and only messages tagged QuizActivity will be visible (Figure 3.4).
Three lifecycle methods were called after GeoQuiz was launched and the initial instance of QuizActivity was created.
)
Figure 3.4 Launching GeoQuiz creates, starts, and resumes an activity
(If you are not seeing the filtered list, select the QuizActivity filter from LogCat’s filter dropdown.)
Now let’s have some fun. Press the Back button on the device and then check LogCat. Your activity received calls to onPause(), onStop(), and onDestroy() (Figure 3.5).
)
Figure 3.5 Pressing the Back button destroys the activity
When you pressed the Back button, you told Android, “I’m done with this activity, and I won’t need it anymore.” Android then destroyed your activity. This is Android’s way of being frugal with your device’s limited resources.
Relaunch GeoQuiz. Press the Home button and then check LogCat. Your activity received calls to onPause() and onStop(), but not onDestroy() (Figure 3.6).
)
Figure 3.6 Pressing the Home button stops the activity
On the device, pull up the task manager: On newer devices, press the Recents button next to the Home button (Figure 3.7). On devices without a Recents button, long-press the Home button.
)
Figure 3.7 Home, Back, and Recents buttons
In the task manager, press GeoQuiz and then check LogCat. The activity was started and resumed, but it did not need to be created.
Pressing the Home button tells Android, “I’m going to go look at something else, but I might come back.” Android pauses and stops your activity but tries not to destroy it in case you come back.
However, a stopped activity’s survival is not guaranteed. When the system needs to reclaim memory, it will destroy stopped activities.
Another situation that pauses an activity is when it is obscured from the user, such as by a pop-up window. Even if the window only partially covers the activity, the activity is paused and cannot be interacted with. The activity resumes when the pop-up window is dismissed.
As you continue through the book, you will override the different activity lifecycle methods to do real things for your application. When you do, you will learn more about the uses of each method.