Understanding the Activity Lifecycle

Photo by MOHI SYED on Pexels.com

Android app development consists of many different technical aspects, all which, when combined create a robust application. One aspect is understanding the Activity Lifecycle. How does the mobile device handle the application when you close the app, rotate the device, have an incoming call or even when it runs out of memory because you have too many things running at once? This is where we look at the Activity lifecycle.

When making an Android application it is important that you understand the Activity lifecycle, especially for a smooth and consistent customer experience. In this post I hope to pass on my understanding of the Activity lifecycle to you, so you can build better apps.

* This is a very simplified description of how the Android Lifecycles work. The intention is to help you break into the topic, i would advise that you follow further reading to get a more technical knowledge.

The Activity Lifecycle

The activity class consists of six callback methods which the Android system invokes when the device enters one of the states.

The Six Callbacks

• onCreate() – when the activity is first created. This is where the setup of the activity occurs, such as setting your layout file, binding data and associating viewModels.
• onStart() – the app prepares to become visible to the user and is ready about to brought to the foreground.
• onResume() – the user can interact with the app in this state. The app only exists this state if the focus from the app is taken away, such as a phone call, thus the app enters the onPause() state.
• onPause() – an indication that the user is leaving the app.
• onStop() – when the app is no longer visible to the user, for example a new Activity covers the entire screen.
• onDestroy() – called just before the Activity is about to be destroyed, either by the user dismissing the app or a configuration change (rotating the device).

Example – Lets say we start an an app on a device, the following events will trigger in order: onCreate(), onStart(), onResume(). Now, theres an incoming call and the call is now in the foreground and the app is in the background. What event’s triggered? Well, just before the call the app would have gone into the state onPause(), pausing the application, next when the incoming call Activity is visible on the screen, the app would have entered the onStop() state. Ok, so phone call over, the app now comes back to the foreground, the following event takes place, the app enters the state of onStart() and then onResume().

Notice, in the example, when the app is brought back to the foreground after the phone call, onCreate() does not get called. This is because the activity is already created, onCreate only gets called on the creation of the Activity, if the app was destroyed by the user or the system then the app would have triggered onCreate().

Fragments have a Lifecycle Too

Similarly to the activity lifecycle, each Fragment has a state which it invokes represented by an enum, which comes from Lifecycle.State.

• INITIALIZED – the intialized state for a lifecycle owner.
• CREATED – the fragment has been created and the onAttach() has been called. This invokes the onCreate() method. The view is not yet visible.
• STARTED – the fragment is available and the onStart() callback is invoked.
• RESUMED – fragment is visible and ready for interaction
• DESTROYED – fragment has been removed or the FragmentManager is destroyed, the state of the lifecycle is moved to DESTROYED.

So why should you care about the Lifecycle?

You may be thinking, why does this whole lifecycle stuff even matter. The Android system just does everything for me, right? Well, sort of.

The Android system may invoke the state, but you need to consider what happens to your application when the system triggers the state. For example, let’s say you have an app where there is a video, the user plays the video and later decides to switch the device to landscape – what would happen? More than likely the video would start playing from the beginning, not from where it left off. Utilising the lifecycle callbacks and viewModels you could simply save the play position of the video within the onPause() function into your videModel. When the app resumes, within onResume() you would get the value of the last play position and continue playback from there.

override fun onPause() {
        super.onPause()
        //save the player position
        viewModel.saveLastVideoPosition = video.playerPosition
    }

    override fun onResume() {
        super.onResume()
        val lastPlayerPosition = viewModel.getLastVideoPosition
        video.playVideo(lastPlayerPosition)
    }

In this post we have talked about the different events that take place when the application enters a certain state in both Activities and Fragments.

Now you know the basics of the activity lifecycle, have a read of the Android developers documentation for a more in-depth look. Happy Dev-ing!