The Activity Lifecycle

The Activity lifecycle is one of the fundamental concepts of Android development you must familiarize yourself with as a beginner in Android development. You’re  probably asking yourself, what is this lifecycle and why is it important? Well, once you understand how state is managed in Activities, you will (hopefully!) never come face to face with the commonly dreaded screen “rotation problem” that exists in Android.

There exists four different states an Activity can be in: resumed, paused, stopped or non-existent (not in memory). With these states, there are different lifecycle methods which notify the Activity of a change in state.

Activity Life Cycle Methods

 

onCreate()  is called when an Activity is being created. Most of the time, this is where an Activity’s UI is prepared. Activity exists in memory, but is not visible in any way.

onStart() is called after onCreate() . This is where the Activity is about to become visible, but not in focus. Activity exists in memory, is in background.

onResume()  is called when the Activity comes in to the foreground and has focus. Activity exists in memory, is in the foreground (visible).

onPause()  is called when the Activity is in the background and is still visible to the user, but no longer has focus. Activity exists in memory, is in background  (visible).

onStop()  is called when the Activity is no longer visible to the user, but is still in memory. Activity exists in memory, but is no longer visible.

onDestroy()  is called when the Activity is about to be removed from memory. Activity is no longer visible and will be removed from memory.

 

android lifecycle

 

Handling Rotation Changes

An Activity in Android goes through many different Activity lifecycle methods. However, once you rotate the device, or if you prefer the more technical term, make the Activity go through a configuration change, the Activity is destroyed and created again. This will cause the Activity’s UI to revert back to the way it was when onCreate()  was first called. Depending on what kind of data you need to retain on a configuration change, there are a few different methods you have at your disposal to make sure your Activity maintains its UI changes. We will now talk about one of the most basic ways of maintaining state, which is, overriding an Activity’s onSaveInstanceState()  method.

Suppose we have a simple Activity and we want to change its background colour with a button press:

 

 

This code works fine, but what happens when we rotate the device? If we press the button and then rotate the device, the background is reverted back to white instead of maintaining its blue colour. How do we fix this? You may have noticed that isSwitched  is a class variable and when we rotate the screen, it changes back to false. Luckily for us, there is a way to maintain the value assigned to isSwitched  across a configuration change. We will do this by overriding onSaveInstanceState()

Overriding onSaveInstanceState()

 

 

As you can see, we’ve made a few a small changes to the class. The most noticeable is that we have now overridden onSaveInstanceState() . onSaveInstanceState()  is called after onPause()  but before onStop() . But what does this do? Well, it allows us to create and save key-value pairs to a Bundle  which survives configuration changes. When inserting values to a Bundle, you will need both a key as well as the value you wish to save. The key is simply represented by a String and it can be anything you want – constants work best here. However, for saving values, Bundles can only accept primitive data or a limited number of different reference types (including Strings). If you would like to save your own custom Object, it will need to implement Parcelable .

 

We have also added a few lines in our onCreate()  lifecycle method. In order to retrieve our saved value, we should first check if our savedInstanceState  is null . If you attempt you retrieve a value, but it was never saved in onSaveInstanceState() , you will be met with a crash ( NullPointerException ). We should also check if our saved state contains a value matching our key, in this case it’s COLOUR_KEY . After checking both of these cases, we can retrieve our boolean  value by calling getBoolean()  on our savedInstanceState . isSwitched  can be directly assigned to our stored boolean . After all this, the value for isSwitched  will now be correctly saved and our activity will maintain the correct background colour!

 

Further reading

Android docs – Activity Lifecycle

 

 

 

Liked the article? Share it!

Leave a Reply

avatar

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  Subscribe  
Notify of