• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Core Data, bindings and synchronizing.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Core Data, bindings and synchronizing.


  • Subject: Re: Core Data, bindings and synchronizing.
  • From: Michael Jurewitz <email@hidden>
  • Date: Mon, 12 Feb 2007 10:51:44 -0800


On Feb 12, 2007, at 10:23 AM, Ryan Homer wrote:

Hello all. Let's say we have a class that encompasses an NSManagedObjectModel, NSPersistentStoreCoordinator and NSManagedObjectContext (moc). If the header file is imported into IB and a class is instantiated, an array controller can then make use of the moc and be bound to a view via Core Bindings.

Now, let's say that I use another separate instance of this class in another part of my code, not bound to any view, and that I use this class to manipulate some data. For example, I might want to add a new "record" (entity?) to my data.

This does NOT automatically update my view because there are now two instances of the moc and each is in a different state. I have tried using a shared moc and this DOES indeed keep the view in sync with my background data changes, but I was wondering what solutions others have used in cases like this. One immediate "situation" that arises is that there is now no simply way to know when we are no longer using the moc and therefore release it from memory.

Is anyone somehow keeping the two instances of the moc in sync?


Hi Ryan,

In a document-based approach this is generally why the MOC is maintained by the NSPersistentDocument subclass; thus in your MyDocument.nib you can bind an array controller's managed object context to File's Owner's managedObjectContext key. File's Owner, in this case, refers is the NSPersistentDocument subclass.

Similarly, if you plan on having numerous nib files, this is why your custom NSWindowController subclasses should probably maintain a connection back to the document object. That way, any nib used by that window controller can bind to a key path such as 'documentController.managedObjectContext' through File's Owner (which is the window controller subclass in this case).

Unless you really need to keep two MOC's in sync, and you haven't listed any explicit reason to that effect, I wouldn't recommend going down that road.

HTH,

-Michael Jurewitz

/*****************************************
Apple DTS Engineer
Cocoa - Core Data - Bindings

Save the Date.
WWDC 2007 | June 11-15, San Francisco
http://developer.apple.com/wwdc

email@hidden
*****************************************/

_______________________________________________

Cocoa-dev mailing list (email@hidden)

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: 
 >Core Data, bindings and synchronizing. (From: Ryan Homer <email@hidden>)

  • Prev by Date: Core Data, bindings and synchronizing.
  • Next by Date: Re: Printing crash
  • Previous by thread: Core Data, bindings and synchronizing.
  • Next by thread: Re: Core Data, bindings and synchronizing.
  • Index(es):
    • Date
    • Thread