After API 28 the order of execution of onSaveInstanceState() and onStop() is changed.

Referring to this paragraph from the documentation:

The reason for that change is the ability to firstly execute fragment transactions and then save state. Referring to this paragraph from the documentation:

• What are the gains after this change?
• Are there other reasons behind this change?

CodePudding user response：

It's indeed a matter of consistency, because method onStop() can still modify the instance state.
When moving onSaveInstanceState() to the end of the timeline, those changes will not be lost.

CodePudding user response：

While I am not a Google employee and have not contributed to this, the change also affected activities if I correctly recall, and I'd imagine the reasoning has to do with the fact that before this change, the call to save the state, was maybe going to happen if/when the Framework considered somewhat appropriate after onPause.

The behavior was quite unpredictable and made the lifecycle methods unreliable to trust.

With (Google Devs) refactoring of the entire FragmentManager and its behavior, this change was most likely driven by consistency. (and unknown to me, perhaps, other technical details we're not familiar with).

In short, the framework is now consistent in the calls, as they are guaranteed to occur after onStop (for API 28 ), which ensures that when you re-create the activity/fragment, the state will be correct (and saved).

Like I mentioned at the beginning, I am not a Google developer, but the way it was before was a clusterf**k of uncertainty, and this change brought some hope to save the Fragment apis from their ultimate demise.

Sometime in the middle of this, using multiple activities was not cool anymore, and we all wanted a single activity with many fragments, and nav component to seamlessly move across the stack (not having to worry to much about "defects" in the original design), as this and many other details were polished across the journey that go us here, to a more stable Fragment platform if you so desire to use it.

Before all these "fixes", the Framework API was prone to many errors and inconsistencies sometimes leading to runtime crashes. I can imagine how this and many other fixes, were aimed at reducing this API to a perfectly functional feature, so that other tools like Navigation Component, Lifecycles, ViewModels, etc. could all work in harmony without having to worry about "oh, the Fragments are special and need further logic to handle its buggy behavior".

Despite all this, Fragments are slowly starting to become "an old thing" as more apps start to incorporate Jetpack Compose.