Fixed
Status Update
Comments
il...@google.com <il...@google.com>
sa...@google.com <sa...@google.com>
ap...@google.com <ap...@google.com> #2
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).
il...@google.com <il...@google.com> #3
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` ?
na...@google.com <na...@google.com> #4
From what I can see, there is no nullability annotation in the generated DAO code (as of Room 2.2.0-rc01) when returning LiveData. The result object is declared and returned uninitialized if the cursor is empty. Or I might be reading it wrong.
Description
Component used: lifecycle-livedata-ktx
Version used: 2.3.0-alpha03
StateFlow
SharedFlow
LiveData
created by theasLiveData
extension methods onFlow
in FlowLiveData.kt. It would be nice if the initial value was available asvalue
on the createdLiveData
to help reduce unnecessary UI updates that happen when the values arrive on theFlow
after the lifecycle method responsible for creating the initial view has already finished.Here is a failing test for
StateFlow
that should work, IMHO: