■ In the foreground phase, the Activity is viewable on the screen and on top of everything else (when the user is interacting with the Activity to perform a task).
■ In the visible phase, the Activity is on the screen, but it may not be on top and interacting with the user (when a dialog or floating window is on top of the
Activity, for example).
■ The entire lifecycle phase refers to the methods that may be called when the
application is not on the screen, before it is created, and after it is gone prior to being shut down.
Table 3.1 provides further information about the lifecycle phases and outlines the main high-level related methods on the Activity class.
Beyond the main high-level lifecycle methods outlined in table 3.1, there are further finer-grained methods that are available as well. Methods such as onPostCreate and
onPostResume aren’t normally needed, so we won’t go into detail on them, but be aware that they exist if you need that level of control (see the Activity Javadoc for full method details).
As for the main lifecycle methods that you will use the majority of the time, it is very important to be aware that onPause() is the last opportunity you have to clean up and save state information. The processes that host your Activity classes will not be killed by the platform until after the onPause() method has completed, but they may be killed thereafter. This means the system will attempt to run through all of the lifecycle methods every time, but if resources are spiraling out of control (as determined by the platform), a fire alarm may be sounded and the processes that are hosting activities that are beyond the onPause() method may be killed at any point. Any time your Activity is moved to the background, onPause() is called. Before your Activity is completely removed,
Table 3.1 Android Activity main lifecycle methods and purpose
Method Purpose
onCreate() Called when the Activity is created. Setup is done here, Also provided is access to any previously stored state in the form of a Bundle.
onRestart() Called if the Activity is being restarted, if it is still in the stack, rather than starting new.
onStart() Called when the Activity is becoming visible on the screen to the user. onResume() Called when the Activity starts interacting with the user. (This is always called,
whether starting or restarting.)
onPause() Called when the Activity is pausing or reclaiming CPU and other resources. This method is where state should be saved so that when an Activity is restarted it can start from the same state it had when it quit.
onStop() Called to stop the Activity and transition it to a nonvisible phase and subse- quent lifecycle events.
onDestroy() Called when an Activity is being completely removed from system memory. Hap- pens either because onFinish() is directly invoked or the system decides to stop the Activity to free up resources.
onDestroy() is not guaranteed to have been called (it probably will be called, under normal circumstances, but not always).
The onPause() method is definitely where you need to save persistent state. Whether that persistent state is specific to your application (such as user preferences) or global shared information (such as the contacts database), onPause() is where you need to make sure all the loose ends are tied up—every time. We will discuss how to save data in chapter 5, but here the important thing is to know when and where that needs to happen.
NOTE In addition to persistent state there is one more aspect you should be familiar with, and that is instance state. Instance state refers to the state of the UI itself. The onSave-InstanceState() Activity method is called when an Activity may be destroyed, so that at a future time the inter- face state can be restored. This method is used by the platform to handle the view state processing in the vast majority of cases. This means you normally don’t have to mess with it. Nevertheless, it is important to know that it is there and that the Bundle it saves is handed back to the onCre- ate() method when an Activity is restored. If you need to customize the view state, you can, by overriding this method, but don’t confuse this with the more common general lifecycle methods.
Managing activities with lifecycle events in this way, through parent processes the plat- form controls, allows Android to do the heavy lifting, deciding when things come into and out of scope, relieving applications of the burden themselves, and ensuring a level playing field. This is a key aspect of the platform that varies somewhat from many other application development environments. In order to build robust and responsive Android applications you have to pay careful attention to the lifecycle.
Now that we have some background in place concerning the Activity lifecycle and have created our first screen, we will next further investigate views and fill in some more detail.
3.2
Working with views
Though it is a bit cliché, it is true that views are the building blocks of the UI of an Android application. Activities, as we have seen, contain views, and View objects represent ele- ments on the screen and are responsible for interacting with users through events.
Every Android screen contains a hierarchical tree of View elements. These views come in a variety of shapes and sizes. Many of the views you will need on a day-to-day basis are provided for you as part of the platform—basic text elements, input ele- ments, images, buttons, and the like. In addition, you can create your own composite and/or custom views when the need arises. Views can be placed into an Activity
(and thus on the screen) either directly in code or through the use of an XML resource that is later “inflated” at runtime.
In this section we will discuss fundamental aspects of views: the common views that Android provides, custom views that can be created as needed, layout in relation to views, and event handling. We won’t address views defined in XML here, because that will be covered in section 3.3 as part of a larger resources discussion. Here we begin with the common View elements Android provides by taking a short tour of the API.
71