Fixed
Status Update
No update yet.
Comments
il...@google.com
Yigit, do you have time to fix it?
reemission of the same liveData is racy
reemission of the same liveData is racy
ap...@google.com
yea i'll take it.
ap...@google.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.
jb...@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()
}
}
na...@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
Using Compose within Fragments require setting a differenthttps://developer.android.com/jetpack/compose/interop/interop-apis#composition-strategy it is still a common 'gotcha' that developers frequently run into as per feedback we've received from partners (
ViewCompositionStrategy(DisposeOnViewTreeLifecycleDestroyed) so that the composition follows the fragment's view lifecycle. While we do document this behavior inTo prevent developers from making this mistake, we can improve the DevEx by either:
ComposeViewin a fragment (preferred - works for existing implementations)ComposeFragment(less preferred - requires awareness of this new component, also can be confused with fragment-in-compose use case)