Analysis of state saving method in Android programming

This paper describes the method of state saving in Android programming. Share with you for your reference, as follows:

1. When we were texting, we had already written hundreds of words, and then suddenly a phone call came. After we answered the phone, if we found that hundreds of hard-working words were missing, it would be very angry. In fact, these contents were saved. In the process of answering the phone, the activity we sent the message may be recycled by the system. At this time, the onsaveinstancestate callback method of the activity will be called, and we can save the state data in this method and recover the state data in oncreate method or onrestoreinstancestate callback method provided after 2.0.

2. When we are playing the game, we may want to listen to music again, and then we will press the home or back key to exit the game to start the music, and then return to the game. When we return to the game, we find that the state just has been saved. In this case, we can save the state in this way. Save the state data in the onpause method and restore the state in the onresume method.

The state of activity is kept in memory. When resume, it will immediately start execution.

When a user starts a new activity, the current activity may be stopped in memory or killed by the system because the new activity needs more memory. However, when the user presses the return key on the new activity, he wants to see the interface of the original activity. If the original activity is recreated, it should be restored to what the user saw it last. So what do we do? In fact, it's not difficult. As described in the previous section, just save the necessary data in onpause() or onstop() or ondestyroy(). But now Google has come up with a new thing: onsaveinstancestate (), which means by its name: it is specially used to save the instance state. This "instance" does not refer to the activity object, but the process in which it is located, because the destruction of the activity is caused by the killing of the process in which it is located. Onsaveinstancestate() is called when the system feels that it needs to kill an activity. It is passed in a parameter: bundle. This bundle can be regarded as a map, dictionary and other things. The "key value" is used to save data. So what state is called feeling to be killed?

Original words of official documents:

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 know that when an activity becomes "easy" to be destroyed by the system, the onsaveinstancestate of the activity 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 quotation marks above. What is "easy"? The implication is that the activity has not been destroyed, but is only 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 the onsaveinstancestate method will be executed when an activity (assumed to be activity a) is displayed at the top of the current task. There are several cases:

1. When the user presses the home key. It is obvious that the system does not know how many other programs to run after you press 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 analysis of the following situations follows this principle. 2. Long press the home key and choose to run other programs. 3. When you press the power button (turn off the screen display). 4. When starting a new activity from activity a. 5. When the screen direction is switched, for example, when switching from vertical screen to horizontal screen. Before screen switching, the system will destroy activity A. after screen switching, the system will automatically create activity a, so onsaveinstancestate will 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's up to you).

As for onrestoreinstancestate method, it should be noted that onsaveinstancestate method and onrestoreinstancestate method are not necessarily called in pairs.

Onrestoreinstancestate is called on the premise that activity a is "indeed" destroyed by the system. If it is only possible, 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 not be destroyed by the system because of memory, 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. You can also choose to restore data in the oncreate method.

So, isn't it possible to save data in onpause()? Why did you come up with such a guy? What is the relationship between them? Originally, onsaveinstancestate() is mainly used to save data related to the state of an activity. When the system is killing an activity, if it wants the activity to look exactly the same next time, it will call this onsaveinstancestate(), otherwise it will not call. So understand this: onsaveinstancestate () is not always called. For example, when the user presses return on an activity, it will not be called, because the user clearly knows that the activity is to be destroyed, and does not expect it to look the same as it is now next time (of course, the developer can keep its dying expression, and the system can't help it if you have to do so), so there is no need to call onsaveinstancestate(). It should be understood now: in onpause(), onstop() and ondestroy(), what needs to be saved is the data that needs to be persisted, not the data used to restore the state. There is a special method for state data: onsaveinstancestate().

The data is stored in a bundle, which is permanently stored by the system. When oncreate() of activity is called again, the previously saved bundle will be passed in to restore the last dying appearance. If the bundle was not saved at the last death, it will be null.

It's not over yet. If you don't implement your own onsaveinstancestate (), but the appearance of the control on the activity may still be saved and restored. The original activity class has implemented onsaveinstancestate(). In the default implementation of onsaveinstancestate(), it will call the relevant methods of all controls to save the states of the controls, such as the text entered in EditText, Check@R_ 645_ 2419 @ whether it is selected, etc. However, not all controls can be saved, depending on whether you assign a name (Android: ID) to the control in the layout file. The famous exist, and the nameless don't care.

Since there are ready-made, should we implement onsaveinstancestate()? It depends. If a variable in your own derived class affects the UI or the behavior of your program, of course, you need to save this variable, so you need to implement it yourself, otherwise you don't need it, but you certainly need to implement it yourself in most cases. By the way, don't forget to call the parent class onSaveInstanceState () in your implementation.

Note: since onsaveinstancestate() is not called every time it is destroyed, do not save the data that needs to be persisted in it. The best place to save the data is in onpause().

The best way to test the state recovery ability of your program is to rotate the screen. Whenever the direction of the screen changes, the current activity will be destroyed by the system and recreated.

Example code:

More readers interested in Android related content can view the special topics of this site: activity operation skills summary of Android programming, Android view view skills summary, Android operation JSON format data skills summary, introduction and advanced tutorial of Android development, Android resource operation skills summary and Android control usage summary

I hope this article will help you in Android programming.