Fixed
Status Update
Comments
il...@google.com <il...@google.com> #2
Project: platform/frameworks/support
Branch: androidx-main
commit 57ca221882695bd6a52549f4d9ea3b812e6fe87c
Author: Simon Schiller <simonschiller@users.noreply.github.com>
Date: Mon Mar 22 16:09:30 2021
[GH] [FragmentStrictMode] Detect <fragment> tag usage
## Proposed Changes
- Detect `<fragment>` tag usage inside XML layouts
## Testing
Test: See `FragmentStrictModeTest#detectFragmentTagUsage`
## Issues Fixed
Fixes: 153738235
This is an imported pull request fromhttps://github.com/androidx/androidx/pull/141 .
Resolves #141
Github-Pr-Head-Sha: 4ea052596e4341b9f11bcf335e2bc38045a91f19
GitOrigin-RevId: 62e7487aa4874eef6bb556490e193717cf937251
Change-Id: Iae48578e85e4e4897f806d7ade2e2a660adf9479
M fragment/fragment/api/public_plus_experimental_current.txt
M fragment/fragment/api/restricted_current.txt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/strictmode/FragmentStrictModeTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentLayoutInflaterFactory.java
M fragment/fragment/src/main/java/androidx/fragment/app/strictmode/FragmentStrictMode.java
A fragment/fragment/src/main/java/androidx/fragment/app/strictmode/FragmentTagUsageViolation.java
https://android-review.googlesource.com/1649748
Branch: androidx-main
commit 57ca221882695bd6a52549f4d9ea3b812e6fe87c
Author: Simon Schiller <simonschiller@users.noreply.github.com>
Date: Mon Mar 22 16:09:30 2021
[GH] [FragmentStrictMode] Detect <fragment> tag usage
## Proposed Changes
- Detect `<fragment>` tag usage inside XML layouts
## Testing
Test: See `FragmentStrictModeTest#detectFragmentTagUsage`
## Issues Fixed
Fixes: 153738235
This is an imported pull request from
Resolves #141
Github-Pr-Head-Sha: 4ea052596e4341b9f11bcf335e2bc38045a91f19
GitOrigin-RevId: 62e7487aa4874eef6bb556490e193717cf937251
Change-Id: Iae48578e85e4e4897f806d7ade2e2a660adf9479
M fragment/fragment/api/public_plus_experimental_current.txt
M fragment/fragment/api/restricted_current.txt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/strictmode/FragmentStrictModeTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentLayoutInflaterFactory.java
M fragment/fragment/src/main/java/androidx/fragment/app/strictmode/FragmentStrictMode.java
A fragment/fragment/src/main/java/androidx/fragment/app/strictmode/FragmentTagUsageViolation.java
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.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
Description
Component used: Fragment Version used: 1.3.0-alpha06
When using
setReorderingAllowed(true)
(such as when using the Navigation Architecture Component), doing areplace()
will cause the new fragment to go throughonCreateView()
,onViewCreated()
and potentially up throughonStart()
andonResume()
before the previous fragment is stopped.This means that any values that are set on a shared view model (i.e., when returning a result ) during one of those methods is immediately sent to the other fragment instead of waiting for the user to return to the previous fragment.
Ideally, the previous fragment should be stopped (but specifically not have its view destroyed) prior to the new fragment moving up through lifecycle methods.