Status Update
Comments
il...@google.com <il...@google.com> #2
reemission of the same liveData is racy
jo...@gmail.com <jo...@gmail.com> #3
ka...@gmail.com <ka...@gmail.com> #4
[Deleted User] <[Deleted User]> #5
@Test
fun raceTest() {
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData)
emitSource(subLiveData) //crashes
}
subject.addObserver().apply {
testScope.advanceUntilIdle()
}
}
g....@gmail.com <g....@gmail.com> #6
ka...@gmail.com <ka...@gmail.com> #7
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} )
}
g....@gmail.com <g....@gmail.com> #8
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
al...@linguistica360.com <al...@linguistica360.com> #9
If you are using hilt you can wrap the incoming arguments in fragment like so
open class BaseFragment : Fragment() {
override fun setArguments(args: Bundle?) {
if (args != null) {
super.setArguments(Bundle(args).apply {
putBundle(BUNDLE_ARGS, args) // Wrap the arguments as BUNDLE_ARGS
})
} else {
super.setArguments(null)
}
}
}
and then for the view model, you can inherit from something like that
open class ArgsViewModel(private val savedStateHandle: SavedStateHandle) : ViewModel() {
val arguments get() = savedStateHandle.get<Bundle>(BUNDLE_ARGS)
@MainThread
inline fun <reified Args : NavArgs> navArgs() = NavArgsLazy(Args::class) {
arguments ?: throw IllegalStateException("ViewModel $this has null arguments")
}
}
Hope that helps
il...@google.com <il...@google.com>
al...@linguistica360.com <al...@linguistica360.com> #11
Do you know when this will be released?
il...@google.com <il...@google.com> #12
Re #11 - The public hotlist listed at the top of this bug says "androidx-navigation-2.4.0-alpha01" - that's the expected release.
ho...@gmail.com <ho...@gmail.com> #13
It seems this has been included in the
But is there any additional setup required besides updating the navigation dependencies? With the following dependencies on my project
object Navigation {
private const val version = "2.4.0-alpha01"
const val compose = "androidx.navigation:navigation-compose:$version"
const val fragment = "androidx.navigation:navigation-fragment-ktx:$version"
const val safeArgsPlugin = "androidx.navigation:navigation-safe-args-gradle-plugin:$version"
const val ui = "androidx.navigation:navigation-ui-ktx:$version"
}
my safeargs don't generate fromSavedStateHandle()
.
fromBundle()
is still the only auto-complete suggestion.
FooFragmentArgs.fromSavedStateHandle(savedStateHandle)
is an unresolved reference in my ViewModel.
ok...@gmail.com <ok...@gmail.com> #14
Android Studio : 4.2.1
com.android.tools.build:gradle:4.2.1
androidx.navigation:navigation-safe-args-gradle-plugin:2.4.0-alpha01
Is there any thing we can do about this?
il...@google.com <il...@google.com> #15
Re #13, #14 - please upgrade to the latest version of Android Studio and file a bug against Android Studio if you are still not seeing this method in the Studio generated light classes.
ho...@gmail.com <ho...@gmail.com> #16
I'm using Arctic Fox | 2020.3.1 Canary 9. I've just updated Navigation to 2.4.0-alpha02 and still seeing the bug, so I've filed a bug against AS.
ho...@gmail.com <ho...@gmail.com> #17
As mentioned in the linked issue, manually downloading the latest version of Android Studio Preview fixes the issue
Description
androidx.navigation:navigation-safe-args-gradle-plugin:2.0.0
androidx.lifecycle:lifecycle-viewmodel-savedstate:1.0.0-alpha02
Allow SafeArgs to be created `fromSavedStateHandle` as one would from a bundle.