Fixed
Status Update
Comments
il...@google.com <il...@google.com> #2
Yigit, do you have time to fix it?
reemission of the same liveData is racy
reemission of the same liveData is racy
ha...@gmail.com <ha...@gmail.com>
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #4
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.
il...@google.com <il...@google.com> #5
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()
}
}
an...@google.com <an...@google.com> #6
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)
il...@google.com <il...@google.com> #7
yea sorry immediate does not fix it.
I actually have a WIP fix for it:
https://android-review.googlesource.com/c/platform/frameworks/support/+/1112186
if your case is the one i found (emitting same LiveData multiple times, as shown in #5) you can work around it by adding a dummy transformation.
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData.map {it })
emitSource(subLiveData.map {it} )
}
I actually have a WIP fix for it:
if your case is the one i found (emitting same LiveData multiple times, as shown in #5) you can work around it by adding a dummy transformation.
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData.map {it })
emitSource(subLiveData.map {it} )
}
Description
Version used: 1.1.0-beta01
For any given fragment backstack, if the fragment to be popped off the backstack is the current primary navigation fragment, this results in a NullPointerException on that popped fragment's FragmentManager receiving notification that the primary navigation fragment changed. Because that fragment is being removed, it no longer has a host nor a reference to that host's FragmentManager. Specifically, this happens at androidx.fragment.app.Fragment.performPrimaryNavigationFragmentChanged, line 2662 (mFragmentManager is null).
Example:
fragmentManager.beginTransaction()
.add(containerId, FragmentA())
.commit()
Current backstack:
A (not primary)
Transaction adding a new fragment that is to be a primary nav fragment:
val fragmentB = FragmentB()
fragmentManager.beginTransaction()
.addToBackStack(null)
.setPrimaryNavigationFragment(fragmentB)
.replace(containerId, fragmentB)
.commit()
Current backstack:
A -> B (primary)
If activity.onBackPress() or fragmentManager.popBackStack() is called, as B is being popped, the FragmentManager's primary nav fragment is set to null, and B (that is now removed) notifies its host FragmentManager of this change (which B no longer has a host because it was removed).