Fixed
Status Update
No update yet.
Comments
mg...@google.com
mg...@google.com
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).
pr...@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: Lifecycle
Version used: 2.5.0-rc02
Right now methods to create a
ViewModelare marked asMainThread. It would be nice if that limitation was removed andViewModelProvider(and hence the creation of ViewModels) could be made thread safe.This would be particularly helpful for cases such as with the Lifecycle ViewModel Compose API of
viewModel(), which would ensure future compatibility for multi-threaded composition.