Hello.

At scale, would this not bloat the namespace for all UIResponders, since each has been extended with all of these functions? It could one day become hundreds of public functions on each UIView, UIViewController, and Coordinator.

I think the code is not clean ,so plan to refactor the code

Hi there

I am a bit stumped as to how to use ApplicationCoordinator or what it should inherit from. In the readme the ApplicationCoordinator is suffixed with three dots ... so I'm not sure what it is subclassing.

I am wondering, is there any chance of a sample xcproject that perhaps covers a few cases?

IE:

• Two journeys (1. A root Main menu and 2. Master -> Detail page)?
• How to hide back button/navigation altogether from one journey, but not the other?
• If two journeys have different storyboards altogether?

With thanks

In current implementation of this library on iOS >= 10 in NavigationCoordinator class this function
func willShowController(_ viewController: UIViewController, fromViewController: UIViewController?)

is never called because
navigationController.transitionCoordinator?.notifyWhenInteractionChanges
only works for pop gesture. It leads to inconsistent NavigationCoordinator's state because self.viewControllers array is never cleared and never synched with VC hierarchy.

Hi, I just wanted to ask if you're open to changing how actions are passed through the responder chain to the coordinator.

Currently, UIResponder is extended to adopt all the methods needed to be called by the cells on their corresponding coordinator. My problem with this is that it means all subclasses of UIResponder are now also able to call these methods even though they are unrelated to their own responsibilities.

