A window and its controller are usually seen to own their views...
I was under the impression that views should be owned by thier respective NSViewControllers, which themselves are managed by their NSWindowController. I could absolutely be wrong about this though. When is it appropriate to break things into sub-nibs?
Why do you want or need loose coupling?
This is my first stab at a "real" OSX app, and I'm mostly doing this project to learn how to make these shoebox-style apps. I'm trying to use best practices, and good OOP design practices so I can use the architecture for this app as a kind of basic "skeleton" for future projects. One of my architecture design goals is to avoid "god classes" and to delegate responsibility so that each class manages just the necessesary and sufficient behavior for it's particular role. I certainly don't need loose coupling, but I'm hoping to follow the best practices and use the appropriate amount of coupling so I can avoid getting into bad habits. This may very well be a situation where I've over-factored the design. Regarding coupling, would it be "wrong" for the detail view controllers to know about the source list? I'm under the impression that this is the Main Window Controller's responsibility to pass out this info on a "need to know basis."
I've avoided adding details mostly because I was hoping that by keeping my question generic, it would be more broadly helpful to others trying to do similar things. Additionally, I was trying to provide sufficient detail, without muddying the waters with information not critical to understanding my basic problem. At this point, I think it makes sense to be more specific with the details.
In my sourcelist I have several permanent groups that correspond to different types of collections. I have a NSManagedObject subclass called a SourceListNode which has certain properties related to it's position in the index, the value of it's badge (e.g. the little pill with a number on the righthand side of folders in the mail.app), a bool for if it's a root object in the sourcelist, a name, it's group type, etc. I have several classes inheriting from the SourceListNode, each corresponding to a different grouping in the source list (using iTunes as an example these would be: Library, Store, Devices, Genius, and Playlists). In these subclasses, I'm implementing the specfic properties/behavior related to that grouping type's particular problem domain. At the moment, I've only implemented 2 of these groups, because I want to build the basic class architecture with the minimum amount of complexity. I fully intend to add the additional classes soon, I just want to get the smallest possible set of functionality working first, then it should be fairly trivial to implement the other groups using the implementation of the working ones as a kind of "template".
I originally had the sourcelist in the main window's xib, but I ran into issues with it being a view-based tableview. I can't recall the exact specifics, but it involved problems when the data source/delegate of the NSOutlineView wasn't the file's owner.
In the detail views, I'm swapping them based on the group type of the current selection via a tabless NSTabView. The goal is to have 3 different views showing the same content of the selected sourcelist item in different ways (table, collectionview, and coverflow) for some of the group types and have just one view for other group types. For the Detail Views implemented with 3 swapable views, the Detail View controller, will handle the logic of swaping out between the table, collectionview, and coverflow. Based on the selection in the table in the detail view, the lower half (it has a horizontal splitview) will show the item view with all of the selected item's detials. At the moment, I'm just focusing on getting the tableview working for the detail view for one of my group types. There may be some aspect of YAGNI here, but this is all included in the 1.0 vision. With all of the planned complexity, I'm having a hard time seeing how this could all be done, and properly organized using best practices in a single xib. I'm trying hard to break my problem down into it's logical components so I can work through each piece independantly. I'm also hoping to set things up so that once I figure out how to implement the interactions for one view, it should be fairly easy to replicate it for others (needing only to make tweaks for each particular problem domain).
In my search for answers to my original question here late last night I re-discovered this great article by Martin Pilkington called "
Building a Modern Cocoa App". It's from back in 2010, and it made a lot more sense to me now, since I'm trying to work through some of the problems his solution is addressing. In a way, his post kind of validated my designs and made me feel a bit less crazy last night. In my current implementation, I'm tracking the source list's selection via an NSNotification in the Main Window Controller. When this fires off, the Main window Controller asks the Source List Controller for the selected object (which will be a subclass of my SourceListNode class). Based on the "type" property in the selected node, I swap the detail view, and pass a reference to the selected object to the detail view's controller. The detail view's controller stores this reference as a property and has an NSObjectController (I borrowed this idea from the Pilkington's article) in the detail view's xib that has it's content bound to this property. From here, the NSArrayController controlling the tableview in the detail xib can bind it's values based on the NSObjectController. At least in theory. I still haven't gotten it working as expected because I'm having some KVC issues with my keypaths, and I'm not completely sure about exaclty what values I should be using in the "controller key" in the bindings tab, and figuring out if my NSObjectController should be in entity or class mode. That and a pre-released version of an unnamed IDE (that I can't talk about publicly) has given me a major setback.
Does this seem like a reasonable design? I'm not an expert like you guys, and my main goal for this project is to learn, put a lot of the things I've been reading about into practice and grow, so your feedback and advice are really invaluable and greatly appreciated. Sorry for the long reply, I tried to keep things as focused as possible. Hopefully my explanation of the arcitecture was clear enough to be comprehended.