Android activity details 3: Saving the activity status

Previous: http://www.bkjia.com/kf/201112/115299.html

Save activity status

In the "acitume lifecycle" section, it is mentioned that when pause and stop are performed, the activity status is kept in the memory. When resume is executed, it starts execution immediately.

The figure on the left shows that the acitry is not destroyed, but the process is stopped and then started. The figure on the right shows that the process of acvitiry is shut down, and the acitry is destroyed and re-created.

When you start a new activity, the current activity may be stopped in the memory or the system will kill the new activity because it requires 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 re-created, it will be restored to the user's last view. So what should we do? In fact, it is not difficult to save the necessary data in onPause (), onStop (), or onDestyroy () as described in the previous section. But now google has a new thing: onSaveInstanceState (). Its name indicates that it is used to save the instance status. This "instance" is not an activity object, it is the process where the activity is located, because the activity is destroyed because the process in which it is located is killed. OnSaveInstanceState () is called when the system feels that activity needs to be killed. It is passed in a parameter: Bundle, which can be considered as a map, Dictionary, or something, use "key-value" to save data.

Now it's a headache again: Can I save data in onPause? Why come another guy? What is the relationship between them? The main purpose of onSaveInstanceState () was to save the activity state-related data. When the system killed the activity, if it wanted the activity to appear exactly the same next time, then it calls this onSaveInstanceState (), otherwise it will not be called. So understand this: onSaveInstanceState () is not always called. For example, if you press return on an activity, it will not be called because the user knows that the activity is to be destroyed, it is not expected that the next time it will look the same as it is now (of course, developers can keep it as a dead face, you have to do this, the system cannot), so you don't need to call onSaveInstanceState (). Now we should understand that in onPause (), onStop (), and onDestroy (), what needs to be saved is that the data needs to be permanently converted, rather than the data used to restore the status, the status data has a special method: onSaveInstanceState ().

Data is stored in a Bundle, and the Bundle is permanently stored by the system. When onCreate () of activity is called again, the previously saved bundle is passed in to restore the last dead state. If the Bundle was not saved in the Last dead state, the value is null.

If you haven't implemented your own onSaveInstanceState (), the controls on the activity may still be saved and restored. The original activity class has implemented onSaveInstanceState (). In the default Implementation of onSaveInstanceState (), all control-related methods are called to save the status of the controls, for example, whether the input text in EditText and CheckBox are selected. However, not all controls can be saved, depending on whether you have assigned a name (android: id) to the control in the layout file ). If you are famous, you can leave it alone.

Since it is ready for use, do we need to implement onSaveInstanceState () on our own ()? This depends on the situation. If a variable in your derived class affects the UI or the behavior of your program, you must save the variable as well, otherwise, you do not need to, but in most cases, you must implement the pilot. By the way, do not forget to call onSaveInstanceState () of the parent class in your implementation ().

Note: Because onSaveInstanceState () is not called every time it is destroyed, do not save the data that requires permanent persistence. The best place to save the data is onPause.

The best way to test the restoration capability of your program is to rotate the screen, and the current activity will be destroyed by the system whenever the screen orientation changes, then re-create (the process should be disabled! -No, right? Low efficiency ).

From the column of nkmnkm