Fixed
Status Update
No update yet.
Comments
he...@gmail.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 87f4c988b713e43deef88a0df6a31c507f11b4a8
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed May 27 11:20:32 2020
Use setMaxLifecycle for FragmentScenario moveToState
Current FragmentScenario uses ActivityScenario to for the moveToState
method. That means moving to STARTED does not work prior to API 23. This
also means that tests including DialogFragment cannot be moved to
CREATED, only ACTIVITY_CREATED.
This change uses setMaxLifecycle instead, so that FragmentScenario is
decoupled from ActivityScenario and there are no longer any restrictions
on moving to API 23 and DialogFragment's can be properly moved to
CREATED.
Test: ran tests on API 21 device and they passed
Bug: 156527405
Change-Id: I63d5facfcce9875acf06e39029686cb535cc3ea6
M fragment/fragment-testing/src/androidTest/java/androidx/fragment/app/testing/FragmentScenarioDialogFragmentTest.kt
M fragment/fragment-testing/src/androidTest/java/androidx/fragment/app/testing/FragmentScenarioTest.kt
M fragment/fragment-testing/src/main/java/androidx/fragment/app/testing/FragmentScenario.java
https://android-review.googlesource.com/1318600
Branch: androidx-master-dev
commit 87f4c988b713e43deef88a0df6a31c507f11b4a8
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed May 27 11:20:32 2020
Use setMaxLifecycle for FragmentScenario moveToState
Current FragmentScenario uses ActivityScenario to for the moveToState
method. That means moving to STARTED does not work prior to API 23. This
also means that tests including DialogFragment cannot be moved to
CREATED, only ACTIVITY_CREATED.
This change uses setMaxLifecycle instead, so that FragmentScenario is
decoupled from ActivityScenario and there are no longer any restrictions
on moving to API 23 and DialogFragment's can be properly moved to
CREATED.
Test: ran tests on API 21 device and they passed
Bug: 156527405
Change-Id: I63d5facfcce9875acf06e39029686cb535cc3ea6
M fragment/fragment-testing/src/androidTest/java/androidx/fragment/app/testing/FragmentScenarioDialogFragmentTest.kt
M fragment/fragment-testing/src/androidTest/java/androidx/fragment/app/testing/FragmentScenarioTest.kt
M fragment/fragment-testing/src/main/java/androidx/fragment/app/testing/FragmentScenario.java
ad...@google.com
ad...@google.com
This has been fixed internally and will be available in Fragment 1.3.0-alpha07.
al...@gmail.com
Yeah, I'm seeing this issue as well, currently this is the workaround that I've come up with:
// This method is called when hide()/show() methods are called on the transaction. Unfortunately Android doesn't
// propagate it to the child fragments (even though their visibility is affected by the parent visibility), so we
// do it manually.
override fun onHiddenChanged(hidden: Boolean) {
super.onHiddenChanged(hidden)
childFragmentManager.fragments.forEach { it.onHiddenChanged(hidden) }
}
// This method is called when hide()/show() methods are called on the transaction. Unfortunately Android doesn't
// propagate it to the child fragments (even though their visibility is affected by the parent visibility), so we
// do it manually.
override fun onHiddenChanged(hidden: Boolean) {
super.onHiddenChanged(hidden)
childFragmentManager.fragments.forEach { it.onHiddenChanged(hidden) }
}
he...@gmail.com
@4 That actually won't technically fix as isHidden() will technically mismatch with the state passed into the child fragment. Each child fragment legitimately needs to have their state set to hidden.
al...@gmail.com
Yeah, I realized that as I kept working further on it. Nevermind that solution, it doesn't work.
he...@gmail.com
@6 I don't know what the ramifications are, but when you iterate, you can save the "currentState" and then hide them all via a transaction. When restoring to visible, restore to the original state.
il...@google.com
il...@google.com
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit 02290cddca3d5e4dc94e2c5f77a6728ad970b204
Author: Jeremy Woods <jbwoods@google.com>
Date: Thu Oct 07 13:11:45 2021
Dispatch onHiddenChanged to child fragments
When a parent fragment is hidden all of its children will automatically
be hidden, but we never call onHiddenChanged on any of the children.
We should dispatch onHiddenChanged down parent's entire hierarchy and
ensure that `isHidden()` also considers the parent's state.
RelNote: "Parent fragments will now dispatch `onHiddenChanged()` down
their entire hierarchy before launching their own call back."
Test: added test
Bug: 77504618
Change-Id: Iedc201ab435cb963e81bc02d203d4d37ff827e01
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentViewTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStateManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
https://android-review.googlesource.com/1850016
Branch: androidx-main
commit 02290cddca3d5e4dc94e2c5f77a6728ad970b204
Author: Jeremy Woods <jbwoods@google.com>
Date: Thu Oct 07 13:11:45 2021
Dispatch onHiddenChanged to child fragments
When a parent fragment is hidden all of its children will automatically
be hidden, but we never call onHiddenChanged on any of the children.
We should dispatch onHiddenChanged down parent's entire hierarchy and
ensure that `isHidden()` also considers the parent's state.
RelNote: "Parent fragments will now dispatch `onHiddenChanged()` down
their entire hierarchy before launching their own call back."
Test: added test
Bug: 77504618
Change-Id: Iedc201ab435cb963e81bc02d203d4d37ff827e01
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentViewTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStateManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
jb...@google.com
This has been fixed internally and will be available in the Fragment 1.4.0-beta01 release.
Description
2) hide fragment (A)
a) onHiddenChanged() gets called for (A)
b) onHiddenChanged() does not get called for (B)
My expectation would be if the fragment itself is hidden, it's children would also be constituted as hidden. A general workaround would be to never rely on a Fragment's hidden state since if you made your fragment correctly, you wouldn't need to worry about the context in which the fragment is being used (either in a child fragment manager or not). The fact that you have to rely no the context in which the fragment is used makes onHiddenChanged() and isHidden() in most cases useless. This means we are left having to add a OnGlobalLayoutChangeListener and listen for whether the root view of the fragment is visible or not.