Fixed
Status Update
No update yet.
Comments
ub...@gmail.com
Could this also help with the problem where a non-nullable type can be null because nullability is not inferred in the generated Java code? E.g., having a query returning a LiveData<Pojo> but the table of Pojo's is empty so the LiveData will trigger an update with a null value that shouldn't be null (or maybe that is a plain bug).
el...@google.com
ap...@google.com
Actually for that, maybe we can start reading the nullability annotation and respect that?
It might get a bit more complicated with regular returns.
e.g. if you write
@Query(...)
suspend fun getUser(id:String) : User
do we throw NPE if user does not exist? i guess we have to.
So then this would be only for `Flow` and `LiveData` return types and i hope we already handle nullability for `FLow` ?
It might get a bit more complicated with regular returns.
e.g. if you write
@Query(...)
suspend fun getUser(id:String) : User
do we throw NPE if user does not exist? i guess we have to.
So then this would be only for `Flow` and `LiveData` return types and i hope we already handle nullability for `FLow` ?
Description
Component used: Room Version used: 2.2.5 Devices/Android versions reproduced on: N/A
Please clarify the intended usage pattern of InvalidationTracker.addObserver(). It is annotated with @WorkerThread, but the javadoc does not mention any restriction or recommendation about the calling thread. Testing produces no errors either way, code inspection reveals a couple of synchronization blocks as the likely greatest performance detractors.