Android Activity and its Lifecycle

An Activity is one screen of the Android app’s user interface. It provides the window in which the app draws its UI. This window typically fills the screen, but may be smaller than the screen and float on top of other windows. Generally, one activity implements one screen in an app. For instance, one of an app’s activities may implement a Profile screen, while another activity implements a Select Profile Photo screen.

Most apps contain multiple screens, which means they comprise of multiple activities. Each activity can start another activity in order to perform different actions. For example, the home activity in a simple app may provide the screen that shows a message inbox. From there, the home activity might launch other activities that provide screens for tasks like writing sharing messages and opening contacts list.

Creating an Activity

When you create a new Android project in Android Studio the project will contain an Android Activity class already (unless you choose that it should not create an activity).

An activity is a subclass of the Android class android.app.Activity . Here is an example of how an Activity subclass could look:

package com.example.activityLifecycle;
import android.app.Activity;
public class HomeActivity extends Activity {
}

As a user navigates through, out of, and back to your app, the Activity instances in your app transition through different states in their lifecycle. The Activity class provides a number of callbacks that allow the activity to know that a state has changed.

Android Activity Lifecycle

If we look at some Java programs, we will find a main() method to launch the code. However, there is no such concept in Android. Instead of this, the Android system gives us a lifecycle to operate and invoke specific callbacks that correspond to the state of the component. Activity is the main component of the Android application, and it has its own lifecycle.

Good understanding and implementation of Activity lifecycle will ensure that your app:

• Is not consuming resources and draining a battery when there is no need.
• Not crashing if the user switches to another app while using the app.
• Not crashing when the user navigates around the app.
• Is not losing the user progress in the app.

Android Activity Lifecycle Diagram

Here we can see how our Activity goes between different states:

• Not exist
• Not visible. The activity instance created, but it’s not visible.
• Visible & background. Activity is visible, but the user can’t interact with it.
• Visible & foreground. Activity is visible, and the user can interact with it.

Image by Vlad Sonkin

When the activity transitions between stages of the activity lifecycle, the Activity class invokes a core set of six callbacks:

onCreate()

override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
Log.v("onCreate","Activity is Created")
}

• This is the main activity lifecycle callback which fires when the system first creates the activity. It is the first method called when we launch an activity, either via launching the app from the splash screen or Intent.
• You can perform basic application startup logic in this method that should happen only once for the entire life of the activity, for example : setting up a UI, ViewModel initialization, observe LiveData, etc.

At this step, your Activity is yet visible and remains at this state until onCreate() finishes. Then it quickly moves to the next state and call onStart()

onStart()

override fun onStart() {
super.onStart()
Log.v("onStart","Activity is visible and in background")
}

• At this state, our Activity is visible and in background i.e. the user can’t interact with it, like pressing a button or scrolling the list.
• Unlike onCreate(), which is called only once during the lifecycle of Activity, onStart() can be called multiple times. For example, it’s also called when the user opens another activity and then presses the back button.
• The onStart() method completes very quickly and, as with the Created state, the activity does not stay resident in the Started state. Once this callback finishes, the activity enters the Resumed state, and the system invokes the onResume() method.

onResume()

override fun onResume() {
super.onResume()
Log.v("onResume","Activity is visible and in foreground")
}

• At this stage our Activity becomes visible and comes to the foreground. The Activity is in focus, and the user can interact with it in any way. It stays in this state until something takes away the focus from the screen, such as a phone call or user navigates to another activity.
• This is where the lifecycle components can enable any functionality that needs to run while the component is visible and in the foreground, such as starting a camera preview.
• Implement this callback as a counterpart of onPause(). If you release some resources in onPause(), make sure that you initialize them again here, in onResume().

onPause()

override fun onPause() {
super.onPause()
Log.v("onPause","Activity is visible and in background")
}

The system calls this method when our Activity loses the focus, for example:

• A new dialog opens, as long as the activity is still partially visible but not in focus, it remains paused.
• If the user navigates to another activity or enters a multi-window mode. It is the first indication that the user leaves Activity.

This method can be used to release system resources, handles to sensors (like GPS), or any resources that may affect battery life while your activity is paused and the user does not need them. However, a Paused activity may still be fully visible if in multi-window mode. So you should consider using onStop() instead of onPause() to fully release or adjust UI-related resources and operations to better support multi-window mode.

From here, your Activity will move to onStop() if the user navigates away from Activity or onResume() if the user returns to Activity.

onStop()

override fun onStop() {
super.onStop()
Log.v("onStop","Activity is not visible")
}

At this state, our Activity again is not visible. It usually happens when the user navigates to another activity or press the home button.

In this method, the app should release or adjust resources that are not needed while the app is not visible to the user. For example:

• your app might pause animations or switch from fine-grained to coarse-grained location updates.
• If your Activity observes some dynamic data, then we can stop it here, in onStop(). You can also perform massive shutdown operations – save user data to the database or perform network calls.

At this state, Activity is not yet destroyed. The instance lives in the back stack. It means that it remembers all the state inside, including the views state. When the user opens the Activity, the Android system will not create the instance again; instead, it will take it from memory. For example, it will restore the user input if the user entered something into the EditText view, pressed the home button, and then opened the app again.
Using onStop() instead of onPause() ensures that UI-related work continues, even when the user is viewing your activity in multi-window mode.

From this state, we can go to onRestart() if the user navigates to the Activity or onDestroy() if the Activity finished, and we no longer need it.

onDestroy()

override fun onDestroy() {
super.onDestroy()
Log.v("onDestroy","Activity becomes non existing")
}

This is the final callback that the Activity receives. This method is called before the Activity becomes not existent. This callback happens in two cases:

• Configuration change, for example, rotation or change the language from the settings. Android system temporarily destroys and then re-creates the activity with a new configuration.
• Activity is finishing; for example, you manually call finish() from code.

This callback should release all resources that have not yet been released by earlier callbacks such as onStop(). For example: to clean up everything else that has not yet cleaned before.
However, you should not rely on this callback. In case of low memory, the Android system can kill the application process, and then onDestroy() is not called. Instead of this, use onStop() or onPause() to save user data and release/adjust resources.

Android Activity Lifecycle Summary

You probably wouldn’t need to implement all these callbacks. Usually, Activities are not that complex. However, a good understanding and implementation of the Android Activity Lifecycle will help you avoid many pitfalls in your application.