preface

In the last issue of 3 Myths about the Activity Life Cycle, we helped you understand the design basis, existence significance, and matters needing attention of the Activity life cycle by introducing the “process pattern” that is commonly ignored in web articles.

And, at the end of the article I also aimed at the network of three myths, to give you a rumor.

After this introduction, you will have a better understanding of the life cycle.

So in this installment, we will explain the Activity reconstruction mechanism with a real case.

List of articles

  • preface
  • Because the heart is bottomless, and dare not use the state of recovery
  • What is rebuilding? What are the scenarios that trigger the reconstruction?
  • Why design a mechanism for reconstruction? What are the benefits?
  • What is the process of state preservation and recovery? (Key details that 99% of web articles miss)
  • What are the considerations for state preservation and recovery?
  • How do I avoid rebuilds caused by “configuration changes”?
  • To sum up

Because the heart is bottomless, and dare not use the state of recovery

One day, colleague A pushed A new version of the App to the customer. I thought everything would be fine. After all, after A week’s polishing, all functions have become smooth and stable.

Why does this happen? I approached my colleague who wrote the page and asked why.

A colleague said that the problem was that a large number of data persistence operations were performed each time onPause was performed to avoid data loss caused by the App being cut to the background and reclaimed by the system.

Why not manage temporary data directly through the Activity’s state management mechanism?

My colleague said that it was “unreliable” and I felt unsure about it.

… Are there not enough articles online describing the Activity rebuild process and state management? No, when you rebuild, you go onSaveInstanceState and onRestoreInstanceState,

However, there is no in-depth exploration of the details that go into onSaveInstanceState and onRestoreInstanceState, and the key conditions that determine the successful preservation and restoration of the state.

This makes the reader nervous when using the mechanic and not 100% sure that nothing will happen. 👀

So after source code analysis and repeated test, I will “reconstruction mechanism” and “state management mechanism” sorted into this article.

If by the end of reading this article, you have a clear understanding of the origin and rules of both of them, so that you can use them in your future work with 100% confidence, then my efforts have not been wasted ~

What is rebuilding? What are the scenarios that trigger the reconstruction?

The normal life cycle process is the page from normal creation to destruction.

The rebuild process, on the other hand, is the process that causes the page to be destroyed and created again under certain conditions.

The rebuild is usually caused by “system resource reclamation” or “configuration change”.

Highlight 👆 👆 👆

System resource reclamation refers to:

When the App is in background mode, it may be reclaimed due to insufficient system memory.

Pressing the Home button to switch back to the desktop, for example, or answering a call to jump to the phone App, could put the previous App in background mode.

A configuration change refers to:

When the system configuration changes, such as screen orientation, language changes.

Why design a mechanism for reconstruction? What are the benefits?

One: In the case of resource reclamation, saving the state and restoring it when it is used takes up much less resources than the background persistence process.

Second: for configuration changes, such as when the screen orientation changes, only reconstruction, there is a chance to load different views, if the horizontal and vertical screen layout is different.

What is the process of state preservation and recovery?

First, “state” refers to the temporary data that underpins the presentation of UI content.

Such as text in EditText, CheckBox check or not.

The Activity uses onSaveInstanceState and onRestoreInstanceState to save and restore state if and only if a rebuild is initiated.

OnSaveInstanceState is executed before onStop and onRestoreInstanceState after onStart.

Second, an Activity has two data structures for holding state:

One is View States, which is used to store the state of the View.

The second is Instance States, which stores View States and Activity member variables manually saved by the developer in onSaveInstanceState.

When a rebuild is initiated, the Activity automatically saves and restores the state of the View for us. Specific performance is as follows:

When the Activity is onSaveInstanceState, it will automatically collect the state of each View in Hierachy that “implements state saving and recovery methods”. This state data is passed back to each View at onRestoreInstanceState. And return is based on the View ID to match one by one.

Highlight 👆 👆 👆

The View state data will be collected in the View States, and the View States will be collected in the Instance States along with other member variables in the Activity that are specified to be collected, to be restored one by one.

What are the considerations for state preservation and recovery?

In short:

1. In order to save the state successfully, it is required to implement the state saving and recovery method inside the View.

Native Views do it all; Keep that in mind if you’re customizing a View; If a third-party View fails to do so, you can implement the save and restore method by inheriting it.

2. Assign an ID to the View in the layout to successfully restore the state.

Highlight 👆 👆 👆

3. If it is a member variable of the Activity, you need to override the onSaveInstanceState and onRestoreInstanceState methods in addition to the Activity (subclass).

Note:

Overridden in an Activity simply to hold additional member variables. When overriding methods, remember to keep the implementation of the base class (super), which is where the Activity saves and restores View state.

Highlight 👆 👆 👆

How do I avoid rebuilds caused by “configuration changes”?

Configure the Android :configChanges property for the Activity in the manifest file.

Such as attribute value orientation | screenSize corresponds to the rotating screen, locale corresponds to the change of language.

This way, when the configuration changes, instead of causing a rebuild, the onConfigurationChanged callback is used.

To sum up

You can safely save and restore a state by following the key details mentioned in the State Preservation and Recovery Considerations section.

You no longer need to perform heavy persistence operations in onPause or onStop for temporary data.

Copyright statement

This article is issued under the CC signature – Non-commercial Use – No Deduction 4.0 International Agreement.

Copyright © 2019 – present KunMinX

The introduction, train of thought and conclusion of this paper belong to the author KunMinX. When you reference or quote the introduction, train of thought and conclusion of this paper for second creation or full text reprint, you must indicate the link source, otherwise we reserve the right to pursue responsibility.