A coordinator design pattern, which makes heavy use of delegates and protocols, allows you to let your UIViewControllers do what they are best at - displaying views! Things like navigation, networking, and in this example, interaction with HealthKit, are all delegated to the coordinator.
Hi Josh
I am a budding iOS developer from India and I have complex modal View Controllers presentation structure in my app. I was trying to implement coordinator pattern tutorial published in Feb 2018 and again today you presented it. The presentation is very good and the promise of coordinator pattern in terms of simplifying navigation and giving freedom to choose which VC to present is very good. My only question is that while implementing the pattern I have huge memory problem and how to solve the memory management issues. Can you please do a screencast on this aspect of coordinator pattern too.
Hi - that’s a pretty complicated question to answer in the forums - are you experiencing memory problems with both the older tutorial and this screencast?
Hi Josh
Concept is same in both, though I have yet to implement the project you’ve mentioned in the screencast and have been working on the older tutorial project only. But the problem remains, everyone in my circle who is an iOS developer as well as while browsing the QA forum in the coordinator pattern tutorial my experience is that people struggle with memory management issue and it grows exponentially if you have more than 10 View Controllers in your app. This is the single biggest reason behind people not implementing coordinator pattern in their projects in spite of its appeal.
What kind of leaks are you experiencing and how have you tried debugging it already?
Hi thaxsillion,
I am experiencing unbound memory growth pointing to the fact the previous view controllers are not getting cleared from the stack. I have tried using Instruments allocation and memory leak tool to solve this. At any given point of time, I just want two view controllers the one who has been presented and the one who is presenting it. In normal presentation scene (simple modal presentation) I took care of this by declaring a root View Controller in app delegate and while presenting making sure to dismiss all view controllers on top of it and then presenting a new view controller. Here in coordinator pattern, I am unable to get a clarity on how to dismiss view controllers before presenting a new one. So the problem in coordinator pattern boils down to how to dismiss all existing view controllers atop the presenting view controllers and then present a view controller on top of it to clear memory and for this, I am still unable to find a solution to.
Hi Josh,
This problem of dismissing all existing view controllers other than the root View controller or a single view controller before presenting one in coorodinator pattern is the topic which I found iOS developers struggle with. This, dismissing a view controller before presenting a new view controller, leads to memory issues and presenting a screencast on this aspect of coordinator pattern is what I was referring to in my previous reply.
Hi josh,
I’ve used coordinator pattern for a while. Coordinator is good but we’re facing some drawbacks in the meantime.
Do you have any idea about above issues?
Hi Josh,
great tutorial. Question, how can we apply this if we are using CoreData and/or Firebase? Where do we do the network calls, JSON queries, etc. Is it all going to be in the 1 Coordinator file? Do you have an example for a more complex app? Thank you.
Hi,
as far as I can see these coordinators don’t do much. Actually it’s just extracted code from UIViewController to Coordinator’s extension. In other words I could just extend UIViewController and achieve the same result.
What’s more now CoordinatorViewController becomes super-massive ViewController, because now it aggregates actions and behaviors for multiple ViewControllers, of course through extensions, but still.
If you think in terms of reusability, CoordinatorViewController still will be very specific for the project, so there is no benefit in this area either.
If you think in terms of testability you don’t get much more in this area, not more than testing just single methods from ViewControllers.
If you think in terms of interchanging implementations of delegates in ViewController in real world there is not often such need. Why would you like to dynamically replace actions on buttons etc.? Maybe for testing ViewController, but in this approach it should be as simple as possible so there is not much to test and I’d prefer to cover it in UI tests.
Am I missing something?
Regards,
Wojciech