Fixed
Status Update
No update yet.
Comments
jb...@google.com
cl...@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.
ap...@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()
}
}
cl...@google.com
ap...@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)
jb...@google.com
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
Component used: Navigation
Version used: Latest snapshot
Devices/Android versions reproduced on: Any
This bug report is to track the discussion that has started over at
The problem is that in minified builds, even though navigation now has support for enum classes, kotlinx.serialization at that point knows the name of the class before it was obfuscated by r8, and the navigation library is trying to find it by using the obfuscated name. That's my understanding of the issue.
The real effect this has when using the type-safe apis is that one is simply not able to have enums inside their serializable type-safe destinations.
The one workaround which works is to annotate the enum class with
@androidx.annotation.Keep, however this is not mentioned anywhere, there is no compile-time warning for it, nor any lint which could help.I am reporting this here with the hopes that there can be some improvement in this area. Optimally this should "just work", even in minified builds, but if that turns out to be infeasible, perhaps some lint could help us out. And if that is infeasible too, perhaps a special error message at compile time could inform the user that they should use this annotation, or whatever other solution may be considered best.
There is a repro project herehttps://github.com/StylianosGakis/navigation-predictive-back-breaking-shared-element/tree/b401ce64c0d2b48585d92f96f626b970fb01bb4a which as seen here