The state of the activity is lost when it is destroyed
Sometimes you may want the activity to be restored to its previous state. An example would be when the user changes the orientation of the device. The current activity is destroyed and restarted.
In cases like this, the user should be unaware that the activity was destroyed and then recreated. They expect it to be in the same state as before. This is why we need to save the activity’s state.
There are two ways of doing this:
- Using Shared preferences
- Using the Lifecycle event handlers
Saving the Crown Jewels: Using Shared Preferences
It is advisable to use Shared Preferences rather than the onSaveInstanceState event handler to save persistent data.
Data saved as a Shared Preference will always be available even if the app is closed.
Use getPreferences() for preferences which are restricted to the calling activity.
Saving the bits and pieces: Using the lifecycle handlers
Android automatically saves the activity’s state with its default implementation of onSaveInstanceState. It saves every view in the layout. The activity is then rebuilt using this saved state.
Sometimes you may want to save extra information. You can do this by overriding the onSaveInstanceState() method.
Save the information in a bundle as name/ value pairs. This bundle is passed on to the activity’s onCreate and onRestoreInstanceState methods.
Saving the State
onSaveInstanceState is implemented by default.
onSaveInstanceState is designed to save the state of the activity if the activity is killed by the Android run time. The state can then be restored in either the onCreate or onRestoreInstanceState methods.
You can call onSaveInstanceState to save additional information about the state of the activity.
Only use onSaveInstanceState to save the transient state of the activity as it is not always called.
Save more persistent data in onPause as it is always called.
When is onSaveInstanceState called?
onSaveInstanceState will always be called when the activity completes its active lifecycle, before it is killed.
When is onSaveInstanceState not called?
onSaveInstanceState is not called if the activity is closed by the user pressing the Back button or programmatically by calling finish().
Restoring the State
onCreate is where we initialize the activity and inflate the User Interface.
It also receives a bundle containing the state of the activity as saved in onSaveInstanceState. You can use this bundle to restore the activity to its previous state in onCreate.
The same bundle is also passed to onRestoreInstanceState where you can also restore the previous state.
When is onCreate called?
onCreate is called once at the start of the activity's full lifetime.
Usually the activity’s state is restored in onCreate but you can also do it in onRestoreInstanceState if you wish.
When is onRestoreInstanceState called?
onRestoreInstanceState is called after onStart() when the activity is being re-initialized from the saved state bundle passed by onSaveInstanceState.
When is onRestoreInstanceState not called?
onRestoreInstanceState is not called if the activity was not killed by the run time (as when the user presses the Back button or the activity closes programmatically using finish()).
onRestoreInstanceState is also not called if there is no bundle to restore a state from.
Save your persistent data in onPause rather than in onSaveInstanceState.
onPause is always called
onPause is always called when the activity is placed in the background or is about to be destroyed.
This is where you can get any persistent data out of the Shared Preference file and use it to restore the activity.
onResume is always called
onResume is called at the start of every activity’s active lifetime.
Check out the tutorial, Saving the Activity's Instance State: A Tutorial. You may also be interested in the Fragments, configuration changes and retaining objects tutorial.
I hope that you have found this tutorial helpful.