When I first starting programming for the Android I was quite confused about the life-cycle of activities. It seemed almost strange how the application started, stopped, and paused without seemingly any logical reasoning. The activity would be destroyed and re-created when the screen was rotated and paused when other applications were started…

I soon learned that having a good grasp on the life-cycle of an activity was critical. Making an efficient application and knowing when to save critical data related to your activities state, let alone restoring your application to a particular state is all a part of the activity life-cycle.

There is a lot of different articles and information available on the internet about the life-cycles of activities. The Google documentation has good information on this as well. But I’m always better at understanding things if I see them for myself.

So I decided that I would write a simple activity that prints out debug statements each time one of the functions of the life-cycle was executed! Then I would be able to see exactly what is happening during each phase and when each function occurs during different situations.

It’s a very simple application, there is literally nothing that it does except print out debug statements on activity changes. Set up a filter in your LogCat called LIFECYCLE to get a clean output of just teh debug statements from this activity.

A couple of things that I found helpful were knowing if the bundle that was passed into the onCreate method had was null or not. This helped me determine when data was being saved and passed back to the activity.

Another item to note is the onRetainNonConfigurationInstance this function can come in handy in situations where you need to retain an object between destroying and re-creating your application. This can be used instead of passing items through a bundle or writing objects out to files or even re-querying a database. The thing you need to remember about this function is when it is called and why. The documentation states that this function is not guaranteed to be called and is only called when configuration changes take place (i.e. screen rotations) – it is not designed for any persistant data storage but is very helpful in retaining objects between activity changes. If you look closely at this function you can save just about anything from threads, network connections, and even images in memory.

Load up the code below and play around, rotate the screen, go to the home screen, start a new activity, click the back button. All these will help you get a better understanding of where and when you should perform certain clean up and data saving routines within the activity life-cycle.

Here’s the code for the whole application put this in the main activity class:

private static final String tag = "LIFECYCLE";

/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);

//Debug check bundle
if(savedInstanceState == null)
Log.d(tag, "onCreate Bundle == null");
else
Log.d(tag, "onCreate Bundle == NOT null");
}

@Override
protected void onPause() {
Log.d(tag,"onPause");
super.onPause();
}

@Override
protected void onResume() {
Log.d(tag,"onResume");
super.onResume();
}

@Override
protected void onStart() {
Log.d(tag,"onStart");
super.onStart();
}

@Override
protected void onStop() {
Log.d(tag,"onStop");
super.onStop();
};

@Override
protected void onRestart() {
Log.d(tag,"onRestart");
super.onRestart();
};

@Override
protected void onDestroy() {
Log.d(tag,"onDestroy");
super.onDestroy();
};

@Override
protected void onSaveInstanceState(Bundle outState) {
Log.d(tag, "OnSaveInstance");
};

@Override
protected void onRestoreInstanceState(Bundle savedInstanceState) {
Log.d(tag, "OnRestoreInstance");
};

@Override
public Object onRetainNonConfigurationInstance() {
Log.d(tag, "OnRetainNonConfig");
return null;
};