Fixed
Status Update
No update yet.
Comments
il...@google.com
ap...@google.com
Yigit, do you have time to fix it?
reemission of the same liveData is racy
reemission of the same liveData is racy
lu...@ozrunways.com
Thanks for the detailed analysis. This may not be an issue anymore since we've started using Main.immediate there but I' not sure; I'll try to create a test case.
an...@google.com
just emitting same live data reproduces the issue.
@Test
fun raceTest() {
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData)
emitSource(subLiveData) //crashes
}
subject.addObserver().apply {
testScope.advanceUntilIdle()
}
}
@Test
fun raceTest() {
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData)
emitSource(subLiveData) //crashes
}
subject.addObserver().apply {
testScope.advanceUntilIdle()
}
}
il...@google.com
With 2.2.0-alpha04 (that use Main.immediate), the issue seems to be still there (I tested it by calling emitSource() twice, like your test case)
Description
Current behavior: calling setMenuVisibility(false) suppresses calls to that fragment's onCreateOptionsMenu, but still dispatches calls to child fragments' onCreateOptionsMenu methods.
Desired behavior: calling setMenuVisibility(false) also suppresses calls to child fragments' onCreateOptionsMenu methods.
This would simplify using FragmentStateAdapter with nested fragments. Currently we have to manually propagate setMenuVisibility calls down from the parent fragment in the adapter, to it's children. Without doing that, menu items from the child fragments are not removed as the active item changes. I found a bug report with a similar workaround for this here:
If this behavior isn't changed, can I suggest changing the documentation for the setMenuVisibility method to make it clear that it doesn't include child fragments.
Component used: Fragment
Version used: 1.3.0-alpha03
Devices/Android versions reproduced on: Emulator, Android API 29