Fixed
Status Update
No update yet.
Comments
il...@google.com
ap...@google.com
This has been fixed internally and will be available in the next release of Fragments.
ap...@google.com
Sorry, that message is not correct yet.
il...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 47c5e9d30d0304a7d1ac6a522c01a055b858ff28
Author: Jeremy Woods <jbwoods@google.com>
Date: Mon Aug 24 14:47:02 2020
Use view alpha to store the view animation state
Currently when using the new state manager, we save the visibility of
the view from onViewCreated() to do proper effects. This visibility
is restored after onStart() when any special effects are complete.
Because we always restore the visibility to whatever it was in
onViewCreated(), we fail to capture any changes that could have been
made by the user between onViewCreated() and onStart(). This means if
view animating in is set to INVISIBLE in onStart(), we force it back to
VISIBILE once the animation is complete.
Since there are still cases where users set their visibility directly on
their views, we need to ensure we are backward compatible. To do so,
instead of storing the view visibility, we should use the view alpha.
Anything above an alpha of 0 is considered visibile. Doing this means we
can handle the case where the visibility is changed, but the
suggestively more rare case of the alpha changing will suffer from the
old issue.
Test: FragmentViewTest, PostponedTransitionTest
Bug: 164481490
Change-Id: I9df6398af8e0404638e83b69319e4bd32bdbc3f2
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentAnimationTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentAnimatorTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentViewTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/PostponedTransitionTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStateManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/SpecialEffectsController.java
https://android-review.googlesource.com/1404407
Branch: androidx-master-dev
commit 47c5e9d30d0304a7d1ac6a522c01a055b858ff28
Author: Jeremy Woods <jbwoods@google.com>
Date: Mon Aug 24 14:47:02 2020
Use view alpha to store the view animation state
Currently when using the new state manager, we save the visibility of
the view from onViewCreated() to do proper effects. This visibility
is restored after onStart() when any special effects are complete.
Because we always restore the visibility to whatever it was in
onViewCreated(), we fail to capture any changes that could have been
made by the user between onViewCreated() and onStart(). This means if
view animating in is set to INVISIBLE in onStart(), we force it back to
VISIBILE once the animation is complete.
Since there are still cases where users set their visibility directly on
their views, we need to ensure we are backward compatible. To do so,
instead of storing the view visibility, we should use the view alpha.
Anything above an alpha of 0 is considered visibile. Doing this means we
can handle the case where the visibility is changed, but the
suggestively more rare case of the alpha changing will suffer from the
old issue.
Test: FragmentViewTest, PostponedTransitionTest
Bug: 164481490
Change-Id: I9df6398af8e0404638e83b69319e4bd32bdbc3f2
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentAnimationTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentAnimatorTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentViewTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/PostponedTransitionTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStateManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/SpecialEffectsController.java
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.