@GNZ Complex coordinators have been really rare in our case. The main reason has been because we’ve since introduced a way to nest Coordinators within each other (this is a topic for another blog post). Once you have that, the problem then becomes a purely a matter of modelling your navigation structure correctly into the actual code. To give an example. Imagine you have 10 screens in your app. It wouldn’t make sense to have a single Coordinator to manage all navigation paths between those 10 screens - it would quickly become unmanageable. But if, say, 5 of these screens are your signup flow, 1 of them is your login flow, 1 is your main ‘launcher’ type screen, and then you have 2 screens for upgrading to a new tier, plus another for one of your features, we would break it down like this:
- One top-level coordinator to switch between Signup/Login/Main
- One sub-coordinator to switch between the signup screens
- The login screen is a single screen, so no need for a Coordinator
- One sub-coordinator for ‘Main’ to switch between the launcher, the upgrade path, and the feature
- One sub-coordinator to manage the two upgrade screens
- The feature only has one screen, so there’s no need for a Coordinator
I should mention, this is a bit different to what I describe in the article. In my blog post, I wouldn’t even use the top-level navigator, or the ‘Main’ sub-coordinator. I would just use the ‘feature navigator’ to navigate between these coordinators. But with sub-coordinators you can model the whole application like this…