MVVM-1: A General Discussion

Published in

Swift India

6 min readJun 1, 2018

Oh, my… What we have today… Another blog on MVVM. What's new or else it will speak of the same boring things.

Yeah, then one thing is that our journey is gonna be long, adventurous and a detailed tour around the MVVM park. Not only we will learn the basics, even we would try our hands on a real-time application scenario with complicated UI. Let’s go on an MVVM adventure.. !!!! Sounds a bit interesting ;). Isn’t it?

MVVM or Model — View — ViewModel is a design pattern aimed for modularising your code and build it on a Test Driven Development environment. When Apple’s traditional MVC design pattern makes our controllers bulky and our unit tests painful, different design patterns such as MVVM, VIPER, MVP, etc come to our rescue. MVVM comes quite handy as it provides a loosely coupled mechanism between all components segregating your view, business and data logic. There are lots of tutorial and blogs explaining this, but here we will follow the basic rules of MVVM and learn how we can respect them and write beautiful code.

We will discuss MVVM in two parts:

Part -1 deals with a lot of discussion regarding MVVM and small demo code.

Part-2 will deal with some commonly encountered potholes in MVVM and ways to tackle them by taking a complex UI example.

What will you learn?

We will be learning the following in Part -1 of the sample

Whats MVVM?
Why MVVM?
We will build a sample example.
Some drawbacks of MVVM.

Whats MVVM?

Model:

Model is basically the data model or entities that your application has. They are simply structs or classes with simple associated properties. In general practice, they simply hold the data that has been mapped from your raw data structure which might come from your API’s or other sources such as SQLite files, etc.

View or View Controller:

The view is the visual element that gets displayed. All the UI components on an app screen are views. The view contains only the UI logic, such as data rendering, navigation, etc. The view owns the view model.

View Model:

View Models receive UI events and perform business logic and provides the output to be displayed on the UI. This is the component that is responsible for handling the business logic driving the view. But it internally does not modify the UI, neither it has any reference to the view. It owns the data model.

Why MVVM?

Okay some of us might ask why the hell do we need MVVM when Apple has provided a beautiful and more simple MVC. We could integrate some different design architecture like Facade, Coordinator, Singleton, etc. to build a modular code. Okay, now here are the following three reasons why MVVM stands out:

Segregated Code: Making the code segregated. MVVM component based divides a particular view handling distributed across the View, Model and View Model, thereby providing us with a modularised code structure.
Avoid Bulky Controllers: Devs using MVC know that when our app gets scalable and requirements keep on messing with our existing logic, our controller keeps on expanding until and unless we route the controller code to separate files. Via MVVM, we write down our business logic in the View Model and just only communicate the output to the view or the controller.
Test Driven Development: The most important of all, MVVM really provides a good platform to perform TDD. We can write down Unit Test Cases for View Models and test the business logic driving the UI. Unit Test cases are really important while developing as they minimize our code-break chances to a great extent. Please follow the below link to explore more about TDD in iOS

Test Driven Development in iOS, SWIFT 4- Part 1

Test Driven Development(TDD), an agile software development methodology that makes development more bug-free and codes…

medium.com

Sample Code

Well, this demo provides a basic example of MVVM by taking a simple View into the picture. We will just show some movie detail and try to understand basic MVVM flow.

Code Flow:

You can download the Sample Code and open up the “Simple MVVM” project. The code consists of only one module.

Oh! Yeah!! ….. It’s gonna end soon ….. ;)

Let’s first see all the classes used for the sample.

MovieDetailController: It represents our movie detail page. It consists of all the UI components that are being rendered on the view.

MovieDetailVM: Its the view model for movie detail view. It holds the business logic such as data fetching and processing it for display.

Movie: It is a simple struct representing a movie model.

DataGenerator: This class generates data for the movie detail page. You can compare with a web service request class which provides data.

When you run the app, in the debugger you will see logs something like this:

So whats going on ??

Flow -1: When view loads

When the view of MovieDetailViewController loads, we inform the ViewModel that view has loaded by calling the viewDidLoad() of ViewModel.

The ViewModel, MovieDetailVM then calls the movieData() to provide data of the movie and pass it as an argument to configureDataModel(data:). Here you can notice that we have moved our logic of fetching data to the viewModel, which earlier used to be in the controller in case of MVC. So is the case when we are configuring and processing the data to be displayed for “Movie release date” and “Rating”

To maintain ViewModel’s authority of setting the values of the output properties, we have made every property to be privately set in ViewModel as:

As you can see the view here communicated with the view model calling viewDidLoad() of ViewModel. In the next flow, we will be seeing closures as another means of communication.

Flow -2: When the favourite button is pressed

Press the favourite button and then check the debugger.

Here the communication of UI event is done via closures for your understanding of how we can use different ways of communicating between the components.

When the user taps MarkFavourite button, the view informs the ViewModel about the event by calling the closure viewModel.markFavoriteButtonPressed().

ViewModel then resets the isFavourite boolean variable.

The controller then resets the image of the button.

Great !!! You finished your first MVVM simple demo.

Disadvantages of MVVM:

Communication between various MVVM components and data binding can be painful
Code reusability of views and view model is difficult.
Managing view models and their state in nested views and complex UI’s is difficult
MVVM for beginners is hard to put to use.

What did we learn?

What is MVVM and how it helps to make our life easy?
You build up a simple MVVM sample.
The disadvantages of MVVM.

What’s next?

This was your first trip around MVVM Jurassic Park. You just explored what is MVVM and how we can use it to improve our code quality. The next part i.e MVVM-2 deals with the problems of MVVM, and how we can elegantly deal with them.

Sample Code: GitHub link