Our team has been using Coordinators and MVVM in production apps for more than 2 years. At first, it looked scary, but since then we’ve finished 6 applications built on top of those architectural patterns. In this article, I will share our experience and will guide you to the land of MVVM, Coordinators & Reactive programming. Instead of giving a definition up front, we will start with a simple MVC example application. We will do the refactoring slowly step by step to show how every component affects the codebase and what are the outcomes. Every step will be prefaced with a brief theory intro. Example In this article, we are going to use a simple example application that displays a list of the most starred repositories on GitHub by language. It has two screens: a list of repositories filtered by language and a list of languages to filter repositories by. Screens of the example app A user can tap on a button in the navigation bar to show the second screen. On the languages screen, he can select a language or dismiss the screen by tapping on the cancel button. If a user selects a language the screen will dismiss and the repositories list will update according to the selected language. You can find the source code here: _Coordinator-MVVM-Rx-Example — Example of MVVM-C architecture implemented with RxSwift_github.com uptechteam/Coordinator-MVVM-Rx-Example The repository contains 4 folders: MVC, MVC-Rx, MVVM-Rx, Coordinators-MVVM-Rx correspondingly to each step of the refactoring. Let’s open the project in the and look at the code before refactoring. MVC folder Most of the code is in two View Controllers: and . The first one fetches a list of the most popular repositories and shows it to the user via a table view, the second one displays a list of languages. is a delegate of the and conforms to the following protocol: RepositoryListViewController LanguageListViewController RepositoryListViewController LanguageListViewController The is also a delegate and a data source for the table view. It handles the navigation, formats model data to display and performs network requests. Wow, a lot of responsibilities for just one View Controller! RepositoryListViewController Also, you could notice two variables in the global scope that define a state of the : and . Such stateful variables introduce complexity to the class and are a common source of bugs when parts of our app might end up in a state we didn’t expect. To sum up, we have several issues with the current codebase: RepositoryListViewController currentLanguage repositories View Controller has too many responsibilities; we need to deal with state changes reactively; the code is not testable at all. Time to meet our first guest. RxSwift The component that will allow us to respond to changes reactively and write declarative code. What is Rx? One of the definitions is: ReactiveX is a library for composing asynchronous and event-based programs by using observable sequences. If you are not familiar with functional programming or that definition sounds like a rocket science (it still does for me) you can think of Rx as an Observer pattern on steroids. For more info, you can refer to the or to the . Getting Started guide RxSwift Book Let’s open and take a look at how Rx changes the code. We will start from the most obvious things to do with Rx — we replace the with two observables: and . MVC-Rx project in the repository LanguageListViewControllerDelegate didCancel didSelectLanguage became the and observables. We use them in the method to reactively observe events. LanguageListViewControllerDelegate didSelectLanguage didCancel prepareLanguageListViewController(_: ) RepositoryListViewController Next, we will refactor the to return observables instead of using callbacks. After that, we will use the power of the RxCocoa framework to rewrite our View Controllers. Most of the code of the will move to the function where we declaratively describe a logic of the View Controller: GithubService RepositoryListViewController setupBindings Now we got rid of the table view delegate and data source method in view controllers and moved our state to one mutable subject: fileprivate let currentLanguage = BehaviorSubject(value: “Swift”) Outcomes We’ve refactored example application using RxSwift and RxCocoa frameworks. So what exactly it gives us? all the logic is declaratively written in one place; we reduced state to one subject of current language which we observe and react to changes; we used some syntactic sugar from RxCocoa to setup table view data source and delegate briefly and clearly. Our code still isn’t testable and View Controllers still responsible for a lot of things. Let’s turn to the next component of our architecture. MVVM MVVM is a UI architectural pattern from Model-View-X family. MVVM is similar to the standard MVC, except it defines one new component — ViewModel, which allows to better decouple UI from the Model. Essentially, ViewModel is an object which represents View UIKit-independently. The example project is in the MVVM-Rx folder . First, let’s create a View Model which will prepare the Model data for displaying in the View: Next, we will move all our data mutation and formatting code from the into : RepositoryListViewController RepositoryListViewModel Now our View Controller delegates all the UI interactions like buttons clicks or row selection to the View Model and observes View Model outputs with data or events like . showLanguageList We will do the same for the and looks like we are good to go. But our tests folder is still empty! The introduction of the View Models allowed us to test a big chunk of our code. Because ViewModels purely convert inputs into outputs using injected dependencies ViewModels and Unit Tests are the best friends in our apps. LanguageListViewController We will test the application using RxTest framework which ships with RxSwift. The most important part is a class, that allows you to create fake observables by defining at what time they should emit values. That’s how we test View Models: TestScheduler Outcomes Okay, we’ve moved from MVC to the MVVM. But what’s the difference? View Controllers are thinner now; the data formatting logic is decoupled from the View Controllers; MVVM made our code testable. There is one more problem with our View Controllers though — knows about the existence of the and manages navigation flow. Let’s fix it with Coordinators. RepositoryListViewController LanguageListViewController Coordinators If you haven’t heard about Coordinators yet, I strongly recommend reading by Soroush Khanlou which gives a nice introduction. this awesome blog post In short, Coordinators are the objects which control the navigation flow of our application. They help to: isolate and reuse ViewControllers; pass dependencies down the navigation hierarchy; define use cases of the application; implement deep linking. Coordinators Flow The diagram shows the typical coordinators flow in the application. App Coordinator checks if there is a stored valid access token and decides which coordinator to show next — Login or Tab Bar. TabBar Coordinator shows three child coordinators which correspond to the Tab Bar items. We are finally coming to the end of our refactoring process. The completed project is located in the directory. What has changed? Coordinators-MVVM-Rx First, let’s check what is : BaseCoordinator Base Coordinator That generic object provides three features for the concrete coordinators: abstract method which starts the coordinator job (i.e. presents the view controller); start() generic method which calls on the passed child coordinator and keeps it in the memory; coordinate(to: ) start() used by subclasses. disposeBag Why does the _start_ method return an _Observable_ and what is a _ResultType_ ? is a type which represents a result of the coordinator job. More often will be a but for certain cases, it will be an enumeration of possible result cases. The will emit exactly one result item and complete. ResultType ResultType Void start We have three Coordinators in the application: which is a root of Coordinators hierarchy; AppCoordinator ; RepositoryListCoordinator LanguageListCoordinator. Let’s see how the last one communicates with ViewController and ViewModel and handles the navigation flow: Result of the LanguageListCoordinator work can be a selected language or nothing if a user taps on “Cancel” button. Both cases are defined in the enum. LanguageListCoordinationResult In the we flatMap the output by the presentation of the . After the method of the completes we filter the result and if a language was chosen we send it to the input of the View Model. RepositoryListCoordinator showLanguageList LanguageListCoordinator start() LanguageListCoordinator setCurrentLanguage Notice that we return _Observable.never()_ because Repository List screen is always in the view hierarchy. Outcomes We finished our last stage of the refactoring, where we moved the navigation logic out of the View Controllers and isolated them; setup injection of the View Models into the View Controllers; simplified the storyboard. From the bird’s eye view our system looks like this: MVVM-C architecture The App Coordinator starts the first Coordinator which initializes View Model, injects into View Controller and presents it. View Controller sends user events such as button taps or cell section to the View Model. View Model provides formatted data to the View Controller and asks Coordinator to navigate to another screen. The Coordinator can send events to the View Model outputs as well. Conclusion We’ve covered a lot: we talked about the MVVM which describes UI architecture, solved the problem of navigation/routing with Coordinators and made our code declarative using RxSwift. We’ve done step-by-step refactoring of our application and shown how every component affects the codebase. There are no silver bullets when it comes to building an iOS app architecture. Each solution has its own drawbacks and may or may not suit your project. Sticking to the architecture is a matter of weighing tradeoffs in your particular situation. There’s, of course, a lot more to Rx, Coordinators and MVVM than what I was able to cover in this post, so please let me know if you’d like me to do another post that goes more in-depth about edge cases, problems and solutions. Thanks for reading! Arthur Myronenko, UPTech Team With ❤️ This post was originally published at UPTech Team blog . Follow us for more articles on how to build great products 💪
