Fixed
Status Update
Comments
il...@google.com <il...@google.com> #2
Yigit, do you have time to fix it?
reemission of the same liveData is racy
reemission of the same liveData is racy
po...@gmail.com <po...@gmail.com> #3
yea i'll take it.
il...@google.com <il...@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.
po...@gmail.com <po...@gmail.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>
jb...@google.com <jb...@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)
po...@gmail.com <po...@gmail.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} )
}
cl...@google.com <cl...@google.com>
ap...@google.com <ap...@google.com> #8
Project: platform/frameworks/support
Branch: androidx-master-dev
commit af12e75e6b4110f48e44ca121466943909de8f06
Author: Yigit Boyar <yboyar@google.com>
Date: Tue Sep 03 12:58:11 2019
Fix coroutine livedata race condition
This CL fixes a bug in liveData builder where emitting same
LiveData source twice would make it crash because the second
emission registry could possibly happen before first one is
removed as source.
We fix it by using a suspending dispose function. It does feel
a bit hacky but we cannot make DisposableHandle.dispose async
and we do not want to block there. This does not mean that there
is a problem if developer disposes it manually since our emit
functions take care of making sure it disposes (and there is
no other way to add source to the underlying MediatorLiveData)
Bug: 140249349
Test: BuildLiveDataTest#raceTest_*
Change-Id: I0b464c242a583da4669af195cf2504e2adc4de40
M lifecycle/lifecycle-livedata-ktx/api/2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/current.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_current.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_current.txt
M lifecycle/lifecycle-livedata-ktx/src/main/java/androidx/lifecycle/CoroutineLiveData.kt
M lifecycle/lifecycle-livedata-ktx/src/test/java/androidx/lifecycle/BuildLiveDataTest.kt
https://android-review.googlesource.com/1112186
https://goto.google.com/android-sha1/af12e75e6b4110f48e44ca121466943909de8f06
Branch: androidx-master-dev
commit af12e75e6b4110f48e44ca121466943909de8f06
Author: Yigit Boyar <yboyar@google.com>
Date: Tue Sep 03 12:58:11 2019
Fix coroutine livedata race condition
This CL fixes a bug in liveData builder where emitting same
LiveData source twice would make it crash because the second
emission registry could possibly happen before first one is
removed as source.
We fix it by using a suspending dispose function. It does feel
a bit hacky but we cannot make DisposableHandle.dispose async
and we do not want to block there. This does not mean that there
is a problem if developer disposes it manually since our emit
functions take care of making sure it disposes (and there is
no other way to add source to the underlying MediatorLiveData)
Bug: 140249349
Test: BuildLiveDataTest#raceTest_*
Change-Id: I0b464c242a583da4669af195cf2504e2adc4de40
M lifecycle/lifecycle-livedata-ktx/api/2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/current.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_current.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_current.txt
M lifecycle/lifecycle-livedata-ktx/src/main/java/androidx/lifecycle/CoroutineLiveData.kt
M lifecycle/lifecycle-livedata-ktx/src/test/java/androidx/lifecycle/BuildLiveDataTest.kt
ap...@google.com <ap...@google.com> #9
Project: platform/frameworks/support
Branch: androidx-main
commit f433d5458950a632900f8a2685ce6eab27272f8c
Author: Clara Fok <clarafok@google.com>
Date: Thu Dec 01 15:52:28 2022
Fix BottomNavView launchSingleTop with NavGraph
NavController previously did not apply launchSingleTop when user repeatedly navigates to the starting destination of a Menu when this starting destination is a NavGraph. This results in the destination being added mulitple times to backstack.
Now NavController checks if the destination is a NavGraph and if so, adds all destinations from the node to its final startDestination (i.e. nested nav graphs) to singleTop.
NavController backstack and Navigator backstacks entries are replaced accordingly upon singleTop navigations.
Test: ./gradlew navigation:navigation-runtime:cC
Bug: 253256629
Relnote: singleTop now works with NavGraph such that if the top destination of the backstack is a NavGraph's startDestination, all destinations starting from original destination to its startDestination will only be added to the top of the backstack once.
Change-Id: Id4bea16aff3dd776826fc6d746475e293eb64b0e
M navigation/navigation-common/src/main/java/androidx/navigation/NavigatorState.kt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
https://android-review.googlesource.com/2283419
Branch: androidx-main
commit f433d5458950a632900f8a2685ce6eab27272f8c
Author: Clara Fok <clarafok@google.com>
Date: Thu Dec 01 15:52:28 2022
Fix BottomNavView launchSingleTop with NavGraph
NavController previously did not apply launchSingleTop when user repeatedly navigates to the starting destination of a Menu when this starting destination is a NavGraph. This results in the destination being added mulitple times to backstack.
Now NavController checks if the destination is a NavGraph and if so, adds all destinations from the node to its final startDestination (i.e. nested nav graphs) to singleTop.
NavController backstack and Navigator backstacks entries are replaced accordingly upon singleTop navigations.
Test: ./gradlew navigation:navigation-runtime:cC
Bug: 253256629
Relnote: singleTop now works with NavGraph such that if the top destination of the backstack is a NavGraph's startDestination, all destinations starting from original destination to its startDestination will only be added to the top of the backstack once.
Change-Id: Id4bea16aff3dd776826fc6d746475e293eb64b0e
M navigation/navigation-common/src/main/java/androidx/navigation/NavigatorState.kt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
cl...@google.com <cl...@google.com> #10
This has been fixed internally and will be available in Navigation 2.6.0-alpha05
pr...@google.com <pr...@google.com> #11
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.navigation:navigation-common:2.6.0-alpha05
androidx.navigation:navigation-runtime:2.6.0-alpha05
Description
Component used: Navigation / NavigationUI Version used: 2.5.2 Devices/Android versions reproduced on: OnePlus 8T / Android 12
I'm using a menu resource file which is bound to a BottomNavigationView. Also I'm setting up the navigation like so
NavigationUI.setupWithNavController(bottomNavigationView, navController, false)
which means I'm using the experimental version of this API.I don't want the state of each menu item to be saved since I want to come back to the respective start destination if a
BottomNavigationView
item gets reselected. So regardless of how deep I got in a navigation graph a reselection of the same item takes you back to the start destination.I'm using a navGraph which consists of several nested navGraphs like so:
The
one_navigation
could look like this:It works pretty good so far, the point is when I click the first BottomNavigationView's menu item
N times
I got the destinationN+1 times
on my back stack. If I wanted to leave the app by triggering the system's back navigation I'd have to do itN+1 times
.So I actually expect the startDestination to only exist once on the back stack regardless of how often I click the respective menu item setup with the above mentioned API.