Status Update
Comments
tp...@gmail.com <tp...@gmail.com> #2
reemission of the same liveData is racy
du...@google.com <du...@google.com> #4
tp...@gmail.com <tp...@gmail.com> #5
@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
fr...@gmail.com <fr...@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} )
}
du...@google.com <du...@google.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
fr...@gmail.com <fr...@gmail.com> #9
You must use paging
3.2.0-alpha01
withpaging-compose:1.0.0-alpha15
.
Ok, then I have a couple of follow ups, in no particular order:
- Is this documented somewhere?
- Why does it not fail at compile time, instead of runtime?
- Why doesn't
paging-compose:1.0.0-alpha15
then force the other dependency to update to3.2.0-alpha01
? - If there is no other way that to fail at runtime, could there be a better error message at least?
il...@google.com <il...@google.com> #10
Re
If you have a sample project where you are not seeing that happen automatically, please attach it here.
il...@google.com <il...@google.com> #12
This is more of an issue with Gradle than anything else - leaving out the dependency on paging-runtime
would automatically upgrade you to the correct version of paging-common
, but your explicit dependency overrides that default behavior.
Gradle does offer the ability to set constrants, which would help enforce this even if you do explicitly set the wrong version. We can add that between paging-common
and paging-compose
.
ap...@google.com <ap...@google.com> #13
Branch: androidx-main
commit e44aa3ffaf00622674ef7dec7ad63be0b03b3f16
Author: Clara Fok <clarafok@google.com>
Date: Tue Jul 19 16:59:26 2022
Add project dependency constraint between paging-common and paging runtime
Added bi-directional project version constraint between paging-common and paging-runtime. If both artifacts are in the dependency tree,
they would have to be on the same version. This is enforced by gradle automatically bumping up the version to meet constraint.
Before constraint added, with direct dependency on paging-runtime:3.1.1 and paging-common:3.2.0-alpha02
+--- androidx.paging:paging-runtime:3.1.1
| +--- androidx.paging:paging-common:3.1.1 -> 3.2.0-alpha02
After constraint with direct dependency on paging-runtime:3.1.1 and paging-common:3.2.0-alpha02
+--- androidx.paging:paging-runtime:3.1.1 -> 3.2.0-alpha02
| +--- androidx.paging:paging-common:3.2.0-alpha02
Test: n/a
Bug: 235256201
Change-Id: I0eb1f099edc626519fa3468e428313b185d105c9
M paging/paging-runtime/build.gradle
M paging/paging-common/build.gradle
ap...@google.com <ap...@google.com> #14
Branch: androidx-main
commit 0b7b59589d3722cc2c4491437f6e27fa0a8d1fc8
Author: Clara Fok <clarafok@google.com>
Date: Tue Jul 19 17:52:02 2022
Add project dependency constraint between paging-common and paging-compose
Added bi-directional project constraint between paging-common and paging-compose. This is necessary because recent features added in common and compose requires these two strict matches:
(common:3.2.0-alpha01) with (compose:1.0.0-alpha15) for
(common:3.2.0-alpha02) with (compose:1.0.0-alpha16) for
As such, project constraint is used to ensure that, regardless of which common version is used, the relevant ToT compose will be set as constraint.
Example: Lower compose version with higher common version
Before constraint added, paging-compose:1.0.0-alpha14 with paging-common:3.2.0-alpha01
+--- androidx.paging:paging-compose:1.0.0-alpha14
+--- androidx.paging:paging-common:3.1.0-beta01 -> 3.2.0-alpha01 (*)
After constraint, paging-compose:1.0.0-alpha14 and paging-common:3.2.0-alpha02
+--- androidx.paging:paging-compose:1.0.0-alpha14 -> 1.0.0-alpha16
+--- androidx.paging:paging-common:3.2.0-alpha02 (*)
Example: Higher compose version with lower common version
Before constraint added, paging-compose:1.0.0-alpha16 with paging-common:3.2.0-alpha01
+--- androidx.paging:paging-compose:1.0.0-alpha16
+--- androidx.paging:paging-common:3.2.0-alpha01
After constraint, paging-compose:1.0-0-alpha16 with paging-common:3.2.0-alpha01
+--- androidx.paging:paging-compose:1.0.0-alpha16
+--- androidx.paging:paging-common:3.2.0-alpha01 -> 3.2.0-alpha02
Test: n/a
Fixes: 235256201
Fixes: 239868768
Change-Id: Ifbe86432341d2d4c18fd105b713f454acdaa5b22
M paging/paging-compose/build.gradle
M paging/paging-common/build.gradle
Description
Hi, encountered java.lang.NoSuchMethodError: crash right after upgrading paging compose version to 1.0.0-alpha15
Upon inspecting the source code locally, noticed that the pagingDataDiffer in class LazyPagingItems is calling the PagingDataDiffer new constructor with mainContext as the named argument.
But the PagingDataDiffer class in the lib is having the old constructor argument mainDispatcher
Component used: Paging Compose
Version used: 1.0.0-alpha15
Devices/Android versions reproduced on: All
Build: AI-212.5712.43.2112.8609683, 202205181650,
AI-212.5712.43.2112.8609683, JRE 11.0.12+0-b1504.28-7817840x64 JetBrains s.r.o., OS Mac OS X(x86_64) v12.4, screens 2880.0x1800.0, 1920.0x1080.0; Retina
AS: Chipmunk | 2021.2.1 Patch 1; Kotlin plugin: 212-1.6.21-release-334-AS5457.46; Android Gradle Plugin: 7.2.1; Gradle: 7.4.1; Gradle JDK: version 11.0.12; NDK: from local.properties: (not specified), latest from SDK: (not found); LLDB: pinned revision 3.1 not found, latest from SDK: (package not found); CMake: from local.properties: (not specified), latest from SDK: 3.18.1-g262b901, from PATH: (not found)
IMPORTANT: Please readhttps://developer.android.com/studio/report-bugs.html carefully and supply all required information.