Status Update
No update yet.
Comments
yb...@google.com
Wow, it seems like a very important bug to fix.
Doing some investigations...
It works fine with CoreTextField as well as BaseTextField.
[Deleted User] <[Deleted User]>
Seems to be a duplicate of
yb...@google.com
It works fine with Material TextFields (both filled and outline) if you use TextFieldValue based overloads.
It doesn't work when you use String based overloads however (both Outline and Filled). I believe this is related to the one-frame lag as we host TextFieldValue internally and proxy only string.
[Deleted User] <[Deleted User]>
Chatted with Anastasia.
We have this code
// "value: String" comes as a param in TextField
TextFieldImpl(
type = TextFieldType.Outlined,
value = textFieldValue,
onValueChange = {
selection = it.selection
composition = it.composition
if (value != it.text) {
onValueChange(it.text)
}
},
and this value is always "" for me, as it's captured my lambda when lambda was created and this lambda is saved and reused by CoreTextField.
Anyway, two things we can do:
- Remove this if and invoke
onValueChangeeverytime, even on the selection change (which we don't care about). This will allow us to workaround quickly and not to let it slip through. - Find and implement the proper fix in CoreTextField
Let me know what you think
yb...@google.com
Updated the details here
ap...@google.com
Just a note that this issue affects String overrides of both material text fields as well as any custom String override text fields that developer might create on top of CoreTextField/BaseTextField.
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();
}
}