What is MVVM ?
Short answer, it is a design pattern.
What is design pattern ?
In simple words, design pattern is all about solving problems in software development process that “WE” developers face from time to time.
Design patterns are incredibly useful, no matter which language or platform you develop for. Every developer should know how to implement them, and most importantly, when to apply them.
When to apply MVVM ?
It is a little long story… 👂
A few years ago at IndaPoint, for the mobile app development, we were doing almost a linear programming. There was nothing bad in that. It was all looking correct. It was fine for small apps. But…few apps was growing day and nights. Even before we realize it became too big then we ever expected.
We started facing a problems which were not so noticeable before:
- A feature request comes from a very old code. Implementing that new feature breaks something working already.
- Developers come and go. A new dev implements something which breaks something existing because one was not aware with in-outs and all the existing features of a big product.
- QA was require to cover more areas than one should be just to make sure everything existing working correctly, along with new feature.
We discussed this amongst us and then concluded that the code (yes, code. Not talking about the app) now is required to be testable. “Write Unit Tests” was the call we made!
When we started to find a solution, we ran into another problem. The code was not testable. Not testable at all. The “good old” linear programming was good, until unit testing was not required. When we wanted to test business logic, other app specific things were keeping us away from what we wanted to test.
We then decided that let’s separate out business logic from app specific code. We came to know that there is a design pattern available which can help with this situation.
“MVP – Model View Presenter”
What is MVP design pattern ?
It has basically 3 components: Model, View and Presenter. Refer following picture to understand it better.
User interacts with View. View is not aware of what to do on that interaction. So it notifies the presenter about that interactions.
Presenter is a manager(The Boss!) here. It knows everything: what to do, when to do. It takes help of model class to get things done.
Model classes are nothing but the servants who provide service whenever they are asked.
When the desired work is done using model, presenter notifies views to show the result to the user.
Presenter holds the reference of View and Model. So that it can communicate with View and Model whenever required.
That’s how we managed to separate out business logic and app specific view related code. Now only thing we need to test here is Model – because it is the only one holding business logic. ✌️
Great! What about MVVM now?
It went well for couple of years. But then we realized that only testing business logic is not enough. We need to test few view specific things as well. For example, what error message user will see in some scenarios. Is progress bar visible to user for this long running task etc…
We were not able to test those using MVP. Only testable component there was Model – The business logic holder. 😟
Then comes MVVM!
MVVM – Model, View & ViewModel.
Same as MVP, when interaction happen with a View, it knows nothing. So it notifies ViewModel.
ViewModel is a manager here. It knows everything: what to do, when to do. It takes help of model class to get things done.
That sounds very familiar..!!
Oh my god, it is same as MVP. Just presenter has been replaced by ViewModel.
BTW, what is ViewModel ?
ViewModel is just good old model, but holding state and behaviour related to view. I said, state and behaviour related to views, not actual views.
There comes a difference between Presenter and ViewModel: In MVP except model, there were app specific code in Views and Presenter was holding a reference of Views.
ViewModel is not holding any reference of View. ViewModel is completely unaware of View. It is just holding the state and behavior.
It just holds the data that “when this happen, that should happen on a view”. Nothing more than that. It doesn’t even care if that is happening already or not. Whenever any state of a ViewModel changes, it broadcasts an event without knowing who might be listening.
When the app is running, View is the one who is interested in those events and update the elements accordingly.
When we want to test, we can test ViewModel to make sure behavior of the app is as expected or not.
So we were now able to test business logic using Models and View related business logic using ViewModels. 🎉
That’s where we’re at the moment and using this design pattern extensively for all our mobile app development at Indapoint.
Stressless Devs -> Satisfied Clients