• 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: Plugins Utilizing Core Data NSManagedObjectContext
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Plugins Utilizing Core Data NSManagedObjectContext


  • Subject: Re: Plugins Utilizing Core Data NSManagedObjectContext
  • From: Marc Blatt <email@hidden>
  • Date: Thu, 29 Nov 2007 13:32:37 -0800

Thanks for the response and my apologies for the delayed acknowledgment. How much of a performance hit does this approach involve? Is the size of the archived NSDictionary with undefined keys the reason for this or is it inherent in the architecture of the "special kind of managed object" that you provide in the primary app? Or is there another reason for this hit? Our app would not only require adding functionality and user data entry fields specific to the plugin's subject matter, but would also require subject matter data from the plugin to populate popup menus with data for quick entry (simple ex., popup menu populated with types of indie contractors--electrician, plumber, roofer, etc.). However, the data provided by the plugin for our app will require substantially more subject matter data and fields.

Thanks again,

Marc

On Nov 21, 2007, at 3:59 AM, Mike Abdullah wrote:

Depending upon the level of performance from the store you require, you might the consider the rough approach we took in Sandvox. There are two parts:

1.
So that plugin models don't have to be merged with the main application model we provide a special kind of managed object that can accept values for any key. Basically we implement - undefinedValueForKey: and -setValue:forUndefinedKey: such that the values are actually kept in an archived NSDictionary. This allows plugin writers to store whatever data they like without having to worry about Core Data. They don't have to provide their own managed object model.


2.
Plugin writers then provide what is known as a "plugin delegate." This is a non-Core Data object that we automatically hook up to the equivalent plugin object in the model. It receives various delegate messages from the model so that the behaviour can be fully controlled.



Mike.

On 18 Nov 2007, at 06:54, Marc Blatt wrote:

Hello Everyone,

I have an app that I want to extend its functionality with plugins that also provide additional data stored and accessed via Core Data. The thought is that the app has a standard (primary) persistent store containing app specific data, besides the user's data. Each plugin would provide additional functionality, including more sophisticated app specific data relating to the added functionality of the specific plugin. Without the specific plugin loaded, the additional app specific data does not exist. My thoughts are to create a moc for each plugin that contains the added specific data and merge it with the primary moc.


_______________________________________________

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: 
 >Plugins Utilizing Core Data NSManagedObjectContext (From: Marc Blatt <email@hidden>)
 >Re: Plugins Utilizing Core Data NSManagedObjectContext (From: Mike Abdullah <email@hidden>)

  • Prev by Date: Convert hex values in an NSData object to NSString?
  • Next by Date: Re: QuickLook generators in application
  • Previous by thread: Re: Plugins Utilizing Core Data NSManagedObjectContext
  • Next by thread: Including <Agl/agl.h> ...
  • Index(es):
    • Date
    • Thread