Activity Lifecycle in Android

This tutorial is about Activity in Android, Activity Lifecycle, Real example use-cases of Activity Lifecycle.

Activity

In Android, an Activity is referred to as one screen in an application. An activity provides the window in which the app draws its UI. An Android app consists of one or more screens or activities.

For example, when we open our Gmail application, then we see our emails on the screen. Those emails are present in an Activity. If we open some particular email, then that email will be opened in some other Activity.

Activities in the system are managed as activity stacks. As a user navigates throughout an app, Android maintains the visited activities in a stack, with the currently visible activity always placed at the top of the stack.

Activity Lifecycle

An Android activity undergoes through a number of states during its whole lifecycle.

An activity has essentially four states:

Running : Activity is visible and interacting with the user.

Paused : Activity is still visible, but no longer interacting with the user.

Stopped : Activity is no longer visible.

Killed : Activity has been killed by the system (low memory) or its finish() method has been called.

To handle these states we should override these seven callbacks onCreate, onStart, onStop, onPause, onResume, onRestart, and onDestroy in our Activity.

The following diagram shows the whole Activity lifecycle:

Activity Lifecycle Methods

The Activity lifecycle consists of 7 methods:

onCreate()

• Called when the activity is first created or the first method that gets called when a user first opens an activity.
• This is where you should do all of your normal static setups: create views, bind data to lists, etc.
• This method also provides you with a Bundle containing the activity’s previously frozen state, if there was one.
• Always followed by onStart().

onRestart()

• Called after onStop() when the current activity is being re-displayed to the user (the user has navigated back to it).

• It will be followed by onStart() and then onResume().

• For activities that are using raw Cursor objects, this is usually the place where the cursor should be requeried (because you had deactivated it in onStop().

onStart()

• Called when the activity is becoming visible to the user (but not ready for user interaction). 

• Called after onCreate(Bundle) or after onRestart() when the activity had been stopped but is now again being displayed to the user.

• Followed by onResume() if the activity comes to the foreground, or onStop() if you call finish() from within this function.

• It’s a good place to put a broadcastReceiver or initialize some state about the UI that should display consistently anytime the user comes back to this activity or to begin drawing visual elements, running animations, etc.

onResume()

• Called when the activity will start interacting with the user.
• At this point, your activity is at the top of its activity stack and ready to receive input.
• Always followed by onPause().
• This is a good place to try to open exclusive-access devices or to get access to singleton resources on platform versions prior to Build.VERSION_CODES.Q .

onPause()

• Called when the activity loses foreground state, is no longer focusable or before transition to stopped/hidden or destroyed state.
• The activity is still visible to user, so it’s recommended to keep it visually active and continue updating the UI.
• Implementations of this method must be very quick (not do a lengthy operation or stop things that consume a noticeable amount of CPU) because the next activity will not be resumed until this method returns.

• This is a good place to try to close exclusive-access devices or to release access to singleton resources on platform versions prior to Build.VERSION_CODES.Q 

• Followed by either onResume() if the activity returns back to the front, or onStop() if it becomes invisible to the user.

onStop()

• Called when the activity is no longer visible to the user.
• This may happen either because a new activity is being started on top, an existing one is being brought in front of this one, or this one is being destroyed.
• This is a good place to stop refreshing UI, running animations, and other visual things.
• Followed by either onRestart() if this activity is coming back to interact with the user, or onDestroy() if this activity is going away.

onDestroy()

• called before the activity is destroyed.

• The system invokes this callback either because:

  1. the activity is finishing (due to the user completely dismissing the activity or due to finish() being called on the activity), or
  2. the system is temporarily destroying the activity due to a configuration change (such as device rotation or multi-window mode)

• This is where the lifecycle components can clean up anything it needs to before the Activity is destroyed.

Activity Lifecycle Use Cases 

Now, let’s see real-life use-cases to understand the lifecycle of an activity.

UseCase 1: Open an Activity and press the Back button

When you first time opens an app or activity, onCreate, onStart, and onResume callbacks will be triggered. 

onCreate -> onStart -> onResume

Now onPause, onStop and onDestroy callbacks have triggered, as soon as we press the back button.

onPause -> onStop -> onDestroy 

UseCase 2: Open an activity and press the Home button

If we press the Home button, our app will be minimized. But it will not be killed. So rather than onDestroy method call, onPause and onStop will be called.

onPause -> onStop 

Now If we reopen the activity again,  onRestart, onStart, and onResume callbacks will be triggered.

onRestart ->onStart -> onResume  

UseCase 3: Open an Activity and Lock the Screen

If we simply turn off the screen (press the power button) while using the app, onPause and onStop methods are called. 

onPause -> onStop  

If we unlock the screen, onRestart, onStart, and onResume callbacks will be triggered.

onRestart ->onStart -> onResume 

UseCase 4: Open an Activity and Phone Ringing

Now if an incoming call comes while running activity and if we receive that call, in this case, onPause and onStop callbacks will be triggered.

onPause -> onStop 

If we disconnect the call, onRestart, onStart, and onResume callbacks will be triggered.

onRestart -> onStart -> onResume 

UseCase 5: Kill the app from the recent app’s tray

When we kill the app from the recent app’s tray, onPause, onStop and onDestroy callbacks will be triggered. 

onPause -> onStop -> onDestroy 

Here onDestroy will kill the instance of the activity. So now when we reopen the activity, it will call onCreate and not onRestart to start the activity.

UseCase 6: Move from one activity to another

In this use case, we will see what happens when we move from one activity to another (let’s say Activity A to Activity B). 

When Activity A will open, the following states are called initially,

onCreate -> onStart -> onResume

Let’s say on click of a button we opened Activity B. While opening Activity B, first, onPause will be called for Activity A and then,

onCreate -> onStart -> onResume

will be called for Activity B and then finally onStop of Activity A will be called.

Now, when we press the back button from Activity B to Activity A, then first, onPause of Activity B is called and then,

onRestart -> onStart -> onResume

gets called for Activity A and it is displayed to the user. Here you can see onRestart gets called rather than onCreate as it is restarting the activity and not creating it.

Then after onResume of Activity A is called, the following methods of Activity B are called and now Activity B is destroyed (removed from activity stack).

onStop -> onDestroy  

UseCase 7: Activity’s  orientation change

When we change the orientation of an Activity while using the app, the following methods get called.

onPause -> onStop -> onDestroy 

After onDestroy, the instance of an Activity gets destroyed and a new instance of activity gets created by calling the following methods.

onCreate -> onStart -> onResume