Use Bundles for saving FragmentManager's hierarchical state [207158202]

Fixed

Bug

androidx-ui-starter-projects

Status Update

No update yet.

Description

il...@google.com

created issue #1

Nov 19, 2021 10:18PM

Component used: Fragment

Version used: 1.4.0

There are tools like toolargetool that let you explore what is taking up space in your saved instance state. However, it has no visibility into custom Parcelables like the FragmentManagerState used to store the entire FragmentManager's hierarchy of saved state.

This makes it hard to differentiate between the state of the FragmentManager itself and the state of each individual fragment, and, within a particular fragment, differentiating the view state, arguments, state provided by onSaveInstanceState(), and the fragment's SavedStateRegistry.

Therefore the focus should be on exposing the hierarchy of fragments - the bookkeeping associated with an individual Fragment and the FragmentManager specific state can and should remain as separate Parcelable instances that don't expose their internal fields.

Comments

il...@google.com <il...@google.com> Jan 11, 2022 08:56PM

Reassigned to sa...@google.com.

ap...@google.com <ap...@google.com> #2Apr 13, 2022 08:29PM

It could easy to reproduce when turning on "Don't keep activities".

ap...@google.com <ap...@google.com> #3Apr 13, 2022 09:20PM

Project: platform/frameworks/support
Branch: androidx-master-dev

commit ba0c19707915ff87d9cac2089fcd166bb5cca17d
Author: Ian Lake <ilake@google.com>
Date: Wed Nov 14 16:20:28 2018

Set the correct FragmentManager on active Fragments

All active Fragments should have the correct
FragmentManager set instead of always using the
Activity's FragmentManager.

While added Fragments have their FragmentManager
set correctly in moveToState(), active Fragments
weren't being set correctly, causing issues when
attempting to save the state of the FragmentManager.

Test: new FragmentLifecycleTest
BUG: 119256498
Change-Id: I830f729d93f00859509a0844fae19752342e6ccc

M fragment/src/androidTest/java/androidx/fragment/app/FragmentLifecycleTest.java
M fragment/src/main/java/androidx/fragment/app/FragmentManagerImpl.java
M fragment/src/main/java/androidx/fragment/app/FragmentState.java

https://android-review.googlesource.com/826954

https://goto.google.com/android-sha1/ba0c19707915ff87d9cac2089fcd166bb5cca17d

ap...@google.com <ap...@google.com> #4Apr 21, 2022 09:55PM

Thanks Ian! Looking forward to a new alpha release ASAP rather than monthly release.😅

ap...@google.com <ap...@google.com> #5May 6, 2022 07:19PM

Thanks for fixing this!

ap...@google.com <ap...@google.com> #6May 19, 2022 08:32PM

Wondering is there any release plan?

ap...@google.com <ap...@google.com> #7May 27, 2022 12:54AM

Fragments 1.1.0-alpha02 is out now with this fix.

ap...@google.com <ap...@google.com> #8Jun 17, 2022 08:06AM

Does Preferences also depend on Fragments? In which case when will that be updated to 1.1.0-alpha02? Or is the recommended practice to specify both Preferences and Fragments in build.gradle so that we can force Fragments 1.1.0-alpha02?

jb...@google.com <jb...@google.com> Jun 17, 2022 04:59PM

Reassigned to jb...@google.com.

il...@google.com <il...@google.com> Jun 21, 2022 09:30PM

Reassigned to il...@google.com.

ap...@google.com <ap...@google.com> #9Jun 23, 2022 11:40PM

Re #8 - yes, if you need a specific version of Fragments, you should specify both Preferences and Fragments in your build.gradle.

The release schedule of AndroidX components is completely independent of one another, so Preferences will only get a new version when there's something new to release in Preferences.

ap...@google.com <ap...@google.com> #10Jun 24, 2022 05:47PM

So, in general it sounds like if an androidx dependency (such as preference) is added to build.gradle, then any dependencies of that (e.g. fragment) should also be explicitly added so that the specific version can be specified. Is that right?

In other words, when we explicitly include preference-1.1.0-alpha01 we need to be aware that the fragment-alpha1.1.0-alpha01 is automatically being brought in and so might affect the fragment behaviour. Sorry, I know this is rather OT.

ap...@google.com <ap...@google.com> #11Jun 24, 2022 05:47PM

Thanks, fix confirmed

ap...@google.com <ap...@google.com> #12Jun 24, 2022 07:01PM

alpha02 version of fragments didn't fix this for me. Is there another solution?

ap...@google.com <ap...@google.com> #13Jun 25, 2022 12:20AM

Re #12 - you're most likely hitting

https://issuetracker.google.com/issues/120814739 - a related but separate issue fixed for alpha03

ap...@google.com <ap...@google.com> #14Jun 25, 2022 12:21AM

Run

ap...@google.com <ap...@google.com> #15Jun 25, 2022 12:21AM

Run

ap...@google.com <ap...@google.com> #16Jun 25, 2022 12:21AM

Run

ap...@google.com <ap...@google.com> #17Jun 25, 2022 12:40AM

This seems to be fixed now.
Using this:

implementation 'androidx.preference:preference:1.1.0-alpha05'

il...@google.com <il...@google.com> #18Jun 27, 2022 11:46PM

Marked as fixed.

The saved state of Fragments has been split entirely between private library state (custom Parcelable classes) and state provided by you, the developer, which is now always stored in a Bundle that allows determining exactly which part of the fragment's state is too large.

The final structure is as follows:

In the Activity's onSaveInstanceState, the "android:support:fragments" key now contains a Bundle that contains the following information:

"state" - the private Parcelable storing the FragmentManager's saved state (e.g., the fragment back stack info)
For each Fragment Result that has been set via setFragmentResult but has not yet been delivered: "result_$name" -> (user defined Bundle)
For each Fragment (where the fragment_id matches the UUIDs found in the debug logging): "fragment_$fragment_id" -> Bundle
- "state" -> the private Parcelable storing the Fragment's saved state (e.g., the class name, max lifecycle, etc.)
- "arguments" -> (Bundle of arguments)
- "savedInstanceState" -> (onSaveInstanceState filled Bundle)
- "registryState" -> (SavedStateRegistry filled Bundle)
- "childFragmentManager" -> The “android:support:fragments” equivalent Bundle of the child FragmentManager, which would lead us recursively down the tree
- "viewState" -> the SparseArray<Parcelable> returned by View.saveHierarchyState representing the Fragment View state
- "viewRegistryState" -> (View SavedStateRegistry filled Bundle)

This will be fully available in Fragment 1.6.0-alpha01.