Avin's Blog

Android Basics: Activity Lifecycle and the difference between UP vs BACK

June 21, 2020
Tags: Android, Android Basics, Github Repository App, Activity Lifecycle,

Since we deal with activities all the time it is important to know the different stages in the lifecycle of an Activity. In the Github Repository App that we have been building, when we go from MainActivity to SettingsActivity and come back to the MainActivity we lose all the data in our RecyclerView similarly when we rotate our phone we lose the data in the RecyclerView.

In both the cases our Activity gets destroyed then recreated and we lose our data. The solution to this is usually saving the data somewhere (using Saved Instance State or fetching data from a database) BEFORE our Activity gets destroyed or using something like ViewModel. Another solution in some cases could be to make sure the Activity is not destroyed.

Activity Lifecycle Overview

An Activity may cycle through multiple stages multiple times. Android provides us with callbacks that are invoked when the Activity enters a new state. I think this illustration from the official docs gives a very good overview:

Activity Lifecycle

Chances of our app being killed by the OS increases the closer we are towards the bottom. The app will almost never be killed in onCreate(), onStart() and onResume(). There is some chance that the app might be killed in onPause() and a very high chance in onStop() and onDestroy. If the data is important saving it in onPause might be a good choice. When the Activity gets destroyed by the OS onSaveInstanceState and onRestoreInstanceState is called which can also be used to store data temporarily.

When we create a new Activity onCreate() is already over overridden for us, similarly we can override the other callbacks and add code to them.

I think the illustration above is enough to get started and a good strategy would be to dive deeper into specific parts when needed.

UP vs BACK

In the Github Repository App right now if we search for a term and then open up settings and come back, our RecyclerView is empty and the data we fetched earlier is lost.

Since SettingsActivity is a child of MainActivity a hierarchy exists and Android knows where to go when the arrow <- is clicked. The MainActivity also has ‘singleTop’ as launchMode and the expected functionality was if there exists an instance of MainActivity use that and do not create a new instance, but I could still not figure out why the Main Activity was recreated every time I navigated away from it.

It turns out when we have parent-child activities the default arrow does not take us BACK, it sends us UP in the hierarchy, to the parent activity.

UP respects hierarchy and takes us to the parent entity, meaning no matter where we come from (any activity or fragment) going up will take us to a predetermined destination.

BACK on the other hand takes us back to wherever we are coming from. It is not dependent on a hierarchy.

The solution to a situation like the one I mentioned above is to override the up/back arrow’s onClick functionality to go back.

In the child activity, in our case the SettingsActivity we override onOptionsItemSelected and call onBackPressed() when home is clicked.

    @Override
    public boolean onOptionsItemSelected(@NonNull MenuItem item) {
        int id = item.getItemId();
        if (id == android.R.id.home) {
            onBackPressed();
            return true;
        }

        return super.onOptionsItemSelected(item);
    }

I did not have to set setDisplayHomeAsUpEnabled to true, since it is enabled by default I think. But if that is not the case for you add the code below in onCreate:

    ActionBar actionBar = getSupportActionBar();
    if (actionBar != null) {
        actionBar.setDisplayHomeAsUpEnabled(true);
    }

And now when we go back, data in the RecyclerView is not lost.

Now that our data persists during the navigation between the activities, we see that when we make changes to the settings the changes are not reflected on our search results. In the next post I will go into how to listen to changes in settings.

As always if you find any errors, have feedback, or just want to say hi leave a comment below.