Proposal: Router as even more abstract term to get all Tab, Split, Nav cases into the Game

[MiMo42]

Proposal: TabBarCoordinaators and SplitViewCoordinators itself can also be seen as a Router, maybe we should think of Router as a feature of coordinators. Actually any kind of Coorindator could act like a Router. A special Coordinator acting like a Router could select a tab item of its root view controller ('Tab Coordinator' acting as a 'Tab Router') or select a master or detail controller of its root view controller ('Split Coordinator' acting like a 'Split Router').

Some more tidbit of UISplitViewController: Excerpt of documentation of UISplitViewController: See https://developer.apple.com/documentation/uikit/uisplitviewcontroller

For example, in a compact environment where the primary view controller is a navigation controller, calling showDetailViewController(_:sender:) does not replace the secondary view controller. Instead, the primary navigation controller pushes the view controller onto its navigation stack.

and:

In a horizontally compact environment, the split view controller acts more like a navigation controller, displaying the primary view controller initially and pushing or popping the secondary view controller as needed.

So as user can switch Apps from Regular to Compact environment (Rotation, Resizing Split Screen of two apps on iPad), the navigation controller in effect may change at any time. A split view controller modifies the controller stack when switching between compact and regular environments. That means a child coordinator in tree may use an injected router using a navigation controller that is not the effective one of a split view controller. (Recap: A detail view controller may be added to stack of a master navigation controller)

Maybe we should not store the Router by injection at init of coordinators. Like any view controller is able to get the nearest ancestor in the view controller hierarchy that is a tab bar controller or navigation controller, we could get the nearest Coorinator acting like a Router of a specific type like 'Navigation Router', ' Tab Router' or 'Split Router' by traversing up the hierarchy of coorinators. Just like traversing a responder chain or getting the NSUndoManager in effect on macOS.

That would allow any coorinator to retrieve the diferent kinds of Routers above and use one or more for push, pop, select etc. For example, a coordinator down the road could call a showDetail(coordinator:) function of a 'Split Coordinator' above that acts like a 'Split Router' or just a push() of its nearest 'Navigation Router' when not in split view contexts. Maybe we should add an identifier to Routers to allow Coordnators in sub tree to retrieve a specific Router above (for very complex scenarios like multiple nav/split/tab coorinators in coorinator tree)

Each type of Router may have a specific set of functions defined in a protocol. 'Split Routers', 'Tab Routers' and 'Navigation Routers' do not share much functionality.

What do you think?