📜 ⬆️ ⬇️

Via MVP to VIPER. Part One: MVP


Not so long ago, I published a translation. Why VIPER is a bad choice for your next application . And, as often happens, the opinion of the translator did not coincide with the opinion of the author of the original article. Therefore, in this post I will briefly tell you how I am trying (while still trying to) to introduce VIPER into my projects.


When I started working on my previous project, the team had exactly two point zero mobile developers: one wrote a version for Android, the second for iOS.


Naturally, the iOS version was created on the classic, recommended by Apple, MVC pattern.


I had a View: a "favorite" storyboard, in which there were quite a few over9000 screens, and which looked like this:



I had a model - classes for storing settings, user data, some data that was stored in the internal database.


And I had a view controller for each screen on a storyboard. In the view controller, handlers of user actions were to be placed, as well as notifications from the model (data retrieval on demand or data changes). But in fact, something like this was happening there:


Networking.request(.POST, withURL: serverAddress, andParameters: parameters) { (dictResult, error) in if let dictResult = dictResult { // some actions with view if let rates = dictResult["rates"] as? [AnyObject] { for rate in rates { if let rateDictionary = rate as? JSONDictonary { let result = Result(jsonDictionary: rateDictionary) self.resultsArray.append(result) } } } // some actions with view } else { if let error = error { DispatchQueue.main.async(execute: { self.showError(error) }) } } } 

In general: I confidently moved from the Model View Controller to the Massive View Controller and had to do something about it.


I began to study possible architectures for mobile applications, and of course, I immediately liked the Clean architecture pattern (which is essentially VIPER):



Picture from The Book of VIPER


I bravely spent several weekends studying this pattern. I looked through several video tutorials and wrote quite a few simple application examples on it. I also found convenient scripts for generating module files, because one module is about a dozen files (protocols, configurators, classes directly, storyboards, unit tests). But pretty quickly it came to an understanding that if I now try to implant the VIPER “head-on,” I will lose a lot of time. After all, with unaccustomed, I will have too much time spent on the correct division of responsibility between all layers. And I decided to go the way easier and share responsibility gradually.



And what if I tell you that the UIViewController is a View.

That's why I took MVP . The most difficult and at the same time the simplest thing is to understand that the UIViewController belongs to the View layer. It should work with the UI and only with it: take actions related to the UI from the user (keystrokes, text input, etc.) and change the display of the UI itself. At first it seemed difficult, but I brought out for myself a few simple rules that help put everything I need into the controller view, and at the same time do not put anything extra there:


  1. All methods and algorithms of the controller view should work with the UI. If you see some method or piece of code that can work without using UIKit, know: this method / block of code is not the place.


  2. For a presenter, everything is exactly the opposite: there should not be a single method for which UIKit is needed. If such methods are found, you need to carefully study these parts of the code and bring them into the view controller.


  3. The view controller and presenter have protocols for which they are signed, these are their external interfaces. There are defined methods that can be called from outside. Therefore, if suddenly, you see a method call from the interface (protocol) of the same view controller in the view controller - this method should not be in the view controller, but in the presenter.

The transition to MVP taught me the main thing: to share responsibility between entities. So far, I have only separated the work with UI from everything else, but ahead, VIPER is still waiting for me. Perhaps classic, and possibly more multi-layered.


I hope that soon I will get to him and continue my story.


')

Source: https://habr.com/ru/post/323764/


All Articles