Home » Android » android – When exactly are onSaveInstanceState() and onRestoreInstanceState() called?

android – When exactly are onSaveInstanceState() and onRestoreInstanceState() called?

Posted by: admin March 11, 2020 Leave a comment

Questions:

The following figure (from the official doc) describes the well-known lifecycle of an Android activity:

enter image description here

On the other hand, when the activity is destroyed by the system (for example because memory needs to be reclaimed), the state of the activity is sometimes automatically saved and restored by means of the methods onSaveInstanceState() and onRestoreInstanceState(), as illustrated by the following figure (also from the official doc):

enter image description here

I’m aware that onSaveInstanceState() is not always called when an activity is about to be destroyed. For example, if it is destroyed because the user has pressed the “back” button, the activity state is not preserved. But in the cases when the state is saved and restored, and onSaveInstanceState() / onRestoreInstanceState() get called, when exactly are they called?

For example, according to the above figures, onRestoreInstanceState() might be called before onStart(), or after onStart() but before onResume(), or after onResume(). Similarly, several possibilities exist for onSaveInstanceState(). So when are they called exactly?

Ideally, what I would like is to see a combined diagram showing the activity lifecycle states and the save/restore methods, if that exists.

How to&Answers:

Per the documentation:

void onRestoreInstanceState (Bundle savedInstanceState)

This method is called between onStart() and onPostCreate(Bundle).

void onSaveInstanceState (Bundle outState)

If called, this method will occur after onStop() for applications targeting platforms starting with Build.VERSION_CODES.P. For applications targeting earlier platform versions this method will occur before onStop() and there are no guarantees about whether it will occur before or after onPause().

Answer:

As per doc1 and doc2

onSaveInstanceState

Prior to Honeycomb, activities were not considered killable until after they
had been paused, meaning that
onSaveInstanceState() was called immediately before onPause().
Beginning with Honeycomb, however, Activities are considered to be
killable only after they have been stopped, meaning that
onSaveInstanceState() will now be called before onStop() instead of
immediately before onPause().

onRestoreInstanceState

This method is called between onStart() and onPostCreate(Bundle) when
the activity is being re-initialized from a previously saved state

Answer:

In addition to already posted answers, there is a subtle change introduced in Android P, which is:

void onSaveInstanceState(Bundle outState)

If called, this method will occur AFTER onStop() for applications targeting platforms starting with P. For applications targeting earlier platform versions this method will occur before onStop() and there are no guarantees about whether it will occur before or after onPause().

Source: docs

As to why this change is introduced, here’s the answer:

… so an application may safely perform fragment transactions in onStop() and will be able to save persistent state later.

Source: docs

Answer:

This is an extra information for onSaveInstanceState(Bundle)

from docs

Do not confuse this method with activity lifecycle callbacks such as
onPause(), which is always called when an activity is being placed in
the background or on its way to destruction, or onStop() which is
called before destruction. One example of when onPause() and onStop()
is called and not this method is when a user navigates back from
activity B to activity A: there is no need to call
onSaveInstanceState(Bundle) on B because that particular instance will
never be restored, so the system avoids calling it. An example when
onPause() is called and not onSaveInstanceState(Bundle) is when
activity B is launched in front of activity A: the system may avoid
calling onSaveInstanceState(Bundle) on activity A if it isn’t killed
during the lifetime of B since the state of the user interface of A
will stay intact.

So it’s default implementation for..

The default implementation takes care of most of the UI per-instance
state for you by calling onSaveInstanceState() on each view in the
hierarchy that has an id, and by saving the id of the currently
focused view (all of which is restored by the default implementation
of onRestoreInstanceState(Bundle)). If you override this method to
save additional information not captured by each individual view, you
will likely want to call through to the default implementation,
otherwise be prepared to save all of the state of each view yourself.

Answer:

String activityState;
@Override 
public void onCreate(Bundle savedInstanceState) {
// call the super class onCreate to complete the creation of activity like 
// the view hierarchy 
super.onCreate(savedInstanceState);

// recovering the instance state 
if (savedInstanceState != null) {
     activityState = savedInstanceState.getString(STATE_KEY);
 } 

   setContentView(R.layout.main_activity);
   mTextView = (TextView) findViewById(R.id.text_view);
} 

//This callback is called only when there is a saved instance previously
saved using
//onSaveInstanceState(). We restore some state in onCreate() while we can
optionally restore
// other state here, possibly usable after onStart() has completed.
// The savedInstanceState Bundle is same as the one used in onCreate().

@Override 
public void onRestoreInstanceState(Bundle savedInstanceState) {
 mTextView.setText(savedInstanceState.getString(STATE_KEY));
  } 


// invoked when the activity may be temporarily destroyed, save the instance 
//state here 
//this method will be called before onstop

@Override 
 public void onSaveInstanceState(Bundle outState) {
    outState.putString(STATE_KEY, activityState);

    // call superclass to save any view hierarchy 
    super.onSaveInstanceState(outState);
}