Fixed
Status Update
Comments
il...@google.com <il...@google.com> #2
My investigation so far:
- When using
setReorderingAllowed(true)
,executeOpsTogether
first executes all of the operations - When
executeOps
callsremoveFragment()
onFirstFragment
it eventually setsmAdded
to false. - The code for handling postponed fragments calls
addAddedFragments()
, which force moves all the fragments to at mostSTARTED
- When
SecondFragment
goes throughattach()
, it finds the target Fragment. In this case, returningFirstFragment
- If a target Fragment is found, it moves it to its expected state.
- Since
mAdded
is false onFirstFragment
, it moves to its expected state -CREATED
(since not added fragments cannot move aboveCREATED
) - By moving to
CREATED
,FirstFragment
's view is destroyed - Only then is
FragmentTransitions.startTransitions
called. - Shared element transtions require both the entering and existing fragment's views to exist, so the shared element transition is ignored as
FirstFragment
's view no longer exists
This whole flow (steps 3 through 9) is being redone in FirstFragment
's view created by keeping it in the new AWAITING_EXIT_EFFECTS
state, rather than immediately moving it to CREATED
) so this will fix itself when the new system is enabled.
I'll leave this open to investigate a temporary workaround.
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #3
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 0462776cb6ba10f9fcba978bbfaaf0e45513f849
Author: Ian Lake <ilake@google.com>
Date: Fri Mar 20 16:59:21 2020
Avoid destroying the target fragment's view too early
When using setReorderingAllowed(true) with a replace
operation that has the incoming fragment with a target
fragment of the outgoing fragment, the new fragment
goes through attach() before transitions are started.
Unconditionally calling moveToExpectedState() when
USE_STATE_MANAGER is false will move the target (i.e.,
the first fragment) all the way down to CREATED since
it is no longer added.
By checking the target's fragment state, we maintain
the guarantee that the target fragment is at least
created when the other fragment is attached without
moving the state downward.
This doesn't affect the USE_STATE_MANAGER case since
the expected state will be AWAITING_EXIT_EFFECTS and
the view won't be destroyed.
Test: new FragmentTransitionTest test
BUG: 152023196
Change-Id: I41f2f8cf3f0a33e846be91f0356adb197be9a386
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentTransitionTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStateManager.java
https://android-review.googlesource.com/1264501
Branch: androidx-master-dev
commit 0462776cb6ba10f9fcba978bbfaaf0e45513f849
Author: Ian Lake <ilake@google.com>
Date: Fri Mar 20 16:59:21 2020
Avoid destroying the target fragment's view too early
When using setReorderingAllowed(true) with a replace
operation that has the incoming fragment with a target
fragment of the outgoing fragment, the new fragment
goes through attach() before transitions are started.
Unconditionally calling moveToExpectedState() when
USE_STATE_MANAGER is false will move the target (i.e.,
the first fragment) all the way down to CREATED since
it is no longer added.
By checking the target's fragment state, we maintain
the guarantee that the target fragment is at least
created when the other fragment is attached without
moving the state downward.
This doesn't affect the USE_STATE_MANAGER case since
the expected state will be AWAITING_EXIT_EFFECTS and
the view won't be destroyed.
Test: new FragmentTransitionTest test
BUG: 152023196
Change-Id: I41f2f8cf3f0a33e846be91f0356adb197be9a386
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentTransitionTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStateManager.java
il...@google.com <il...@google.com> #4
We've added a fix and it'll be available in Fragment 1.3.0-alpha03
Description
Version used: 1.3.0-alpha02
Theme used: Theme.AppCompat.Light.DarkActionBar
Devices/Android versions reproduced on: Google Pixel 4 XL, Android 10 (API 29)
An otherwise working shared element fragment transition will stop working (i.e. not run at all) if `setTargetFragment` is called before. This does not happen when using version 1.2.3
See the sample project for a repro case