Fixed
Status Update
No update yet.
Comments
ap...@google.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).
il...@google.com
mg...@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` ?
ap...@google.com
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.
mg...@google.com
il...@google.com
VOTE +100500
pr...@google.com
Maybe for first step (if kotlin obly project) don generate kotlin class files from java sources and delete Java gen sources. Becouse another annotation processors reread it. I think it's normal what IMPL classes will be only in bin/disassembled modules
Description
Lifecycle.StatefromINITIALIZEDtoDESTROYEDneeding to throw whether there was an observer or not.But attempting to move the
Lifecycle.StatefromDESTROYEDto any other state should throw as well asDESTROYEDis a terminal state for any component that has aLifecycle.