Fixed
Status Update
Comments
co...@gmail.com <co...@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
il...@google.com <il...@google.com>
jb...@google.com <jb...@google.com>
il...@google.com <il...@google.com>
cl...@google.com <cl...@google.com>
co...@gmail.com <co...@gmail.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.
cl...@google.com <cl...@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()
}
}
il...@google.com <il...@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)
na...@google.com <na...@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
In order navigate using "NavDirection" directly created from a ViewModel would it be possible to pass R.string.id as argument?
Imagine a case where multiple errors leads you to a fragment that differs only by its text. Same behavior inside but only information change sightly. You would try to re-use that common part and avoid duplication.
If you try to generate a direction from your ViewModel with argument you won't be able to retrieve context assosiated string to fill the label. So would it be possible to parse a dynamic label's id instead of applying a toString() on it?
Currently if I send a NavDirection with an argument in it which is also {label} it will just apply a toString() and show id in place of toolbar title. Expected is the localised string as title to not resolve it using getString by myself (in a fragment, before or after navigation)
Some snippets from the way I would otherwise do it.
Current work around would be to create one destination per string_id reusing the same fragment "name" attribute and duplicate actions.
This would also remove the need of "getString()" logic from fragment or hook the "onDestinationChanged" as suggested some places just to update a title.