Fixed
Status Update
No update yet.
Comments
il...@google.com
ap...@google.com
Thanks for the report - do you have any reproduction steps?
ap...@google.com
Nevermind, this has been fixed and will be available in an upcoming release.
il...@google.com
An unfortunate side effect of this seems to be that the adapter is set to null before any pending fragment animations are completed.
In my project I add a PreferenceFragmentCompat to the backstack, specifying custom enter and exit animations. Now, when the user presses the back button I call FragmentManager.popBackStack() which in turn starts the custom exit animation.
The problem is that popBackstack() internally calls onDestroyView() on the PreferenceFragmentCompat to be removed. The PreferenceFragmentCompat calls unbindPreferences() which calls getListView().setAdapter(null).
The effect is that the list of preference items is cleared instantly before the exit animation even starts! This causes a white flicker and is clearly noticeable, the preference items disappear, then the view fades out.
Could you prevent setAdapter(null) from being called in this scenario? Maybe unregister the data observer instead?
In my project I add a PreferenceFragmentCompat to the backstack, specifying custom enter and exit animations. Now, when the user presses the back button I call FragmentManager.popBackStack() which in turn starts the custom exit animation.
The problem is that popBackstack() internally calls onDestroyView() on the PreferenceFragmentCompat to be removed. The PreferenceFragmentCompat calls unbindPreferences() which calls getListView().setAdapter(null).
The effect is that the list of preference items is cleared instantly before the exit animation even starts! This causes a white flicker and is clearly noticeable, the preference items disappear, then the view fades out.
Could you prevent setAdapter(null) from being called in this scenario? Maybe unregister the data observer instead?
Description
Component used: Lifecycle
Version used: 2.5.0-alpha01
Currently the call to
enableSavedStateHandles()creates aViewModelusing theViewModelStore. This requires that the ViewModelStore be set on any component attempting to make the call, but there are scenarios where the call toenableSavedStateHandlesneeds to happen before that in particular in the Fragment and Navigation components where the call is not immediately made when the object is constructed or sometimes not at all.If we remove the reliance on
SavedStateHandles(and therefore view models), we can lean into theSavedStateProviderAPIs and the call toenableSavedStateHandles()can be made before theViewModelStoreis set.