Home/ Questions/Q 907529
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T16:34:12+00:00

Currently I have one managedContext, many NSArrayControllers of entities which are all pretty interrelated,

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0