Fixed
Status Update
No update yet.
Comments
il...@google.com
It seems that this ordering is caused by FragmentManager's addAddedFragments(), which is being removed/reworked as part of
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 4ea7d82a7e17dd5a20aa0d581add0ba34874e485
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 20 17:12:55 2020
Ensure fragments move to the expected state in op order
When using the new FragmentStateManager, we
should ensure that fragments move to their expected
state in the same order as the underlying operations -
i.e., in the order that they were added to the
FragmentTransaction.
This ensures that replace()'d fragments are stopped
before their replacement fragments move through
lifecycle methods, avoiding cases where both fragments
are simultaneously started.
Due to how the previous code works, this fix *only*
applies when using the new FragmentStateManager.
Test: new FragmentReorderingTest passes
BUG: 161654580
Change-Id: I32662cf3ec8bc5bd9a232b2572c91b5567a47f2f
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentReorderingTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
https://android-review.googlesource.com/1367610
Branch: androidx-master-dev
commit 4ea7d82a7e17dd5a20aa0d581add0ba34874e485
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 20 17:12:55 2020
Ensure fragments move to the expected state in op order
When using the new FragmentStateManager, we
should ensure that fragments move to their expected
state in the same order as the underlying operations -
i.e., in the order that they were added to the
FragmentTransaction.
This ensures that replace()'d fragments are stopped
before their replacement fragments move through
lifecycle methods, avoiding cases where both fragments
are simultaneously started.
Due to how the previous code works, this fix *only*
applies when using the new FragmentStateManager.
Test: new FragmentReorderingTest passes
BUG: 161654580
Change-Id: I32662cf3ec8bc5bd9a232b2572c91b5567a47f2f
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentReorderingTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
ap...@google.com
This has been fixed internally and will be avilable in Fragment 1.3.0-alpha08.
Note: this fix relies on using the
jb...@google.com
This has been fixed internally and will be available in the Fragment 1.7.0-alpha09 release.
na...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.wear.protolayout:protolayout-material-core:1.1.0-rc01androidx.wear.tiles:tiles-tooling:1.3.0-rc01androidx.wear.tiles:tiles-tooling-preview:1.3.0-rc01
Description
Using Compose within Fragments require setting a differenthttps://developer.android.com/jetpack/compose/interop/interop-apis#composition-strategy it is still a common 'gotcha' that developers frequently run into as per feedback we've received from partners (
ViewCompositionStrategy(DisposeOnViewTreeLifecycleDestroyed) so that the composition follows the fragment's view lifecycle. While we do document this behavior inTo prevent developers from making this mistake, we can improve the DevEx by either:
ComposeViewin a fragment (preferred - works for existing implementations)ComposeFragment(less preferred - requires awareness of this new component, also can be confused with fragment-in-compose use case)