Fixed
Status Update
No update yet.
Comments
cl...@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
na...@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.
zy...@gmail.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()
}
}
Description
Component used: Navigation
Version used: 2.8.5
The
NavDestination.fillInLabelmethodlabelof theNavDestinationwith arguments. However, it does this by (in every case butNavType.ReferenceType) by just callingargs[argName].toString()- e.g., just directly callingtoString()on the object in theSavedStatebundle.While this approach works for simple types, a custom
NavTypemight not store their class directly in the Bundle - for example, if using the@Serializablesupport, it would be stored as aBundle, which means thetoString()is unlikely to actually be what is needed.Instead,
fillInLabelshould take into account theNavTypeand use itsgetmethod to give theNavTypecontrol over exactly the object that is synthesized from the arguments. That way, developers could implement a customtoString()implementation on their object to control how it is displayed in the label.