What comes after VIPER? by Steve Powell

Steve Powell @s-powell, a robotics nerd turned iOS developer discusses how iOS architecture can be improved if we consider VIPER as a starting point.

You can watch the full presentation here: https://youtu.be/B30rHcVXfO8

Transcript

1. VIPER-X
2. Experimentation with architectures
3. A Quick History
4. Uncle Bob - > Clean Architecture Mutual Mobile -> VIPER -> ???
5. Review of Architectures
6. MVC
7. Model View Controller
8. MVC - Model: contains data - View: displays data - Controller: does everything else
9. MVC
10. MVC
11. MVVM
12. Model View View Model
13. MVVM - Model: contains data - View: displays data - View Model: presentation logic - (Controller: still does everything else)
14. MVVM
15. MVVM
16. A Quick Note on Unit Tests
17. Tests
18. Tests
19. VIPER
20. View Interactor Presenter Entity Router
21. VIPER - View: displays data - Entity: contains data - Presenter: presentation logic - Interactor: ? - Router: ? _
22. VIPER - View: displays data - Model: contains data - View Model: presentation logic - Interactor: ? - Router: ? _
23. VIPER - View: displays data - Entity: contains data - Presenter: presentation logic - Interactor: business logic - Router: navigation logic _
24. VIPER - View: displays data - Entity: contains data - Presenter: presentation logic - Interactor: business logic - Router: navigation logic - (Data Store: persistence logic)
25. VIPER - View: displays data - Entity: contains data - Presenter: presentation logic - Interactor: business logic - Router: navigation logic - (Data Store: persistence logic) - (Controller: still does everything else)
26. Interactor - Logic for a module's use cases e.g. logging in, signing up, creating a user, resetting a password
27. Router - Logic for what to present - Logic for how to present
28. Data Store - Logic for retrieving entities - Logic for saving entities
29. What have we done?
30. from - View Controller: all logic
31. to - Presenter: presentation logic - Interactor: business logic - Router: navigation logic - Data Store: persistence logic
32. and the View Controller still does everything else but it's a lot less
33. So that's VIPER
34. What does this look like?
35. MVC
36. MVVM
37. VIPER
38. Starting point for an app architecture
39. How can we improve it?
40. Some layers still do too many things
41. Router -> Router + Wireframe
42. Wireframe - Logic for creating a module - Logic for module communication
44. Data Store -> Data Manager + Networking + Persistence
45. Persistence - Logic for in-memory data structures <-> database objects - Logic for executing queries on database - Logic for writing to the database
47. Networking - Logic for creating and formatting network requests - Logic for handling network responses - Logic for JSON <-> native types
49. Data Manager - Logic for when to cache / call - Provides model parsers for persistence - Provides formatters for networking
51. from - Presenter: presentation logic - Interactor: business logic - Router: navigation logic - Data Store: persistence logic
52. to - Router: navigation logic - Wireframe: module logic - Presenter: presentation logic - Interactor: business logic - Data Manager: caching logic - Networking: networking logic - Persistence: persistence logic
55. internal final class SettingsVC: UIViewController { @IBOutlet private weak var settingsView: SettingsView! weak var router: Router? } override func viewDidLoad() { super.viewDidLoad() // create components // link components ...
56. override func viewDidLoad() { super.viewDidLoad() let serializer = Serializer() let APIClient = API(authToken: serializer.currentSessionToken) let dataManager = ModelDataManager(serializer: serializer, APIClient: APIClient) let interactor = SettingsInteractor(dataManager: dataManager) dataManager.interactor = interactor let presenter = SettingsPresenter(interactor: interactor) interactor.presenter = presenter settingsView.presenter = presenter presenter.view = settingsView presenter.wireframe = self }
59. Benefits: - Testable - Reusable - Parallel development - Easier to understand
60. How can we improve it?
61. Components still know too much about each other
62. Protocol Boundaries
63. Replace explicit references to class types with abstract protocol boundaries
64. internal final class SettingsVC: UIViewController { @IBOutlet private weak var settingsView: SettingsView! weak var router: Router? }
65. internal protocol SettingsWireframeType {...} internal final class SettingsVC: UIViewController { @IBOutlet private weak var settingsView: SettingsView! weak var router: SettingsRouterType? } extension SettingsVC: SettingsWireframeType { ... }
70. Benefits: - Testable - Reusable - Parallel development - Protocols act like headers
72. internal protocol AuthInteractor: SignUpInteractor, LoginInteractor { } internal protocol SignUpInteractor { func signUp(withEmail email: String, password: String, name: String, completion: Result<Session, NSError> -> Void) } internal protocol LoginInteractor { func login(withEmail email: String, password: String, completion: Result<Session, NSError> -> Void) } internal protocol SignOutInteractor { func signOut(completion: Result<Session, NSError> -> Void) }
73. Won't we end up with LOTS of protocol boundaries?
74. YES !
75. How can we improve it?
76. Data is flowing in too many directions
77. Top-down structure
78. from:
79. to:
80. Benefits: - Reduced communication complexity - Easier memory management - More maintainable - Dependency injection
81. override func viewDidLoad() { super.viewDidLoad() let serializer = Serializer() let APIClient = API(authToken: serializer.currentSessionToken) let dataManager = ModelDataManager(serializer: serializer, APIClient: APIClient) let interactor = SettingsInteractor(dataManager: dataManager) let presenter = SettingsPresenter(interactor: interactor) settingsView.presenter = presenter settingsView.delegate = self }
82. Anything else?
83. Merge view with view controller
84. - View controllers provide view lifecycle information - Tightly coupled to storyboards and XIBs - Remove logic (New wireframe object)
85. extension SettingsWireframe: Wireframe { var viewController: UIViewController { let serializer = Serializer() let APIClient = API(authToken: serializer.currentSessionToken) let dataManager = ModelDataManager(serializer: serializer, APIClient: APIClient) let interactor = AuthInteractor(dataManager: dataManager) let presenter = SettingsPresenter(interactor: interactor) let vc = SettingsViewController(presenter: presenter, delegate: self) return vc } }
86. Split interactors by use case
87. → interactor for fetching objects of a type → interactor for updating objects of a type → interactor for deleting objects of a type module interactor that glues them together
88. Split router into coordinators
89. - one massive router to handle navigation for whole app vs - one coordinator for each section
92. An Experimentation
93. Go Forth and Experiment
94. Acknowledgments Robert Martin's Clean Architecture https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean- architecture.html Mutual Mobile's VIPER http://mutualmobile.github.io/blog/2013/12/04/viper- introduction/ my coworkers
95. Gracias ❤ Questions?