Na documentação do ViewModel
No entanto, os objetos ViewModel nunca devem observar mudanças nos observáveis que reconhecem o ciclo de vida, como objetos LiveData.
Outra maneira é os dados implementarem RxJava em vez de LiveData, então não terão o benefício de serem cientes do ciclo de vida.
Na amostra do google de todo-mvvm-live-kotlin , ele usa um retorno de chamada sem LiveData em ViewModel.
Eu estou supondo que se você deseja cumprir com a ideia de ser um software de ciclo de vida, precisamos mover o código de observação em Activity / Fragment. Caso contrário, podemos usar callback ou RxJava em ViewModel.
Outro compromisso é implementar MediatorLiveData (ou Transformations) e observar (colocar sua lógica aqui) em ViewModel. Observe que o observador MediatorLiveData não disparará (o mesmo que Transformations), a menos que seja observado em Activity / Fragment. O que fazemos é colocar um vazio observe em Activity / Fragment, onde o trabalho real é realmente feito em ViewModel.
fun start(id : Long) : LiveData<User>? {
val liveData = MediatorLiveData<User>()
liveData.addSource(dataSource.getById(id), Observer {
if (it != null) {
}
})
}
viewModel.start(id)?.observe(this, Observer {
})
PS: Eu li ViewModels e LiveData: Patterns + AntiPatterns que sugeriam Transformations. Não acho que funcione a menos que o LiveData seja observado (o que provavelmente requer que seja feito em Activity / Fragment).