Status Update
No update yet.
Comments
il...@google.com
ap...@google.com
reemission of the same liveData is racy
co...@protonmail.com
jb...@google.com
co...@protonmail.com
@Test
fun raceTest() {
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData)
emitSource(subLiveData) //crashes
}
subject.addObserver().apply {
testScope.advanceUntilIdle()
}
}
co...@protonmail.com
jb...@google.com
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} )
}
jb...@google.com
co...@protonmail.com
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
ma...@deutschebahn.com
Really? Releasing AGP without being sure home-made libraries are working? ... next this seems to break androidx.core dependency Compiler stops with
public class MyActivity extends AppCompatActivity {
^
class file for androidx.core.content.OnConfigurationChangedProvider not found
because of other changes in androidx.navigation:2.5.0-alpha01 ?!
#madeMyDay ;(
jb...@google.com
Please file an issue with a minimal sample project against the
ma...@deutschebahn.com
might you have unintentionally updated your navigation dependencies
yes, typically I update the nav_version field as proposed documented
I updated AGP from 7.0(.3) to 7.1.0 which forced me to then update navigation stack including safeargs (to 2.5.0alpha01) - you know why, and anyhow I updated updated kotlin from 1.5.30 to 1.6.10 - because this changed too in new AGP databinding deps - before or after, I ran into this compiler mess someone (and I doubt it is the new safeargs) somehow looks for the OnConfigurationChangeProvider which is not released with 2.4.0
It would be more helpful to me if s.o. can validate (or INvalidate) if safeArgs has it's finger in fire or somehow it's transitive dependencies.. yes, perhaps safeargs is not the guilty one in this case just the one I can blame on to be in the front row today. Sorry for that
Feedback you might take with to your next teams of teams: main purpose of this rant is to document the pain your uncoordinated releases in the androidx universe causes in the real world aside some unrealistic, "minimal sample projects" noone has the time to provide. Why don't you provide - "Eat your own dogfood" - US some sample projects that integrate all androidx components without dep problems on an active stable AGP and IntelliJ/Studio on a regular schedule when some androidx team releases a new version. Sounds unrealistic? - so it is to us! The more components your teams release with each transitive-cross dependencies, it's unlikely up to impossible to do regular project maintenance without spending nightmare hours in dependency management!
do...@gmail.com
^
class file for androidx.core.content.OnConfigurationChangedProvider not found
got the same error as you, i tried upgrading agp to 7.1 but it doesn't seem to work
jb...@google.com
Navigation 2.5.0 depends on the newest Activity, which depends on the newest core version were those APIs exist.
If you don't wish to upgrade your core version, you can use the Navigation 2.4.1 release which fixes this bug directly without any other included changes.
Description
Component used: Navigation/SafeArgs Kotlin Version used:
2.4.0-rc01AGP:7.1.0-rc01Kotlin:1.6.10When calling
gw :app:assembleDebugI see the following error (plus stacktrace):Here's my plugins block in
app/b.g.kts:Obviously the error message is incorrect -- KGP is invoked right there at the top 🤔
Happy to provide more info (Gradle Scan, other repo info) privately; just ping me!