Fixed
Status Update
Comments
jb...@google.com <jb...@google.com>
ap...@google.com <ap...@google.com> #2
Project: platform/frameworks/support
Branch: androidx-master-dev
commit bf9efd55fff0c729e3ee87258aa4269b6767aeb8
Author: Jeremy Woods <jbwoods@google.com>
Date: Thu Nov 19 13:23:38 2020
Only execute when there are pending operations
We currently always call executePendingOperations() whether or not we
have any pending operations. This results in a call to
executeOperations, which will force cancel any currently running
operations we have.
What we really want is to only executeOperations where there are
actually other pending operations waiting to be run. This change checks
if there are any pending ops before attemping to run them.
RelNote: "Fragments now properly appear when postponed and then
immediately started."
Test: transition FragmentTransitionTest
Bug: 170022857
Change-Id: Ie713bb4f44c5d2432680f2efbb8cdb38a9d26bf2
M fragment/fragment/src/main/java/androidx/fragment/app/SpecialEffectsController.java
M transition/transition/src/androidTest/java/androidx/transition/FragmentTransitionTest.kt
M transition/transition/src/androidTest/java/androidx/transition/TrackingVisibility.java
https://android-review.googlesource.com/1506420
Branch: androidx-master-dev
commit bf9efd55fff0c729e3ee87258aa4269b6767aeb8
Author: Jeremy Woods <jbwoods@google.com>
Date: Thu Nov 19 13:23:38 2020
Only execute when there are pending operations
We currently always call executePendingOperations() whether or not we
have any pending operations. This results in a call to
executeOperations, which will force cancel any currently running
operations we have.
What we really want is to only executeOperations where there are
actually other pending operations waiting to be run. This change checks
if there are any pending ops before attemping to run them.
RelNote: "Fragments now properly appear when postponed and then
immediately started."
Test: transition FragmentTransitionTest
Bug: 170022857
Change-Id: Ie713bb4f44c5d2432680f2efbb8cdb38a9d26bf2
M fragment/fragment/src/main/java/androidx/fragment/app/SpecialEffectsController.java
M transition/transition/src/androidTest/java/androidx/transition/FragmentTransitionTest.kt
M transition/transition/src/androidTest/java/androidx/transition/TrackingVisibility.java
jb...@google.com <jb...@google.com> #3
This has been fixed internally and will be available in the Fragment 1.3.0-beta02
release.
You can verify this by following the 6986935
and switching your fragment dependency to 1.3.0-SNAPSHOT
.
Description
Component used:
Fragment
Version used:
1.3.0-beta01
Devices/Android versions reproduced on:
Google Pixel 4 XL
There are some key components here:
startPostponedEnterTransition
instantly after postponingThe effect is really noticeable when using the MDC transitions since they are currently not handling cancelations gracefully so it leaves the target view with alpha 0.
One fix is to always wait calling
startPostponedEnterTransition
at least one frame by posting to a handler or usingyield()
with Coroutines.You may wonder why I'm calling start instantly and it's because the data is cached: