Andrey Panov Coordinator

After doing some reading I quite like the approach taken in these articles by Andrey Panov:
https://medium.com/blacklane-engineering/coordinators-essential-tutorial-part-i-376c836e9ba7
https://medium.com/blacklane-engineering/coordinators-essential-tutorial-part-ii-b5ab3eb4a74

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