I got some inspiration from this article ( https://blog.veloxdb.com/2016/05/12/bubbling-events-using-uiresponder-in-swift/ ) and was thinking if it could also be applied in this project.

For example, from the sample project, cart events could be defined in a protocol:

protocol CartEventHandler {
    func cartBuyNow(_ product: Product, sender: Any?)
    func cartAdd(product: Product, color: ColorBox, sender: Any?, completion: (Bool) -> Void)
    func cartToggle(sender: Any?)
}

and the AppCoordinator would then adopt protocol like so:

extension AppCoordinator: CartEventHandler {
    
    func cartBuyNow(_ product: Product, sender: Any?) {
         ...
    }
    
    func cartAdd(product: Product, color: ColorBox, sender: Any?, completion: (Bool) -> Void) {
        ...
    }
    
    func cartToggle(sender: Any?) {
        ...
    }
}

The UIResponder could have an additional function that walks the coordinating responder chain to find a matching responder that adopts this protocol.

public extension UIResponder {
	public var coordinatingResponder: UIResponder? {
		return next
	}
    
    func nextActionableResponder<T>() -> T? {
        guard let responder = self.coordinatingResponder else {
            return nil
        }
        
        return (responder as? T) ?? responder.nextActionableResponder()
    }
}

The PromoCell would then invoke the buy now method on the coordinator via the nextActionableResponder() function.

fileprivate extension PromoCell {
	@IBAction func didTapBuyNow(_ sender: UIButton) {
		guard let product = product else { return }

                (nextActionableResponder() as CartEventHandler?)?.cartBuyNow(product, sender: self)
	}
}

Thanks again for making the library. This is probably the best open source example of Coordinators I can currently find.

Hi Aleksandar,
Thank you for the great coordinator. I am trying to follow your steps in the example.
You have added for example:

extension UIResponder {
	///	Adds given Product to the temporary cart and immediatelly shows Payment screen 
	func cartBuyNow(_ product: Product, sender: Any?) {
		coordinatingResponder?.cartBuyNow(product, sender: sender)
	}

	///	Adds given Product to the cart
	func cartAdd(product: Product, color: ColorBox, sender: Any?, completion: (Bool) -> Void) {
		coordinatingResponder?.cartAdd(product: product, color: color, sender: sender, completion: completion)
	}

	///	show/hide the cart
	func cartToggle(sender: Any?) {
		coordinatingResponder?.cartToggle(sender: sender)
	}
}

Then in the applicationCoordinator you override them:
```
// UIResponder coordinating messages

override func cartBuyNow(_ product: Product, sender: Any?) {
	//	re-route to CartManager and/or CartCoordinator

	let ac = UIAlertController(title: nil, message: "cart-BuyNow", preferredStyle: .alert)
	ac.addAction( UIAlertAction(title: "OK", style: .default) )
	rootViewController.present(ac, animated: true)
}

override func cartAdd(product: Product, color: ColorBox, sender: Any?, completion: (Bool) -> Void) {
	//	re-route to CartManager and/or CartCoordinator

	let ac = UIAlertController(title: nil, message: "cart-Add", preferredStyle: .alert)
	ac.addAction( UIAlertAction(title: "OK", style: .default) )
	rootViewController.present(ac, animated: true)
}

override func cartToggle(sender: Any?) {

	let ac = UIAlertController(title: nil, message: "cart-Toggle", preferredStyle: .alert)
	ac.addAction( UIAlertAction(title: "OK", style: .default) )
	rootViewController.present(ac, animated: true)
}

With no problems at all.

When I try to do the same I get the above error. Could you please point to me what I am missing? 

Thank you.

I would love to include at least the following Shields.io badges

• licence
• pod + version
• version in general

Cocoapods badges they have prebuilt seem to be targeting cocoapods.org, where I can't publish this library.
Not sure how to build the badge targeting the repo here directly.

If parent and children share the same UINavigationController, children should return back the delegate of UINavigationController to parent after stopped.

I think the open override func stop(with completion: @escaping () -> Void) method of NavigationCoordinator should like this:

open override func stop(with completion: @escaping () -> Void) {
     if let parent = self.parent as? NavigationCoordinator,
         parent.rootViewController == rootViewController 
     {
         rootViewController.delegate = parent
     }
     else
     {
         rootViewController.delegate = nil
     }

	for vc in viewControllers {
		guard let index = rootViewController.viewControllers.index(of: vc) else { continue }
		rootViewController.viewControllers.remove(at: index)
	}

	viewControllers.removeAll()

	super.stop(with: completion)
}

Is it right?

I've noticed one critical issue with NavigationCoordinator: handlePopBack is not being called when popViewController(animated: false). In this case navigationController.transitionCoordinator will be nil and pop detection mechanism will not work properly. As the result, we'll get a different viewControllers arrays on coordinator and navigation controller.

p.s.: Default pop animation was disabled to apply a custom CATransition animation.

I see only one good way to solve that by handling the case when fromViewController == nil separately. Whenever viewController which is being shown already exists in viewControllers array, that shall be treated as a pop event.

Feel free to propose a better solution. Meanwhile I will implement this one and test in my app.

I've opened Coordinator.xcodeproj but am unable to compile the project: "No such module 'TinyConstraints'" (and the same for the other external dependencies).

I noticed that there are 4 frameworks listed under the Frameworks map in the project navigator, but they reference non-existing frameworks. For example Carthage/Build/iOS/TinyConstraints.framework, which is not part of the repo. So is there some step missing in the readme? Do I need to do something with Carthage or something?

Improvements in 09b040f broke the following use case:

• App has a single UINavigationController shared between home and account navigation coordinators
• home coordinator shows the initial screens
• account coordinator gets control over home.rootViewController when home creates and starts the account on user event (imagine showing an Account screen over the main app screen)
• User uses the swipe-to-pop to close controller shown by account coordinator

Context before popping:

(lldb) po home.viewControllers
[HomeViewController]

(lldb) po account.viewControllers
[AccountViewController]

(lldb) po navigationController.viewControllers
[HomeViewController, AccountViewController]

When user performs swipe-to-pop gesture, didShowController gets called on account coordinator, but it returns on the check if lastIndex <= index { return } and therefore it:

• don't remove AccountViewController from viewControllers
• don't call handlePopBack(to:)
• don't call parent?.coordinatorDidFinish(...)

Thanks for sharing this design.
I am very keen on learning your implementation of the pattern.

I can't say for sure bc I haven't experienced the flow in use, but it seems this style is quite unique and understandable.

Working my way through the code, it seems like this style can be mixed and match with other architectural styles.

Can show me some sample code or some thoughts on how to incorporate UITabBarController as the root coordinator or as one of the child coordinators?

thanks!

I experienced crashes from time to time when accessing a UIViewController's parentCoordinator property.

As it turns out, the parentCoordinator is realized as an Objective-C Associated Object using the OBJC_ASSOCIATION_ASSIGN association policy, which, in newer Objective-C parlance, means unsafe-unretained.

While I agree that the parent coordinator's lifetime should always exceed the child coordinator's lifetime, there is no way to enforce that. Any object may establish a strong reference to the child coordinator (for instance, by submitting an asynchronous operation) that may keep the child coordinator alive although the parent was instructed to stopChild.

This finally leads to a crash for the next caller that accesses the parentCoordinator property, as the AssociatedKeys.ParentCoordinator contains a stale pointer once the parent coordinator goes away.

I would propose to establish a real weak association where, in this use-case, the parentCoordinator becomes nil. Unfortunately, there is a little quirk required because the only safe association policy is OBJC_ASSOCIATION_RETAIN, requiring a trampoline object that establishes the actual weak reference.

The only equally safe alternative I see would be to make the parentCoordinator a strong reference, but that would lead to retain cycles for obvious reasons.

What are your thoughts?

I am linking a pull request as my proposed solution, open for discussion.

Kind regards
Nico

Quite a few of Coordinator libraries have a problem keeping the Coordinator hierarchy in sync with the ViewController hierarchy (e.g. these ones). How do you think we should prevent that a Coordinator's rootViewController gets dismissed by some dismiss call or similar without the Coordinator noticing it?

I am getting this error message when I compile with carthage:

Reason: Project /Carthage/Checkouts/Coordinator/Example/CoordinatorExample.xcodeproj cannot be opened because it is missing its project.pbxproj file.

Indeed the project.pbxproj file is not there

I wonder if Coordinator.stop() & Coordinator.stopChild() should rewind rootViewController.parentCoordinator value.

Currently rootViewController.parentCoordinator = nil after Coordinator.stop() but it can be that it had different value before Coordinator.start() / Coordinator.startChild() was called.

E.g.
AppCoordinator initialized with rootViewController = AppNavController
and ChildCoordinatorinitialized with the same rootViewController = AppNavController
then after ChildCoordinator.didFinish
AppNavController.parentCoordinator will be nil instead of AppCoordinator.

Of course it can be mitigated with overriding

    override func stopChild(coordinator: Coordinating, completion: @escaping () -> Void) {
        super.stopChild(coordinator: coordinator) {
            self.rootViewController.parentCoordinator = self
        }
    }

Maybe capturing rootViewController.parentCoordinator value in start() / startChild() and setting it back in stop() / stopChild() would be more reliable/foolproof option?

I think Carthage is a great tool to manage dependency ,so most developer like to use it ,So Pls think about whether it should support Carthage?

Something not so good. The params of method extended from UIResponder have to be NSObject.
Well, I can't use struct as model type now.

public struct User {
    let name = ""
}

public extension UIResponder {
    // Error
    // Xcode tips: Method cannot be marked @objc because the type of the parameter cannot be represented in Objective-C
    @objc func navigate(_ user: User) {
        coordinatingResponder?.navigate(user)
    }

    // OK
    @objc func navigateOC(_ list: [String]) {
        coordinatingResponder?.navigateOC(list)
    }
}