Migration to MVVM @ Pepperfry iOS App- Part II(Deep Tour)

We are back again with the second part of the series, Migration to MVVM @ Pepperfry iOS App. In this part, we are gonna dive deep into the actual implementation of MVVM.

Before moving ahead, if you have not read the previous part in this series - Migration to MVVM @ Pepperfry iOS App- Part I(Inception), I suggest that you read it first. It talks about initial Pepperfry iOS app architecture & issues with it.

stocksnap.io

In this part, we will look at :

• Why MVVM?
• MVVM Architecture of Pepperfry iOS App

Why MVVM?

In the previous part of this series, we saw what are the problems with MVC architecture. We were facing two major issues: Huge View controller code & business logic is not easily testable.

Some developers might ask, do we really need MVVM, as Apple has already provided an elegant and a simple MVC. Along with MVC, we could adopt some other design patterns like Facade, Coordinator, Singleton, etc. to build more modularised code? I think below are some points that really will help us to understand the need for MVVM :

1. Separation of responsibilities: MVVM architecture smartly distributes the responsibilities across different layers like View, Model and ViewModel. Eventually translates it into decoupled components, which are easy to debug and test.
2. Get rid of Massive View Controller: As we saw in last part of this series, View Controller is the most important entity in iOS app(View Controller in iOS is different from our classic controller in MVC, View Controller is an integral part of iOS app). iOS developers must have seen that as new requirements come up, existing logic in View Controller gets messed up and we just add new code to existing View Controller. Thus, leading to a problem of Massive View Controller. To get rid of huge View Controller, via MVVM, we separate business logic in a separate entity called as ViewModel. View Controller just acts as a communicator between the View and ViewModel with fewer responsibilities and code.
3. Unit Testing: Most important benefit of MVVM is the ability to write unit tests. We can easily test our business logic by testing ViewModels. Unit testing is really important, as it ensures most of the possible test cases are covered and hence minimizes our code break chances to a great extent.

The most important thing, we feel that MVVM is an improved version of MVC. This means that it doesn’t require any dramatic change in mindset. In fact, once we understand the fundamental pattern, it’s fairly easy to implement, no more difficult than implementing Model-View-Controller architecture.

MVVM Architecture of Pepperfry iOS App :

Now, let’s see how are iOS app architecture with MVVM. Every module we developed is divided into three parts: Model, View & ViewModel.

1. Model: Model in MVVM is the same Model in MVC as it contains only Model objects.
2. View: View Layer contains all UI element that we see on the screen like button and labels.
3. ViewModel: ViewModel is the most important layer to look into. We will try to get in detail about it as much as possible. Our ViewModel got several responsibilities like Business Logic, Networking Code, etc. As a basic responsibility, the ViewModel accepts model and converts it into the ViewModel. This process consists of the conversion of Model in the most usable way to ViewModel, so we can directly use it in our Views without processing it anymore. The second responsibility is the networking service, that is handled by the ViewModel. Now there are lots of arguments about where to write networking code, some people prefer model while others prefer the ViewModel. We prefer the ViewModel, as it has access to both layers i.e. Model & ViewModel. Although we initiate networking call from ViewModel, there is a separate service layer called Networking Manager, which handles the networking code.

View Controller: We believe View Controller is an integral part of the iOS app and it has its own place in the app. Although View Controller is not a separate layer in MVVM, it’s responsibilities may change with each architecture. In MVVM, as we move business logic from View Controller to ViewModel, it has fewer responsibilities and code. Responsibilities of view controller are now very simple, to act as an intermediator between View & ViewModel.

MVVM Flow Diagram

As you can see in the above diagram, view controller no longer owns the model; it’s a ViewModel that owns the Model and the view controller asks the ViewModel for the data it needs to display.

This is an important difference from the Model-View-Controller pattern. The view controller has no direct access to the model. The ViewModel hands the view controller the data it needs to display in its view.

The relationship between the view controller and its view remains unchanged. That’s important because it means that the view controller can focus exclusively on populating its view and handling user interaction. That’s what the view controller was designed for.

The result is pretty dramatic. The view controller is now slim and many responsibilities are shifted to the ViewModel. You no longer end up with a view controller that spans hundreds or even thousands of lines of code.

Because the Model-View-ViewModel pattern is not native to Cocoa(iOS Framework), there is no strict rule to implement the pattern. So every developer takes an opportunity to tweak it according to their own convenience or project need.

In the next and last part of this series, we will conclude the Migration to MVVM @ Pepperfry iOS app with a focus on some great insight & limitations on MVVM. Stay tuned!!!