> On 2015 Oct 18, at 05:05, Michael de Haan <m...@comcast.net> wrote:
>
> I am using a separate, second “standAlone" Window to display a
> SplitViewController. Design is StoryBoard, for an OS X application.
> From appDelegate, I instantiate the SplitViewController in
> “applicationDidFinishLaunching"
>
> let storyBoard = NSStoryboard(name: "Main", bundle: nil)
> resultWindowController =
> storyBoard.instantiateControllerWithIdentifier("ResultController") as!
> NSWindowController
> resultWindowController.showWindow(self)
It looks to me like you are instantiating a window controller, not a split view
controller. But that’s a better idea anyhow.
> In this particular “testBed” configuration, I initialized a Core Data Stack
> in AppDelegate. My goal is to initialize the splitViewItem’s context once
> AppDelegate has setup the stack.
By “context”, do you mean managed object context? The managed object context
is part of the Core Data stack.
> In the end, I resorted to posting a notification in
> “applicationDidFinishLaunching"
>
> "NSNotificationCenter.defaultCenter().postNotificationName("SetUpComplete",
> object: self.managedObjectContext)”
>
> for the interested parties, but this seems to duplicate a lot of code in each
> of the children’s view controllers.
>
> viz
>
> NSNotificationCenter.defaultCenter().addObserverForName("SetUpComplete",
> object: nil, queue: NSOperationQueue.mainQueue()) { (notification) -> Void in
> self.managedObjectContext = notification.object as!
> NSManagedObjectContext
> }
>
> where “managedObjectContext” is simply a var in the Child View Controller
Alarm bells go off in my head whenever I see instance variables which are used
only as a “shortcut” to objects which are owned by other objects. I suppose it
may not be too dangerous in the case of an app-wide managed object context
which you are sure is going to live for the entire run of the app and never be
replaced. But it’s a very odd design, and getting it via a notification is
even more odd.
> Is there a simpler way of doing this? Maybe initializing the actual
> splitViewController and using this as a source of the context for it’s
> children?
That would just move the oddity from one class to another.
I would remove that instance variable and notification. Instead, get to that
managed object context directly, by adding a method like this to any object
that needs the app-wide managed object context (sorry, in Objective-C):
@property (readonly) NSManagedObjectContext managedObjectContext ;
- (NSManagedObjectContext*)managedObjectContext {
return [(MyAppDelegate*)[NSApp delegate] managedObjectContext] ;
}
Now help me by showing what that would look like in Swift :)
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
