|
|
Sermon Ohakwe (@admin) |
Within an Activity’s full lifetime, between creation and destruction, it will go through one or more iterations of the active and visible lifetimes. Each transition will trigger the method handlers described previously. The following sections provide a closer look at each of these lifetimes and the events that bracket them.
The full lifetime of your Activity occurs between the first call to onCreate and the final call to onDestroy. It’s possible, in some cases, for an Activity’s process to be terminated without the onDestroy method being called.
Use the onCreate method to initialize your Activity: Inflate the user interface, allocate references to class variables, bind data to controls, and create Services and threads. The onCreate method is passed a Bundle object containing the UI state saved in the last call to onSaveInstanceState. You should use this Bundle to restore the user interface to its previous state, either in the onCreate method or by over-riding onRestoreInstanceStateMethod.
Override onDestroy to clean up any resources created in onCreate, and ensure that all external con-nections, such as network or database links, are closed.
As part of Android’s guidelines for writing efficient code, it’s recommended that you avoid the creation of short-term objects. Rapid creation and destruction of objects forces additional garbage collection, a process that can have a direct impact on the user experience. If your Activity creates the same set of objects regularly, consider creating them in the onCreate method instead, as it’s called only once in the Activity’s lifetime.
An Activity’s visible lifetimes are bound between calls to onStart and onStop. Between these calls, your Activity will be visible to the user, although it may not have focus and might be partially obscured. Activities are likely to go through several visible lifetimes during their full lifetime, as they move between the foreground and background. While unusual, in extreme cases, the Android run time will kill an Activity during its visible lifetime without a call to onStop.
The onStop method should be used to pause or stop animations, threads, timers, Services, or other processes that are used exclusively to update the user interface. There’s little value in consuming resources (such as CPU cycles or network bandwidth) to update the UI when it isn’t visible. Use the onStart (or onRestart) methods to resume or restart these processes when the UI is visible again.
The onRestart method is called immediately prior to all but the first call to onStart. Use it to imple-ment special processing that you want done only when the Activity restarts within its full lifetime.
The onStart/onStop methods are also used to register and unregister Broadcast Receivers that are being used exclusively to update the user interface. It will not always be necessary to unregister Receiv-ers when the Activity becomes invisible, particularly if they are used to support actions other than updating the UI. You’ll learn more about using Broadcast Receivers in Chapter 5.
The active lifetime starts with a call to onResume and ends with a corresponding call to onPause.
An active Activity is in the foreground and is receiving user input events. Your Activity is likely to go through several active lifetimes before it’s destroyed, as the active lifetime will end when a new Activ-ity is displayed, the device goes to sleep, or the Activity loses focus. Try to keep code in the onPause and onResume methods relatively fast and lightweight to ensure that your application remains respon-sive when moving in and out of the foreground.
Immediately before onPause, a call is made to onSaveInstanceState. This method provides an opportunity to save the Activity’s UI state in a Bundle that will be passed to the onCreate and onRestoreInstanceState methods. Use onSaveInstanceState to save the UI state (such as check button states, user focus, and entered but uncommitted user input) to ensure that the Activity can present the same UI when it next becomes active. During the active lifetime, you can safely assume that onSaveInstanceState and onPause will be called before the process is terminated.
Most Activity implementations will override at least the onPause method to commit unsaved changes, as it marks the point beyond which an Activity may be killed without warning. Depending on your application architecture, you may also choose to suspend threads, processes, or Broadcast Receivers while your Activity is not in the foreground.
The onResume method can be very lightweight. You will not need to reload the UI state here as this is handled by the onCreate and onRestoreInstanceState methods when required. Use onResume to re-register any Broadcast Receivers or other processes you may have stopped in onPause.
The Android SDK includes a selection of Activity subclasses that wrap up the use of common user interface widgets. Some of the more useful ones are listed below:
❑MapActivity Encapsulates the resource handling required to support a MapView widget within an Activity. Learn more about MapActivity and MapView in Chapter 7.
❑ListActivity Wrapper class for Activities that feature a ListView bound to a data source as the primary UI metaphor, and exposing event handlers for list item selection
❑ ExpandableListActivity Similar to the List Activity but supporting an ExpandableListView ❑ ActivityGroup Allows you to embed multiple Activities within a single screen.
Summar y
In this chapter, you learned how to design robust applications using loosely coupled application com-ponents: Activities, Services, Content Providers, Intents, and Broadcast Receivers bound together using the application manifest.
You were introduced to the Android application life cycle, learning how each application’s priority is determined by its process state, which is, in turn, determined by the state of the components within it.
To take full advantage of the wide range of device hardware available and the international user base, you learned how to create external resources and how to define alternative values for specific locations, languages, and hardware configurations.
Next you discovered more about Activities and their role in the application framework. As well as learning how to create new Activities, you were introduced to the Activity life cycle. In particular, you learned about Activity state transitions and how to monitor these events to ensure a seamless user experience.
Finally, you were introduced to some specialized Android Activity classes.
In the next chapter, you’ll learn how to create User Interfaces. Chapter 4 will demonstrate how to use layouts to design your UI before introducing some native widgets and showing you how to extend, modify, and group them to create specialized controls. You’ll also learn how to create your own unique user interface elements from a blank canvas, before being introduced to the Android menu system.
