Architecture ViewModel — a half baked solution?

Architecture component is the way recommended by Google. It’s an MVVM approach, where it’s supposed to provide 3 solutions as below.
If you are unfamiliar with Architecture Component, you could refer to this simple tutorial, Architecture for Dummies.

- The LiveData — Where our activity/fragment will listen to for new data provided by the ViewModel (or any helper class you made). It is basically a minimal version of RxJava, but does know about the activity/fragment’s lifecycle. This delinks the
- The LifecycleObserver — Once a class implements it, the function that is annotated with appropriate
@OnLifecycleEvent
will be triggered upon the respective life cycle - The ViewModel — This is suppose to be the an object that outlive the Activity/Fragment, where onConfiguration change, the state it is in, is retained. Hence giving an impression we no longer need to save state anymore.
LiveData
and LifecycleObserver
is great as it decouple the ViewModel from the Activity/Fragment, yet having them related.
The half baked ViewModel
The way ViewModel is created is through this ViewModelProviders factory class as below.
val model by lazy {
ViewModelProviders.of(this)[MyViewModel::class.java]
}
We do this instead of instantiating our own MyViewModel()
, is so that it could outlive the Activity/Fragment owning it in onConfiguration change.
This may looks cool, as now when we rotate the device, all our data in the ViewModel is retained, without us needing to saveInstanceState.
Android does kill your process.
However, Android does have the liberty will kill your activity, due to various reason (e.g. if an incoming phone calls happens when memory is low etc). At this point, all your data in the ViewModel
is now flushed away. Bye-bye.
To emulate this, just checkout the below blog.
To solve the problem, you’ll need the conventional approach of onSaveInstanceState
of storing all your states before your activity/fragment got killed. And use the normal onRestoreInstanceState
to restore it accordingly.
What’s the use of ViewModelProviders now?
By implementing your own onSaveInstanceState
and onRestoreInstanceState
, this itself also solve the onConfiguration change state lost.
Why do you still need to use ViewModelProvider
anymore? Just instantiate MyViewModel()
is have the same behavior.
Any if you see further, if you’re not using ViewModelProvider
, you don’t even need to have your class implementing ViewModel()
interface anymore. So you could create your native ViewModel POKO (Plain Old Kotlin Object 😅).
Back to square one 🤔

You could still use LivecycleOwner
and LiveData
independent from the Viewmodel
.
Caveat
Perhaps the use of ViewModelProvider I could think of now is the ability to share the ViewModel across Fragments of the same activity as shared by https://developer.android.com/topic/libraries/architecture/viewmodel#sharing. It’s still nice as the Fragment doesn’t need to get the model from its Activity directly.
Let me know if you find out other use of ViewModel
in Architecture Component.
Updated
After explore further, found a distinct different on ViewModel
and SaveInstanceState
. Check it out
Also for the Half-Baked Solution I complaint about, Google is coming up with a solution. Check out the below