Fixed
Status Update
Comments
su...@gmail.com <su...@gmail.com> #2
It seems that this ordering is caused by FragmentManager's addAddedFragments()
, which is being removed/reworked as part of
su...@gmail.com <su...@gmail.com> #3
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
il...@google.com <il...@google.com> #4
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 <jb...@google.com> #6
Thank you for the pull request! This has been added internally and will be a part of the next Fragment alpha release.
a....@gmail.com <a....@gmail.com> #7
I know the ticket is closed but ..
if you call getLayoutInflater from onCreate method (not onCreateDialog) you may have a crash.
because getLayoutInflator goes to onGetLayoutInflater and then it can go to onCreateDialog (even though the entry point is onCreate dialog)
if you call getLayoutInflater from onCreate method (not onCreateDialog) you may have a crash.
because getLayoutInflator goes to onGetLayoutInflater and then it can go to onCreateDialog (even though the entry point is onCreate dialog)
Description
When using a method from
DialogFragment
, if you want to get aLayoutInflater
, you should always call thegetLayoutInflater()
Fragment
.Using can return a
LayoutInflater.from(Context)
LayoutInflater
that does not have the correct theme.It would be nice if there was a lint rule, that caught all calls to
LayoutInflater.from(Context)
and suggested to usegetLayoutInflater()
instead.