Split nib in to several nib files with Core Data..

Question

Currently I have one managedContext, many NSArrayControllers of entities which are all pretty interrelated, and several Windows which each make use of 1 or 2 of the NSArrayControllers. The windows use core data bindings, all set up via cocoa bindings done in IB

I have 1 nib (xib) right now with everything in there. Often when using my application I'll only open one of these windows and I don't want to load everything else. So, as recommended by Apple and common sense, I want to break in to many nibs (one for each Window ideally)

I'm OK as far as how to load separate nib files, but how can I split this all up and still keep them linked to each other? It seems that when I create a new nib I can't connect between that and another. That makes sense for a lot of reasons, but then how do I go about this? Do I simply switch to doing all bindings programmatically and at nib load I set up my bindings then? Maybe it makes sense to put all my NSArrayControllers in a central nib and load them all at once, and then load up each Window's nib when I access that functionality and do the bindings at that point?

Answer 1

You will have to create the necessary bindings in code. I don't know the architecture of your app but in general I would recommend to share the context among the different windowcontrollers of your nibs. Within each nib you can bind your (array, tree, object, ...)controllers the context.

mmalc samples give a good explanation of how bindings work.

ADC on Bindings

Answer 2

You can't connect between nibs but if those nibs share a controller you can connect through that controller. In addition, as you create these new windows you can pass in the NSManagedObjectContext to the new nib and then bind to it.

As an example, if you had the NSManagedObjectContext configured in your AppDelegate (most common) then you could pass that NSManagedObjectContext to the next window as the AppDelegate creates it. In the nib associated with that window, you can then set up a binding to that NSManagedObjectContext property on the window's controller and bind to it.

update

Any object can be referenced across nibs so long as it is in your controllers somewhere. However referencing array controllers across windows is a bad design in general. If you want the selected item passed around then consider passing around just the object using notifications or something. Hard wiring everything is very fragile and an indication that there is something wrong with the design. MVC and dependency injection are the two designs you should be aiming towards in general.

Answer 3

It's a design mistake to connect view controllers (VC) together to tightly. Passing a chunk of data one-way is usually okay for small apps but ideally you don't want to even do that.

Ideally, the data model and only the data model remembers data between views/VCs. Each VC communicates only with the data model and its view. The design goal is to make have each VC controller encapsulated such that it could work standalone without reference to any other view.

The key to accomplishing this is to realize that the data model is the actual core of the application. That is where the critical logic of the app resides. A well designed data model should be UI agnostic and be able to support any kind of interface. For example, the same data model should support a views UI, a web page UI, a command line UI or a scripting interface.

For example, suppose you had an app with a core function to capture two numbers, save them, add them together and return the result. It would be tempting to just do the addition in the VC and immediately display the result. However, since this is a core function, the data model should do the adding. That way, any view or any interface can easily add the numbers just by referring to the function in the data model. If you want to add additional views, each new VC just needs to know about the data model, not any of the other VC.

This also has the practical virtue of making it easy to break the app up into multiple nibs. Each VC gets it own self-contained nib. Since each VC communicates only with the data model, you can load the nibs only when needed and in any order (as long as the data for the VC is in the data model.)

You probably need to back out and reconsider your overall app design. Move the logic and data that connects the VC together into the data model. Then it will be simple to break the VC up into modular nibs.