Fixed
Status Update
Comments
lc...@gmail.com <lc...@gmail.com> #2
Yigit, do you have time to fix it?
reemission of the same liveData is racy
reemission of the same liveData is racy
jo...@gmail.com <jo...@gmail.com> #3
yea i'll take it.
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.
jb...@google.com <jb...@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()
}
}
ec...@gmail.com <ec...@gmail.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)
jb...@google.com <jb...@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
Component used: Navigation
Version used: 2.4.0-alpha09
Devices/Android versions reproduced on: Not device dependent, code generation issue
Safeargs plugin on 2.4.0-alpha09 since it implemented this behaviour change below
When generating arguments, Safe Args now puts parameters without default values before those with default values. (I89709, b/198493585)
This bahvious change seesms to cause the side effect of compilation time errors in the genrated argument files. As far as I know this affects both kotlin and java generated files.
e.g.
XML navgraph destination (
NavCompFingerPrintAuthDialogFragment
)As you can see the arguments with no default values are not defined first.
this will generate the argument data object shown below with the behavios change which puts the arguments with no default values first in the constructor.
Now the problem is that in the
NavCompFingerPrintAuthDialogFragmentArgs.fromBundle(bundle: Bundle): NavCompFingerPrintAuthDialogFragmentArgs
companion function does not use named arguments when creating aNavCompFingerPrintAuthDialogFragmentArgs
from a bundle. And it uses the arguments in the order that it was defined in the navgraph and not in the order that theNavCompFingerPrintAuthDialogFragmentArgs
data object expects in its constructor. The same issue also apples for the companion functionfromSavedStateHandle(savedStateHandle: SavedStateHandle):NavCompFingerPrintAuthDialogFragmentArgs
but compilation will fail at the earliest point so it was not reported in the error. But from what i can see in the genrated code, its will have the same problem too.One solution is to just use named arguments for kotlin generated files, but it does not solve the issue for java generated files. So perhaps putting the arguments in the order of the
behavior change
mention above shld solve the issue.