1

I have recently started experimenting with Xcode following the introduction of Swift. I have no background in Objective C, but I am making progress, especially with Cocoa Bindings and Core Data. I am playing around with an OSX application which has one xib and one window and is bound to a Core Data model. So far everything works just fine and I can populate a Table View with no issues.

My next step is to include a second window with another Table View bound to my Core Data model. I found this impossible to achieve because I couldn't access the AppDelegate when I tried to bind the second Table View to the Core Data model.

So I tried to create a second window in the MainMenu xib; now binding is possible but it seems to be very clumsy. Surely a second window demands its own xib and, if so, how on earth do I bind to the AppDelegate?

My goal is to use Coocoa Bindings as far as possible to eliminate "glue code", but all my research only reveals Objective C examples, some of which are very old, involve a huge amount of program code and are not at all relevant to Xcode v6.1.

I'm a newbie to Xcode, but so far I love it and would appreciate any advice or assistance.

David Rönnqvist
  • 56,267
  • 18
  • 167
  • 205
Ian Wilson
  • 13
  • 3

1 Answers1

0

The single-coordinator application template adds that "App Delegate" object to the MainMenu.Xib, and it's somewhat magically connected to the NSApplication object's delegate, in that the App Delegate object is created by the Nib loading process and attached to the NSApplication instance. It's fairly impossible to duplicate that object in another Nib. You can really create havoc trying to do so.

The simplest way to do what you want in any other Nib is to bind to the Application with a keypath beginning with "delegate." Voila, you have what you want.

Others will insist that the delegate object shouldn't own the core data stack, and you should move all that boilerplate code to some other place. Or, that each view controller should be passed the MOC pointer as a property (see comments below)... but that's not really relevant to this question.

YMMV, this answer is given from the Objective-C universe, but the language shouldn't matter.

Community
  • 1
  • 1
stevesliva
  • 5,351
  • 1
  • 16
  • 39
  • Thanks @stevesliva. Your solution is perfect and works with no issues. However, after posting my question I did some more research and found that inserting `let managedObjectContext = (NSApplication.sharedApplication().delegate as AppDelegate).managedObjectContext` in the second window controller allowed me to bind the secondary Array Controller to the File's Owner and retain the `self.managedObjectContext` key path. But which is the better solution; to use your approach, or the other one? – Ian Wilson Nov 25 '14 at 05:18
  • Your comment is considered the better approach. (Passing the moc pointer around between controllers) And a side benefit is that you can use throwaway child contexts in the second window that allow easy cancel/save. So self.moc would be a child of the delegate moc, and you'd save to the parent only if the user wanted to keep all their gui changes. I answered as I did because binding through the application is actually not mentioned much as a solution for this issue, but it is the easiest. – stevesliva Nov 25 '14 at 06:54