take a closer look at the all-important Android Activity lifecycle and how it relates to processes on the platform.
3.1.2 Exploring Activity lifecycle
Every process running on the Android platform is placed on a stack. When you use an
Activity in the foreground, the system process that hosts that Activity is placed at the top of the stack, and the previous process (the one hosting whatever Activity was previously in the foreground) is moved down one notch. This is a key point to under- stand. Android tries to keep processes running as long as it can, but it can’t keep every process running forever because, after all, system resources are finite. So what hap- pens when memory starts to run low or the CPU gets too busy?
UNDERSTANDING HOW PROCESSES AND ACTIVITIES RELATE
When the Android platform decides it needs to reclaim resources, it goes through a series of steps to prune processes (and the activities they host). It decides which ones to get rid of based on a simple set of priorities:
1 The process hosting the foreground Activity is the most important.
2 Any process hosting a visible but not foreground Activity is next in line.
3 Any process hosting a background Activity is next in line.
4 Any process not hosting any Activity (or Service or BroadcastReceiver),
known as an empty process, is last in line.
A very useful tool for development and debugging, especially in the context of pro- cess priority, is the Android Debug Bridge (adb), which you first met in chapter 1. You can see the state of all the running processes in the emulator by issuing the fol- lowing command:
adb shell dumpsys activity
This command will output a lot of information about all the running processes, including the package name, PID, foreground or background status, the current pri- ority, and more.
Because a user can elect to change directions at just about any time—make a phone call, change the screen orientation, respond to an SMS message, decide to stop
The Builder pattern
You may have noticed the usage of the Builder pattern when we added parameters to the AlertDialog we created in the ReviewCriteria class. If you are not familiar with this approach, basically each of the methods invoked, such as AlertDia- log.setMessage() and AlertDialog.setTitle(), returns a reference to itself (this), which means we can continue chaining method calls. This avoids either an extra-long constructor with many parameters or the repetition of the class reference throughout the code. Intents make use of this handy pattern too; it is something you will see time and time again in Android.
using your wonderful stock market analysis application and start playing Android Poker—which in turn can affect overall system resources, all Activity classes have to be able to handle being stopped and shut down at any time. If the process your
Activity is in falls out of the foreground, it is eligible to be killed (it’s not up to you; it’s up to the platform, based on resources and priorities).
To manage this environment, Android applications, and the Activity classes they host, have to be designed a bit differently than what you may be used to. Using a series of event-related callback type methods the Activity class defines, you can set up and tear down state gracefully. The Activity subclasses that you implement (as you saw a bit of with ReviewCriteria in the previous section) override a set of lifecycle methods to make this happen. As we discussed in section 3.1.1, every Activity has to imple- ment the onCreate() method. This is the starting point of the lifecycle. In addition to
onCreate(), most activities will also want to implement the onPause() method, where data and state can be persisted before the hosting process potentially falls out of scope.
The lifecycle methods that the Activity class provides are called in a specific order by the platform as it decides to create and kill processes. Because you, as an application developer, cannot control the processes, you have to rely on your use of the callback lifecycle methods to control state in your Activity classes as they come into the foreground, move into the background, and fall away altogether. This is a very significant, and clever, part of the overall Android platform. As the user makes choices, activities are created and paused in a defined order by the system as it starts and stops processes.
ACTIVITY LIFECYCLE
Beyond onCreate() and on- Pause(), Android provides other distinct stages, each of which is a part of a particular phase of the life of an Activ- ity class. The most com- monly encountered methods and the phases for each part of the lifecycle are shown in figure 3.3.
Each of the lifecycle meth- ods Android provides has a distinct purpose, and each happens during part of the foreground, visible, or entire lifecycle phase. onCreate() onStart() onDestroy() onRestart() onResume() onStop() onPause() Foreground phase Visible phase Entire lifecycle
Figure 3.3 Android Activity lifecycle diagram, showing the methods involved in the foreground and background phases
69