Model View Presenter – Router (MVP-R) in iOS

Tram Ho

Difficulty: Beginner | Easy | Normal | Challenging
Xcode 14.0.1
Swift 5.7

1. About

In this article, I will introduce a popular model in iOS, that is Model View Presenter – Router (MVP – R). So how is it different from the MVC model and the pure MVP model? What problem was MVP – R created to solve? Let’s find out together now!!!

2. Make a problem

For those who have just approached iOS programming, we will usually build the project in the form of an MVC (Model View Controller) model. However, when the project has grown, more features, there will be times when you will see our Controller can be up to 1000 lines of code. So people often call MVC as Massive View Controller. That’s because the Controller (in MVC) takes on too many responsibilities: handling business logic, view logic, navigator, … So is there a way to avoid this situation?

Of course, that’s why we’re going to learn a new paradigm of problem solving in the MVC pattern. It’s the MVP-CHEAP model

3. Structure of MVP architecture

3.1. Main ingredients of MVP

Above is the flow diagram of the main components in MVP. MVP consists of 3 main components: Model, View and Presenter. I will introduce each ingredient:

  • Model : Is the place to keep the structs/classes that our application uses. Usually, I will separate the Model from the model to use it for the whole project (refer to the example code in the next section).
  • View : includes UIViewController and storyboard (or xibs if you don’t use storyboard). Now in the View only care about the view logic: setup UI, receive events/actions from the user, .. Then the View will pass those events/actions to the Presenter to handle. Of course it must also contain a reference to the Presenter
  • Presenter :
    • This is the heart of the MVP model. Where we will receive events/actions from View , where we perform restful API (call API to server to get data), validate input, … In general, all business logic we handle in Presenter
    • After having data (data has been processed), the Presenter will transmit that data back to the View and ask the View to display it on the screen.
    • Presenter needs to contain a weak link to View to avoid retain cycle
    • An important note: Presenter should not import UIKit (because it can cause code smell).

=> Note: These components will communicate with each other through Protocol, everyone. This is quite important in this model and also an advantage compared to MVC
=> Through this, we have briefly understood the main components and uses of each component in the MVP model.

So where will the navigation logic (push, present, dismiss, pop) be implemented? The answer is that we will do it in the View (because there is a UIViewController).
=> Thus, in general, View will receive more responsibility for navigation. Can we optimize it a little more? We will come to another component in the MVP-R model.

3.2. Router in MVP architecture


Above is a diagram of all components in the MVP-R model. This model will differ from the pure MVP model in that it will separate the navigation logic into a new class named Router . And for this Router to be able to handle push, present, dismiss or pop views, it must contain a weak link to the View .

  • Router : This is responsible for handling the movement between screens in the MVP-R model

4. Implementing MVP-R Architecture

I have a small example code about MVP-R architecture in iOS using Swift. Everyone can refer to the link . If you find it interesting, please drop a star for me.

structure.png
Here, I have 2 quite strange classes, so I will introduce them briefly for everyone to understand

  • Contract : This is where the entire Protocol is stored for communication between components: communication protocol between View and Presenter, between Presenter and Router
  • Builder : Is a place to contain a build() function and this function is responsible for connecting the components in the MVP-R model together for us and returns a reference UIViewController

Note: I have included a template to create a branch of MVP-R architecture in the link above. Everyone can download and import it into Xcode Templates for quick use.

5. Pros and cons of MVP-R Architecture

5.1. Advantage

Since Presenter has separated the business logic code from the View, it will help us:

  • Easy to read and understand code.
  • Easy to write Unit test for logic.
  • Easy to maintain, maintain.

5.2. Defect

  • The amount of code and code files increased much compared to MVC
  • Because the model only handles separating the business logic from the View, calling the API, saving data locally, etc. are all handled in the Presenter. Will cause Massive Presenter phenomenon (Presenter takes on many responsibilities, so it will be enlarged)
  • It will be difficult to configure/organize the MVP-R model code for newbies (but I have included the template in section 4, so there is no problem anymore)

6. Conclusion

  • MVP consists of 3 parts: Model, View and Presenter. MVP-R with extra Router
  • View and Presenter do not know each other’s existence, because they communicate with each other via protocol
  • Router takes responsibility for navigating between screens (instead of View in pure MVP model)
  • Presenter is where the business logic is handled and passed to the View to display data
  • So we’ve learned what the MVP-R architecture is and how to implement it through this blog.
  • If you have any questions or have a way to optimize your example code, don’t hesitate to comment. Thank you so much = Thank a lot = Thank you very much.

Reference

Share the news now

Source : Viblo