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.

1. 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
2. The LifecycleObserver — Once a class implements it, the function that is annotated with appropriate @OnLifecycleEvent will be triggered upon the respective life cycle
3. 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

I hope this post is helpful to you. You could check out my other topics here.

Follow me on medium, Twitter or Facebook for little tips and learning on Android, Kotlin etc related topics. ~Elye~