Android Lifecycle Revised

The Activity class is an essential part of every Android app. Unlike traditional programming paradigms, the Android framework starts code in an Activity instance by invoking callback methods that correspond to specific stages of its lifecycle.

The activity state changes when the user rotates the phone, responds to a notification, or switches to another app. When these state changes happen, Android uses lifecycle callback methods to notify the activity about them.

A simplified illustration of the activity lifecycle

onCreate()

This is the first callback called by the system. The activity is now on CREATED state.

You should perform basic application startup logic that should happen only once for the entire life of the activity, for example, associating the activity to a viewModel.

If you initialize something after onCreate() is called, release or terminate it when onDestroy() is called.

onStart()

This is the second callback called by the system. The activity is now on STARTED state. The activity is visible to the user but not yet interactive.

You should execute code that maintains the UI.

onResume()

This is the third callback called by the system. The activity is now on RESUMED state. The user can now interact with the app. The app stays in this state until something happens to take focus away from the app. Such an event might be, for instance, receiving a phone call, the user’s navigating to another activity, or the device screen’s turning off.

You should implement onResume() to initialize components that you release during onPause()

These 3 commands are called on all activities you instantiate, they’re used to setup and make the activity available to the user. First the method is called, then the state changes. onCreate() is called and after that the activity is on CREATED state. The next 3 methods do that in the reverse order. The state changes to PAUSED and after that onPause() is called.

The state changes

After	Before
onCreate	onDestroy
onStart	onStop
onResume	onPause

onPause()

This is the first callback called to indicate the user is leaving the activity. The activity is now on PAUSED state. It is no longer in the foreground.

onPause() execution is brief and should not be used to perform heavy operations. Don’t use onPause() to save data, make network calls or execute database transactions. These operations should be executed when onStop() is called.

The user might decide to come back to the activity and onResume() will be called. If that doesn’t happen, onStop() is the next method.

onStop()

This is the second callback called to indicate activity might be finishing. The activity is now on STOPPED state. It is no longer visible. This happens every time you open a new activity that covers the whole screen.

You should release almost all resources that aren’t needed while the user is not using it. If needed you should also make network calls or save data to the database.

In some rare cases, the system might kill your process without calling onDestroy(), so it’s important that you use onStop() to release resources that might cause memory leak.

onDestroy()

This is the third and last callback called to indicate activity is finishing. The activity is now on DESTROYED state. This method is called by the system when finish() is called, when the user dismisses the activity or because the configuration changed, for example, the user rotated the device.

What happens when you start another activity? Source

The order of lifecycle callbacks is always the same. Here’s the order of operations that occur when Activity A starts Activity B:

1. Activity A’s onPause() method executes.
2. Activity B’s onCreate(), onStart(), and onResume() methods execute in sequence. (Activity B now has user focus.)
3. Then, if Activity A is no longer visible on screen, its onStop() method executes.

The sequence is always the same, making it easier for developers to manage transitions between them.

When to call the super class?

When overriding any of the methods, you may need to call the super class implementation. The rule of thumb¹² is that

During initialization, you should always call the super class first

During de-initialization, you should do the work first before calling the super class

The post Android Lifecycle Revised first appeared on Victor Brandalise.