Re: Best Advice for accessing App Delegate's Managed Object Context
Re: Best Advice for accessing App Delegate's Managed Object Context
- Subject: Re: Best Advice for accessing App Delegate's Managed Object Context
- From: Jerry Krinock <email@hidden>
- Date: Sun, 18 Oct 2015 10:52:21 -0700
> On 2015 Oct 18, at 05:05, Michael de Haan <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden
| References: | |
| | >Best Advice? (From: Michael de Haan <email@hidden>) |