Learning Topic: Coordinator Pattern

Topic: Coordinator Pattern

Coordinator pattern created by Soroush Khanlou from a series of articles and a talk given at NSSpain

Example protocol for the most basic Coordinator:

protocol Coordinator {
    var childCoordinators: [Coordinator] { get set }
    var navigationController: UINavigationController { get set }

    func start()
}

This is a good starting point for the protocol but not every project uses this protocol. I will need to assess other example protocols to see why they have changed parts of this.

Why:

This pattern is to:

Remove coupled navigation code in your ViewControllers
Increase reusability and give single responsibility to the coordinator
Reduce the complexity in ViewControllers
Allow for easier testing
Allow for easier changes to navigation flow

Here is a simple example,

public class HomeViewController: UIViewController {

    // ... Other code for View Controller

    @IBAction internal func didPressButton(_ sender: AnyObject) {
        // HomeViewController needs to know about AwayViewController and how to navigate to it.
        if let awayViewController = storyboard?.instantiateViewController(withIdentifier: "AwayViewController") {
            navigationController?.pushViewController(awayViewController, animated: true)
        }
    }
}

with the coordinator pattern and delegation this can result in:

// Coordinator implements this delegate
public protocol HomeViewControllerDelegate: class {
  func homeViewControllerDidPressButton(_ viewController: HomeViewController)
}

public class HomeViewController: UIViewController {
    public weak var delegate: HomeViewControllerDelegate?

    // ... Other code for View Controller

    @IBAction internal func didPressButton(_ sender: AnyObject) {
        // HomeViewController using a delegate
        // Removed coupling between HomeViewController and AwayViewController
        // also removed the navigation concerns away from HomeViewController 
        // as the delegate can decide how it should be navigated to, e.g. modal, push, pop, etc
        delegate?.homeViewControllerDidPressButton(self)
    }
}

This is a much cleaner approach as we can reuse the HomeViewController in other places within our app or swap out its coordinator to change the navigation in homeViewControllerDidPressButton

Notes:

This pattern has been around since 2015 so a lot has progressed since then, prepare to find it has evolved.

Some seem to use Delegates for events between Coordinator and ViewControllers others use Closures, need to see why this is the case?

Using closures with the coordinator pattern

That allows to inject callbacks into a view controller rather than a specific coordinator. This has the effect of creating even more loose coupling than having a coordinator object or protocol, allowing us to replace coordinators with something else entirely if we wanted.

This technique of closure injection is nothing new – in fact, Apple even mentioned it in their WWDC 2016 presentation, Improving Existing Apps with Modern Best Practices. However, I think it has its limits: if you try to pass in more than a couple of closures it gets messy, and you should consider using a coordinator object or protocol instead.

Possibly use both?

Why do some of the examples use Factories?

For dependency injection and easier mocking in tests
- Dependency injection using factories in Swift
To avoid singletons
- Avoiding singletons in Swift
To avoid Shared state
- Using the factory pattern to avoid shared state in Swift

Resources:

He also describes this pattern in a way that it could be used in MVVM, MVC, VIPER, etc, by calling the VM, VC, IPV - "modules"

Sample code here, it also has tests 🤘: https://github.com/AndreyPanov/ApplicationCoordinator

Why should we use it?

The main goal is to have unchained module-to-module responsibility and to build modules completely independently from each other. After this iteration, we can easily reuse them in different flows.

He uses a similar protocol to the one mentioned above but simpler:

protocol Coordinator: class {
    func start()
    func start(with option: DeepLinkOption?) // This is used for deep linking
}

He has extracted the UINavigationController out of the coordinator and into an object called Router (similar to the RayWenderlich approach and others). I like this idea as it has serves the single responsibility principle, and I can see things getting messy if not extracted out.

He has also moved the childCoordinators into a baseCoordinator so that

So this example's coordinator is composed of two protocols, Coordinator & CoordinatorOutput, to allow for optional results after a flow has finished.

protocol CoordinatorOutput {
    var finishFlow: (Item -> Void)? { get set }
}

Terminology

using "show" prefix in coordinator methods when moving to another module, e.g.,

func showItemList()

using "run" prefix in coordinator methods when moving to another flow/coordinator, e.g.,

func runCreationFlow()

Summary

The architecture elements proposed here are:

