MVVM — How View and ViewModel should communicate?
So you choose MVVM (Model-View-ViewModel) for your app’s architecture, Brawo, a good choice! In MVVM we separate view from view model from the model. Generally speaking, separation is a good thing that’s why we have the principle of “Separation of concerns” that is a fundamental principle to write good software.
Separation of concerns, or SoC, is a principle of software design that code be separated into layers and components that each have distinct functionality with as little overlap as possible.
Let’s define View and View-Model responsibilities in MVVM architecture, as this definition will guild us to design our code.
View: should only be responsible for how the app looks like! What is the color and size of the texts? and things like that.
View-Model: should only be responsible for preparing data for the View and defining how the view react and function when different events happen, data comes from the server, the user clicks on something, etc.
So the most important thing is to design our code in a way that these definitions are satisfied and we don’t mistakenly put codes that relate to View in View-Model and vice versa. To do that I personally follow these rules.
Rules for clear View-ViewModel communication
Rule Number One: View should not have any logic in it, not at all! Not even a simple if condition. All logic for the view happens in ViewModel.
Rule Number Two: In response to events view does nothing except notifying view-model by calling a method. View does not pass any view related classes to view model.
Rule Number Three: ViewModel uses live data as the main way to communicate to view!
One of the benefits of MVVM is that ViewModel doesn’t have to know anything about the View and has no reference to View classes! Instead, it uses the reactive programming paradigm, so View can still observer the data and be notified about the changes. I prefer LiveData over RxJava because it is lifecycle aware and therefore helps you to avoid many issues and bugs related to updating the view in the wrong time (ex. when the view is not created yet!) More about LiveData here https://goo.gl/DCCkob
Rule Number Four: View can call view-model whenever it needs something. ViewModel can provide helper methods for the view.
Note that whether ViewModel updates the calculated values in LiveData or do it in helper method It’s the ViewModel that handles the logic and that’s what’s matter!! Depending on our your case you can choose one of these two solutions to push logic into ViewModel.
Benefits
Now that I explained the rules let’s see what's the benefit of applying them in a real application.
- We are using MVVM the right way and that matters the most!! In my opinion, If we are adapting to new architecture we should respect the rules so our app is similar to other MVVM apps and anybody who knows MVVM can easily maintain our code.
- We pushed logics out of our views (activity/fragment) and therefore made View code simpler and easier to understand. (Fixed an old problem in android that activities/fragments contain most of the code in the app!). Our View code is also more consistent as well since all View does is setting precalculated values and forwarding events to ViewModel. Not only simpler and more consistent code means fewer bugs it also makes it easy to test the View with Espresso.
- ViewModel is also easier to understand and easier to test. You can test your ViewModels with JUnit tests only.
Also, don’t forget to Clap and share your ideas in the comment section below. Follow Me if you’re interested to read my other posts as well.
