Status Update
Comments
yb...@google.com <yb...@google.com> #2
To use
The issue is happening because, starting from LocalLifecycleOwner
has been moved from androidx.compose.ui
to lifecycle-runtime-compose
, as outlined in their respective release notes. For compatibility reasons, you must update both dependencies.
For context, note these changes were made to enable the utilization of its Compose-based helper APIs beyond Compose UI (such as in
If the issue persists even after updating your Compose UI, please let us know.
Edit: please see
[Deleted User] <[Deleted User]> #3
If this change has made both libraries version dependent, it seems that guide them to the release note so that users will not experience difficulties :)
yb...@google.com <yb...@google.com> #4
lifecycle 2.8.0 is now stable but compose UI 1.7.0 is still in beta.
[Deleted User] <[Deleted User]> #5
Same problem here. Lifecycle 2.8.0
is now stable but Compose UI 1.7.0
is still beta. Of course our Dependabot didn't know about this relationship between dependencies 😬
yb...@google.com <yb...@google.com> #6
Something like that really shouldn't happen... 🤦🏻♂️
ap...@google.com <ap...@google.com> #7
Thats really really bad. I would always expect the latest stable versions to be compatible. Please add this requirement to the changelog or better add a warning at compile time if used with incompatible combinations.
Description
Version used: 2.0.0
Devices/Android versions reproduced on: N/A
In current version of room if I mark method in DAO with @Transaction, and if it uses any disposable e.g. Single, the generated code will throw main thread access exception at runtime.
I would expect one of two behaviours instead:
1. It would be ideal if room could somehow defer start/end transaction to match thread that is used on Disposable, but I can imagine that this can be not possible.
2. To get compile time warning or error that this may be not the correct way of using @Transaction with mix of asynchronous code.
Example of code:
Method in abstract DAO:
@Transaction
open fun upsert(obj: T): Single<Boolean> {
return insert(obj)
.map { true }
.onErrorResumeNext {
if (it is SQLiteConstraintException)
{ update(obj)
.map { true }
} else {
Single.error(it) }
}
.subscribeOn(Schedulers.io()) }
Generated method:
@Override
public Single<Boolean> upsert(Supplier obj) {
__db.beginTransaction();
try {
Single<Boolean> _result = super.upsert(obj);
__db.setTransactionSuccessful();
return _result;
} finally {
__db.endTransaction();
}
}