Coordinators for reasons similar to the description above
- Remove coupling of Navigation and Flow within View Controller
- Coordinators use Routers, Instructors, Factories and Storage
Routers
- For Single Responsibility principle: coordinator manages flow but router manages navigation
- Navigation for different devices, like iPhone, iPad, TV, or Watch
Instructors
- To instruct the coordinator where to flow to, e.g., App start logic or Deeplinks
Factories
- For creating coordinators and modules to allow them to be mocked in tests
- Creates all objects, sets all dependencies, injects properties, and returns protocol
  - Modules’ factory, for creating modules and injecting all dependencies.
  - Coordinators’ factory (optional), in case we need to switch to a different flow.
Storage
- Storage (optional), only if we store any data and inject it into the modules.
Uses a single storyboard for each area
Uses Closures for events between Coordinator and ViewController

I feel this approach has a lot of fo flexibility and looks easy to extend for other cases in navigation flow. I am going to start with this approach and feedback and issues.

Pavle Pesic has blogged about using this pattern How to implement flow coordinator pattern and has some sample code

iOS Academy Coordinator

Video: Swift Coordinator Design Pattern (iOS, Xcode 12, 2021) - iOS Design Patterns

Protocol

protocol Coordinator {
    var navigationcontroller: UINavigationController? { get set }

    funceventOccurred(with type: Event)
    func start()
}

protocol Coordinating {
    var coordinator: Coordinator? { get set }
}

enum Event {
    case buttonTapped
}

Summary

Not extracted out the UINavigationController
Using an event enum to relay events - I don't think there is much gained from this, possibly due to having to use a protocol or coordinating.
Using the Coordinating protocol to allow Viewcontrollers to have a reference to their coordinators, others have used delegates or other methods for the comms between VC and coordinators.
Shows set up with SceneDelegate easy
Talks about how Facebook uses this pattern for the new messenger app (Jan 7, 2021)
Talks about how the Coordinator could have the API dependencies on it rather than the ViewController
Coordinator is not just navigation. Could be Networking, etc
doesn't use them for personal projects but does for his work and commercial-grade projects, useful for scaling
Doesn't use storyboards or xibs, all code

James Haville Coordinator

Video: MVVM iOS App Part 4: View | Event Countdown App

Set of tutorials on creaditing MVVM architecture with Coordinator

Protocol

protocol Coordinator {
    var childCoordinators: [Coordinator] { get }
    func start()
}

Summary

Used to separate navigation code from ViewController
Has an App Coordinator - sets rootViewcontroller init's with window - init(window:)
Can mix and match where we want to use coordinators
Has the navigation controllers created within the Coordinators, or passed with init(navigationController:)
Uses SceneDelegate
Is a simpler version than Andrey Panov's version possible due to trying to fit it into a YouTube video, e.g. no base coordinator, storyboard instantiate extension, factories, etc
- Adds storyboard instantiate extension later in video 3
Uses CoreDate in the next episode part 2
Part 3 adds ViewMdoels in coordinator and passes them to the Viewcontrollers
also shows how to call Coordinator events
- Viewmodels have a reference to Coordinators - so when buttons are tapped they go to the ViewModel then call the Coordinator
- Talks about having a call back instead to avoid this reference
Uses a single storyboard for all views
Shows deinits for clearing up VM, VC and Coordinators
Shows Parent Coordinator for showing coordinator is finished

Ray Wenderlich Coordinator

Article: Coordinator Pattern

Sample Code

Protocol

public protocol Coordinator: class {
  var children: [Coordinator] { get set }
  var router: Router { get }

  func present(animated: Bool, onDismissed: (() -> Void)?)
  func dismiss(animated: Bool)
  func presentChild(_ child: Coordinator,
                    animated: Bool,
                    onDismissed: (() -> Void)?)
}

When to use it?

Use this pattern to decouple view controllers from one another. The only component that knows about view controllers directly is the coordinator.

Consequently, view controllers are much more reusable: If you want to create a new flow within your app, you simply create a new coordinator!

Summary

Uses Routers like Andrey's Coordinator Pattern
- Has an AppDelegateRouter for setting up the window and rootviewcontroller
Uses extension methods for storyboard instantiable
Uses a storyboard for each view
Uses Delegates for events between Coordinator and ViewController

b099l3 / DinkleBot-NativeiOS