Mark Murphy - Beginning Android

• The possibility that you will encounter an error during background processing. For example, if you are gathering information off the Internet, the device might lose connectivity. Alerting the user of the problem via a Notificationand shutting down the background thread may be your best option.

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.

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 Notification.

• 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.

Android will call into your activity as the activity transitions between the four states previously listed, using the methods shown 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 this section when deciding which events to pay attention to and which you can safely ignore.

Note that for all of these, you should chain upward and invoke the superclass’ edition of the method, or Android may raise an exception.

We have been implementing onCreate()in all of our Activity subclasses in every example. This will get called in three situations:

• When the activity is first started (e.g., since a system restart), onCreate()will be invoked with a null parameter.

• If the activity had been running, then sometime later was killed off, onCreate()will be invoked with the Bundlefrom onSaveInstanceState()as a parameter.

• If the activity had been running and you have set up your activity to have different resources based on different device states (e.g., landscape versus portrait), your activity will be re-created and onCreate()will be called.

Here is where you initialize your user interface and set up anything that needs to be done once, regardless of how the activity gets used.

On the other end of the lifecycle, 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 get called if the need for RAM is urgent (e.g., incoming phone call) and that the activity will just get shut down regardless. Hence, onDestroy()is mostly for cleanly releasing resources you obtained in onCreate()(if any).

An activity can come to the foreground either 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, either after being initially launched, being restarted from a stopped state, or after a pop-up dialog (e.g., 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 — mostly, 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., 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 upon 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(), 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 users are, ideally, unaware that this is going on. If, for example, they were using a calculator, and come back to that calculator after an absence, they should see whatever number(s) they were working on originally — unless they themselves 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 get killed off at any time, activities may need to save their state more frequently than one 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 Bundleinto 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 too fancy — just put your data in the Bundleand exit the method.