What is MVVM?

The short answer, it is a design pattern.

What is a design pattern?

In simple words, a design pattern is all about solving problems in the software development process that “WE” developers face from time to time.

Design patterns are beneficial, 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, we were doing almost linear programming for the mobile app development services. There was nothing terrible in that. It was all looking correct. It was fine for small apps. But…few apps were growing day and night. Even before we realize it became too big than we ever expected.

We started facing problems that 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 required to cover more areas than one should be just to make sure everything existing-working correctly, along with the new feature.

We discussed this amongst us and then concluded that the code (yes, code. Not talking about the app) is now required to be testable. “Write Unit Tests” was the call we made!

Cool, then…

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 kept us away from what we wanted to try.

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 that can help with this situation.

“MVP – Model View Presenter”

What is an MVP design pattern?

It has 3 components: Model, View, and Presenter. Refer to the following picture to understand it better.

 

A user interacts with View. The view is not aware of what to do on that interaction. So it notifies the presenter about that interactions.

The presenter is a manager(The Boss!) here. It knows everything: what to do when to do it. It takes the help of a 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 the model, the presenter notifies views to show the result to the user.

The 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 business logic and app-specific view related code. Now the only thing we need to test here is the Model – because it is the only one holding business logic. ✌️

Great! What about MVVM now?

It went well for a 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 the progress bar visible to the user for this long-running task etc…

We were not able to test those using MVP. The only testable component there was Model – The business logic holder. ?

Then comes MVVM!

MVVM – Model, View & ViewModel.

Same as MVP, when interaction happens 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. It takes the help of a model class to get things done.

That sounds very familiar..!!

Oh my god, it is the same as MVP. Just presenter has been replaced by ViewModel.

BTW, what is ViewModel?

ViewModel is just a good old model, but holding state and behavior related to view. I said, state and behavior related to views, not actual views.

There comes a difference between Presenter and ViewModel: In MVP except for the model, there were app-specific codes in Views, and the 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 happens, 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 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 the 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.

Are you looking to outsource mobile application development services? We are having experienced and professional mobile application developers who develop the application based on your needs and requirements. Contact us now