Architecture Patterns in Mobile Development

As we mentioned in the last blog Design Patterns in Mobile Development, there was a time when designing an iOS app meant relying on one of the three design patterns – the Singleton pattern, the Decorator pattern, and the Builder design pattern. Since these patterns started having issues of interactions between client and server, iOS moved to better architecture patterns, like MVP, MVVM, MVC, and VIPER. 

They are better because they:

• Have more balance distribution of responsibilities 
• The single responsibility principle is better fulfilled

But Should You Care About Choosing Architecture Pattern? 

Kristijan highlighted that with architecture comes the balanced distribution of responsibilities among entities with strict roles. Also, testability can be implemented from the first feature, as they are easy to write and have a low maintenance cost. 

How to Choose the Right One?

When deciding which architectural pattern to use, there are a few questions you need to ask first:

• Is the Model or Controller supposed to own a networking request?
• How does a Model communicate with a View Model or a View?
• Does the Router or the Presenter create a new VIPER module?

The architectures mentioned above have pros and cons, but they are all designed to simplify and clarify the code. There is no wrong answer or wrong architecture pattern, but you have to know what exactly you need the architecture for and for what it will be used. 

The Architecture Patterns 

MVC 

The first Architecture Pattern introduced was MVC by Trygve Reenskaug, a Norwegian computer engineer in the 1970s. It has a Stateless View, which the Controller renders once the Model is changed. The problem with this architecture is that it’s tightly coupled, and each entity knows about the other two. 

So, we have a View that sends an action to a Controller. The Controller updates the Model, and the Model notifies the View about the update. 

Next, the View receives a change of the Model, and that’s exactly where the problem lies. There should be a separation, and the Controller needs to be in charge—something like a Stateless View rendered by the Controller when the Model updates. Also, the problem is that every entity knows about the other one. 

Apple’s MVC

But then we have Apple’s MVC. Here, the Controller mediates between the View and the Model. In that way, they don’t know about each other. Kristijan highlighted that Apple’s MVC is one of the best architectural patterns if you use development speed as a primary criterion. There is less code than with other patterns, and inexperienced developers can easily maintain it. 

Apple’s View Controller is a mediator between the View and the Model. The View sends an action to the Controller, which then updates the Model, and the Model sends all the updates through the Controller. 

While the View and the Model are separated, Kristijan mentioned that a huge problem appeared with the View Controller. Suddenly, it becomes responsible for dispatching and cancelling the network requests and acts as a delegate and a data source. That’s why it ends up having thousands and thousands of lines of code, and it begins to be impossible to maintain. Due to the actually bad distribution, you can only test your Model while the View Controller is very hard to test. 

MVP

To lighten the controller, the architecture pattern MVP was introduced. It’s basically MVC, but here we have a Presenter. It doesn’t include the View Controllers life cycle or the UI part. Instead, we have a Passive View which takes care of UI updates and sends them to the Presenter. Presenter owns and sends updates to the Model, while the Model sends the update to the Presenter and then returns to the Passive View. The most important thing is that the View Controller is separated from UI, and it cares only for the logic of the actions. 

But, there are some problems Kristijan also talked about. While we now have a superb testability option, now we have to write too much boilerplate code for it to be feasible. To put it in perspective, if we compare it to MVC, there is a double amount of code, and the logic is there, so we’re on the right track to have an ultimate architecture. 

MVVM

MVVM was proposed by John Gossman in 2005, and the primary purpose of this architecture pattern was to move the data from the View to the View Model. It treats the View Controller as the View, and there is no tight coupling between the View and the Model. 

Again, it is very similar to the MVP, but this time, we have bindings that connect objects.

So the View updates the Model through View Model, and the Model notifies the View Model about the changes. The bindings here automatically update the View when needed. There are no tight couplings between the View and the Model; the View is treated just like the View. There is not too much stake in it, like with the View Model. 

While View has more responsibility, they are bound only to View Model, while View Model knows nothing about the Model. Because of that, you can test the View easily since it’s separated from everything else. 

The most modular Architecture Pattern – VIPER

And then we have Viper, which Kristijan explained is more like a Lego and suitable for complex architecture with good separation. 

Viper consists of Interactor, Presenter, Entities, and Router. 

• Interactor — keeps logic related to the data or the Entities and networking, and it creates new instances of the entities and fetches them, as well as 
• Presenter — keeps the UI-related logic and invokes methods on the Interactor
• Entities — plain data objects
• Router — segues between the VIPER modules

So, we have a View which owns and sends all action to the Presenter, appointed to handle all the logic from the View. It sends everything to Interactor, which then does the job and manages the data. That means that Interactor is the only one that knows about the Entity (Model), and it sends it to it. Here the updates happen, the Interactor sends them to Presenter, and the Presenter updates the View. 

Also, with VIPER, a routing component is presented for the first time, which is used for navigation between multiple Controllers. 

What’s new with the VIPER is that: 

• Model (data interaction) logic shifted into the Interactor with the Entities as dumb data structures
• Only the UI representation duties of the Controller/Presenter/ViewModel moved into the Presenter, but not the data-altering capabilities
• The first pattern explicitly addresses navigation responsibility, which is supposed to be resolved by the Router

And what’s excellent about VIPER is that: 

• VIPER can be called a champion in the distribution of responsibilities
• And we know that better distribution means better testability
• It’s easy to use, but you have to write a vast amount of interfaces for classes with minimal responsibilities

But, although VIPER is the most modular architecture pattern, it’s easy to test, and many people can work on it. But sometimes the approach lies in simplicity Kristijan said, and there is no need for this kind of complexity if we need a straightforward approach. 

The Coordinator Pattern

Last but not least, Kristijan talked about the coordinator pattern, which was introduced a few years ago in iOS. It’s a structural design pattern for organising navigation between view controllers. It is similar to a router in Viper which takes care of the ViewControllers navigation, but it’s more complex: 

• Here, the coordinator defines methods and properties all concrete coordinators must implement, and they know how to create concrete view controllers and their order.
• The Router defines methods all concrete routers must implement
• The Concrete Routers know how to present view controllers
• Concrete View Controllers are typical View Controllers, but they don’t know about other View Controllers

Sooooo, what to use? 

Kristijan ended his Learn@Lunch highlighting that we need to keep it simple. All of these architecture patterns are good, and there is not just one pattern you can always use. 

But, we need to know the challenge of what we’re building and what is expected of us. As well as be well aware of the tools we can use to solve any problem. 

Design patterns are here to help. They simplify and quickly resolve some problems others have already encountered. But, to know which pattern will help us, we need to be well aware of the problem we need to solve, so use them wisely!