iPad: Design pattern for controller hierarchy in a UISplitViewController?

Situation: The UI of an app is based on a UISplitView with two UINavigationControllers on the left and right side. Several custom views with their corresponding UIViewControllers are embedded in each UINavigationController.

Some possible approaches: The class documentation suggests to use delegates to communicate between subviews, as demonstrated also in this excellent tutorial. If this is done on the level of the custom views (inside each UINavigationController as both Apple's template and Ray's tutorial do), it will eventually get tedious as one would need delegates to handle all possible combinations of view controllers. So it seems better to subclass each UINavigationController and establish delegation between those two only. In that case, however, the navigation controllers may have to forward information to their sub-controllers that they开发者_如何学C do not need to know about - the delegation protocol would need to provide methods for a wide variety of events that might occur and the sub-classes become highly app-specific and duplicate communication of the subviews. As suggested in the answer in this post there are two further possibilities: a) responder chains, and b) notifications.

Question: What's the best design pattern to handle this situation?

I have found a very good post on this question on Cocoa with love. One of the key ideas is to introduce controller objects while iteratively refactoring the design until one ends up with classes that have a single purpose each.

When applying it to a complex view hierarchy, I find the idea of having a larger hierarchy of controllers with limited scope each very appealing and practical. The resulting design will converge after a couple of iterations of refactoring the code.

Practical application: For the left to right communication of view controllers, delegation - as recommended in the Apple documentation - is indeed most practical. If the left view needs to respond to the right view (a rare thing with the master/detail paradigm), I have used KVO as typically these kinds of updates may also be triggered by model objects and KVO is ideal for one-to-many communication patterns. I did not see a use of the target-action mechanism for controller communication.

Update: I have found another blog post which addresses this particular situation on Cocoa is my girlfriend, see also the comment section of that entry. The post is a little basic and does not cover the workflow of a more complex application, but it is still useful for seeing other approaches to this kind of design. Furthermore, there is a tutorial by Ray Wenderlich which discusses such a design with a simple albeit practical example.