SoFunction
Updated on 2025-03-11

Android   OnSaveInstanceState and onRestoreInstanceState triggering

Android  onSaveInstanceState and onRestoreInstanceState triggering

Let’s first read a passage on Application Fundamentals:

 Android calls onSaveInstanceState() before the activity becomes vulnerable to being destroyed by the system, but does not bother calling it when the instance is actually being destroyed by a user action (such as pressing the BACK key) 

From this sentence, we can see that when an activity becomes "easy" to be destroyed by the system, the activity's onSaveInstanceState will be executed unless the activity is actively destroyed by the user, for example, when the user presses the BACK key.

Pay attention to the double quotes above, what is "easy"? The implication is that the activity has not been destroyed, but is just a possibility. What are the possibilities? By rewriting the onXXX methods of all life cycles of an activity, including onSaveInstanceState and onRestoreInstanceState methods, we can clearly know when an activity (assuming activity A) will be executed when it is displayed at the top level of the current task. There are several situations:

1. When the user presses the HOME key.

This is obvious. The system does not know how many other programs you want to run after pressing HOME, and naturally does not know whether activity A will be destroyed. Therefore, the system will call onSaveInstanceState to give users the opportunity to save some non-permanent data. The following analysis follows this principle

2. Press and hold the HOME key to select when running other programs.

3. When pressing the power button (off the screen display).

4. When starting a new activity from activity A.

5. When switching the screen direction, for example, when switching from vertical screen to horizontal screen.

Before the screen switch, the system will destroy activity A. After the screen switch, the system will automatically create activity A, so onSaveInstanceState will definitely be executed.

In short, the call of onSaveInstanceState follows an important principle, that is, when the system destroys your activity "without your permission", onSaveInstanceState will be called by the system. This is the responsibility of the system, because it must provide an opportunity for you to save your data (of course if you don't save it, you'll do whatever you want).

As for the onRestoreInstanceState method, it should be noted that the onSaveInstanceState method and the onRestoreInstanceState method are called in pairs (my note: I found out that it was not necessarily called in pairs when debugging last night!)

The premise of onRestoreInstanceState being called is that activity A is "destined" destroyed by the system. If it is just stuck in the case of this possibility, the method will not be called. For example, when activity A is being displayed, the user presses the HOME key to return to the main interface, and then the user returns to activity A. In this case, activity A will generally not be destroyed by the system due to memory reasons, so the onRestoreInstanceState method of activity A will not be executed.

In addition, the bundle parameter of onRestoreInstanceState will also be passed to the onCreate method, and you can also choose to restore data in the onCreate method.

As for the use of these two functions, give the exemplary code (note that the custom code is before or after calling super):

@Override
public void onSaveInstanceState(Bundle savedInstanceState) {
    ("MyBoolean", true);
    ("myDouble", 1.9);
    ("MyInt", 1);
    ("MyString", "Welcome back to Android");
    // etc.
    (savedInstanceState);
}
 
@Override
public void onRestoreInstanceState(Bundle savedInstanceState) {
    (savedInstanceState);
 
    boolean myBoolean = ("MyBoolean");
    double myDouble = ("myDouble");
    int myInt = ("MyInt");
    String myString = ("MyString");
}

Thank you for reading, I hope it can help you. Thank you for your support for this site!