Android Life Cycle

[beingchinmay]

To understand the Android life cycle it is useful to first understand the states that an Android app user experiences. When users touch an app’s icon, the app is started and becomes visible to the users. While the app is visible, the users can interact with it. This is considered the Resumed or running state. As the users interact with the app, they may be interrupted with a pop-up window, or they may be distracted and not touch the screen for a period of time. If the users stop interacting for a period of time, the app will fade but still be partially visible. In either of these two cases the app enters the Paused state. If the users close the pop-up or touch the screen, the app becomes fully visible again, and the app again enters the Resumed state. If users don’t touch the screen for a longer period of time and the screen goes black, or the user
starts another app so that the original app is no longer visible, the app enters the Stopped state. If users turn on the screen or use the Back button to get back to the app, the app again enters the Resumed state. An app can remain in the Stopped state for quite some time. However, if the device is rebooted or a user runs a number of other apps before coming back to the original app, that app can be Destroyed by the operating system to free up resources for other apps that the user is actually interacting with. To design an app that functions well given this pattern of use, developers must understand what happens as the app enters and leaves these states, as well
as what they should design the app to do in those instances. This requires understanding the Android life cycle.


The Android life cycle begins when a user touches an app’s icon. This action causes the onCreate method in the app’s initial activity to execute. This method includes code to load the screen (called a layout ) associated with the initial activity to load. The developer needs to place code in this method that initializes variables and layout objects to the settings required for the user to begin interacting with the app. After the activity has been created, the onStart method is executed. This method does not have to be implemented but is useful if the app requires certain settings to be the same for every time the app starts, whether it is an initial start after the activity is created or restarted after the activity is brought back from a stopped (but not destroyed) state. After the activity has started, the onResume method is executed. This method also does not have to be implemented but is very useful to return the app to the running state that the app was in before it paused. This includes turning on system services used by the app (for example the GPS or the camera), restarting animations, and any other settings needed to allow users to pick up where they left off.

When a user stops directly interacting with the app, the path to destruction begins. None of the methods executed on the path to destruction have to be implemented. However, they often serve a useful purpose and should be considered. The first method executed is onPause . This method should be used to stop services that the app is using, to stop animations, or to store important state information so that users can start using the app exactly as they left it. If the app is about to become invisible, the onStop method will be executed. This method should make sure important data is permanently stored so that as system resources are consumed by other apps, they are not lost. Finally, if not restarted, the onDestroy method will be executed just before the operating system takes away all the app’s resources. This is your last chance to capture important data before all is lost.