Recently I started to use the “Navigation Coordinator” pattern in my projects.
This pattern helps to significantly reduce coupling. It takes responsibility for choosing and presenting the right view controller from another view controller.
I borrowed the idea from a course on Lynda.com. I made changes that allow choosing where you want to navigate from the current View controller.
Another place where this concept is well explained is a Swift Talk episode Connecting View Controllers I’m not completely satisfied with this approach and working on the update. I described the following update in my next post about coordinators.
Below is an example of a traditional navigation pattern often used in code examples and simple applications:
class MainViewController: UIViewController {
....
func showScreenA() {
let viewController = ScreenAViewController() // 1
self.navigationController?.pushViewController(viewController, animated: true) // 2
}
func showScreenB() {
let dependency: SomeClassBDependency()
let viewController = ScreenBViewController(dependency: dependency)
self.navigationController?.pushViewController(viewController, animated: true) // 3
}
}
Here we have two functions that can be called to present another ViewControllers. In case of ScreenBViewController, we also inject a dependency.
MainViewControllershould know how to create theScreenAViewController.- It also knows where to present (
self.navigationController) - And how to present (
pushViewController(viewController, animated: true))
With this pattern, the MainViewController besides to its main function also should know how and where to present the ScreenAViewController and ScreenBViewController.
It bloats the code and violates the Single Responsibility Principle. To deal with it we should remove all mentions of other ViewControllers from the MainViewController. The Navigation Coordinator should make decisions about the controller it should present next.
##Refactoring for Navigation Coordinator
To simplify the example I will create the new controller inside the Navigation Coordinator. In a real project we should move this responsibility to some object factory. Also I will not use protocols.
As a starting point, I used a simple method that allows linear navigation between two View Controllers.
Let’s create a NavigationCoordinator class and pass it to our MainViewController from a common parent class.
// 1
enum NavigationState {
case atMainView, atScreenA, atScreenB
}
class NavigationCoordinator {
private var navigationState: NavigationState = .atMainView
private var navigationController: UINavigationController!
// 2
init(with navigationController: UINavigationController) {
self.navigationController = navigationController
}
// 3
func next(arguments: [String: Any]?) {
switch navigationState {
case .atMainView:
showSecondaryView(arguments: arguments)
default:
break
}
}
private func showSecondaryView(arguments: [String: Any]?) {
guard let selectedScreen = arguments["screen"] as? MainViewNavigation else { // 4
return
}
switch selectedScreen {
case .screenA:
showScreenA(arguments: arguments)
case .screenB:
showScrenB(arguments: arguments)
}
}
private func showScreenA(arguments: [String: Any]?) {
let viewController = ScreenAViewController()
navigationController.pushViewController(viewController, animated: true)
navigationState = .atScreenA
}
private func showScreenB(arguments: [String: Any]?) {
let dependency = arguments["screenBDependency"]
let viewController = ScreenBViewController(arguments: dependency)
navigationController.pushViewController(viewController, animated: true)
navigationState = .atScreenB
}
}
In the NavigatoinCoordinator above we made a few steps that will allow to create and present the screen we need.
- We use the enum to store possible navigation states.
- In the initializer, we inject the navigation controller that will present the child view controllers.
- The function
next(arguments: [String: Any]?)checks the current navigation state to find the ViewContrtoller from which it is called. Then it calls the corresponding navigation method. - In the navigation function, we use a passed argument to find what screen should be created.
Let’s check the new MainViewController
// 1
enum MainViewNavigation: Int {
case screenA, screenB
}
class MainViewController: UIViewController {
weak var navigationCoordinator: NavigationCoordinator? // 2
init(with navCoordinator: NavigatonCoordinator) { // 2
self.navigationCoordinator = navCoordinator
}
func showScreenA() {
let arguments = ["screen": MainViewNavigation.screenA]
self.navigationCoordinator.next(arguments: arguments) // 3
}
func showScreenB() {
let dependency: SomeClassBDependency()
self.navigationCoordinator.next(arguments: ["screen": MainViewNavigation.screenB,
"screenBDependency": dependency, // 4
//"someOtherDependency": dependency // 5
])
}
}
- We use the enum
MainViewNavigationto store the codes of all possible screens we need to navigate to. - The
NavigationCoordinatoris passed from the common parent and stored as a weak variable. It is very similar to the Delegate pattern. - Now, instead of instantiating a new ViewController we call the method
nextof the navigation coordinator letting it know what kind of screen we want to present (or what event happened, if you prefer) - If we need to inject a dependency, we can do it by passing an additional argument.
- It’s possible to add all kinds of additional arguments to the call.
The updated MainViewController knows nothing about screens that will be presented. It also doesn’t know where or how these controllers will be presented.
The only external method it has access to is navigationCoordinator.next(arguments:). By passing the “screen” and “dependency” arguments it allows NavigationCoordinator to decide what to do next.
It looks like this approach adds a lot of code, but it gives much more benefits in return.
- It reduces code coupling
- It helps to make code that follows the Single Responsibility Principle
- It makes the code testable
Please leave a comment if you know a better way to achieve this functionality or have a question.