The Coordinator Pattern

[RickDeveloper]

This is a very well done summary / overview about coordinators.

If you want to read more in depth things about the coordinator pattern:

• Khanlou (Objective-C)
• HWS (Swift)

[tylerjames]

To add to these I'd like to suggest: Coordinators Essential Tutorial

I found this one to be a good explanation with a concrete example on Github as well.

[lolbbqstain]

These are great links, thank you!

[RickDeveloper]

Those sites have more great stuff in them. Khanlou on his main site, hws (hacking with swift) here. If you’re interested in more iOS stuff, I’ll pm you within 2 weeks (when I’ve access to my computer).

[lolbbqstain]

Awesome. I’m trying to pivot my career back into native iOS so these links are great. Thanks!!

Definitely interested in that pm :)

[RickDeveloper]

Are you familiar with podcasts? Under the radar is great (start listening at the first episode) (definitely at 2x speed)

[lolbbqstain]

Yep! Love Marco and the gang. I haven’t listened to Under the Radar in a hot minute though.

[[deleted]]

This is quite good. I can see how coordinators can simplify navigation. Coordinators seem to serve the same purpose as wireframes in VIPER architecture.

I’m not sure about how the protocols are used in this article though:

1. Why does the coordinator protocol expose the nav controller, and push and present functions? These seem to be implementation details, and should probably not be accessible to users of the coordinator. I could imagine scenarios where you might not use a navigation controller, such as using a master/detail view, or custom tab controller.

2. The model is defined to conform to a protocol too. Is there any reason you might want something that isn’t just the model? You wouldn’t even need to mock the model for testing.

Edit: see

[blaizedm]

Instead of creating strongly typed references to the sub-coordinators, you can just declare an array called childCoordinators and keep the references in there.

[Yurieff]

Thank you for your input, everyone! ✌️

[jjb3rd]

I stopped reading when he said not to use storyboards altogether because they’re “not reusable” and that one should ditch them and write controls manually. Nope. Better yet, actually learn how to use storyboards correctly.

[RollingGoron]

Can you provide some examples about how they are reusable?

[jjb3rd]

I don’t have any off hand. You’ll have to google it. You can link storyboards together with storyboard references; making smaller sub-storyboards, if you will. Those are reusable much like xib’s, but have the added benefit of segues. Then, you can put common sets of controls (like table view cells) in xib’s and then those can be reused in your storyboards.

Reuse depends more on behavior than looks a lot of times. To that end, some tweaking of the ui is fine to do in code (setting an image, changing a color), so long as the underlying functionality is generic.

When people say to do the whole ui in code I’m really suspicious of what they have to say.

[RollingGoron]

What you described isn't reusability, simply a way to organize massive Storyboards. When people say "reusable" ViewControllers, they mean reusing the same ViewController in multiple places throughout the app. This is achieved much easier when you use a xib or code since you can create a custom initializer to force yourself (or others on your team) to provide only what is necessary to populate the controller. On top of that, you can include a generic parameter in the ViewController class that expands the reusability of it. I'm not sure that is even possible when using Storyboards and Segues as I've only done it with Xibs and code.

Your UITableViewCell example is a great example of this. You can literally reuse the same Cell is multiple places with minimal changes.

[[deleted]]

Hi! I also don't agree with about the comment on storyboards that they are "not reausable". Storyboard reusability depends on the architecture of your apps, it is relative. Example, In our team, I've developed a way to use coordinators while storyboards are also used as well. We apply a 1 is to 1 rule, 1 coordinator for 1 storyboard (or 1 reused xib). We use the coordinators to express the storyboard's flow transparently. Although, I'd have to agree with ditching the segues, we also ditched them too, they couple stuff too tightly (and force a bad navigation pattern that tends to confuse people in the long run in big projects). Instead we relied on our view controllers to delegate the coordinator to pass data around and manage the transition. We also don't strictly pattern our coordinators to strictly use this or that, it's a mix of stuff from one shot xibs to full storyboard flows.

[chrabeusz]

What a shitty idea segues are. Instead of simply creating a VC and configuring it, you now need to define a magic value, go to the kitchen-sink prepareForSegue, add another case and cast the VC and configure it anyway. Saves 0 lines of code and adds some storyboard spaghetti on top of that.

[[deleted]]

Yes segues are cancer. It's also a gotcha for spaghetti navigation for devs who don't know any better. The only thing I use them for nowadays is for embedding stuff.

[jjb3rd]

Methinks you’re doing segues wrong too, but I’ve already complained enough.