Examining the Application Life Cycle - Android Tutorial

The life cycle of an Android application is strictly managed by the system, based on the user’s needs, available resources, and so on. A user may want to launch a web browser, for example, but the system ultimately decides whether to start the application. Although the system is the ultimate manager, it adheres to some defined and logical guidelines to determine whether an application can be loaded, paused, or stopped. If the user is currently working with an activity, the system gives high priority to that application. Conversely, if an activity is not visible and the system determines that an application must be shut down to free up resources, it shuts down the lower-priority application.With Android, resources are more limited, so Androidmust have more control and power over application.

Android runs each application in a separate process, each of which hosts its own virtual machine. This provides a protected-memory environment. By isolating applications to an individual process, the system can control which application deserves higher priority. For example, a background process that’s doing a CPU-intensive task can’t block an incoming phone call.

Specifically, the Android application architecture is component- and integration-oriented. This allows a rich user experience, seamless reuse, and easy application integration, but creates a complex task for the application life-cycle manager.

Android is sensitive to the life cycle of an application and its components. Therefore, you need to understand and handle life-cycle events in order to build a stable application.The processes running your Android application and its components go through various life-cycle events, and Android provides callbacks that you can implement to handle state changes. For starters, you should become familiar with the various life-cycle callbacks for an activity 

Life-Cycle Methods of an Activity

protected void onCreate(Bundle savedInstanceState);
protected void onStart();
protected void onRestart();
protected void onResume();
protected void onPause();
protected void onStop();
protected void onDestroy();

Android calls the onCreate() method when the activity is freshly created. onCreate() is always followed by a call to onStart(), but onStart() is not always preceded by a call to onCreate() because onStart() can be called if your application was stopped. 

When onStart() is called, your activity is not visible to the user, but it’s about to be. onResume() is called after onStart(), just when the activity is in the foreground and accessible to the user. At this point, the user can interact with your activity.When the user decides to move to another activity, the system calls your activity’sonPause() method. 

From onPause(), you can expect either onResume() or onStop() to be called. onResume() is called, for example, if the user brings your activity back to the foreground. onStop() is called if your activity becomes invisible to the user. If your activity is brought back to the foreground after a call to onStop(), then onRestart() is called. If your activity sits on the activity stack but is not visible to the user, and the system decides to kill your activity, onDestroy() is called.

The state model described for an activity appears complex, but you are not required to deal with every possible scenario. You mostly handle onCreate(), onResume(), and onPause(). You handle onCreate() to create the user interface for your activity. In this method, you bind data to your widgets and wire up any event handlers for your UIcomponents. In onPause(), you want to persist critical data to your application’s data store: it’s the last safe method that is called before the system kills your application. onStop() and onDestroy() are not guaranteed to be called, so don’t rely on these methods for critical logic.