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

Plugins Utilizing Core Data NSManagedObjectContext


  • Subject: Plugins Utilizing Core Data NSManagedObjectContext
  • From: Marc Blatt <email@hidden>
  • Date: Sat, 17 Nov 2007 22:54:24 -0800

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.

By way of example (attempting to make this as simple as possible for this purpose), let's say my primary app is the department and employees NSPersistentDocument Core Data tutorial app. The primary app has two entities, department and employee. Thus, the user can enter information about a specific department, its employees and their related manager. Now, let's say that the plugin is called Indie Contractors and that it adds functionality for tracking independent contractors that work with and/or are being supervised by certain employees of a company's specific department. The plugin would add an IndieContractor entity and functionality to track who the indie contractor answers to, etc.

Obviously, there would have to be a migration of data from the original persistent store if a user's document already includes user data (e.g., employees and departments) prior to adding the plugin. This could cause a number of problems if multiple plugins are developed for different added functionality. If, for example, another plugin were created for brother-sister company related project tracking (ex., Bro-Sis plugin), then migration would need to be handled for three different scenarios--migration of data for purchasers of Bro-Sis plugin alone, Indie Contractors alone, and combined Bro-Sis Indie Contractors plugins. This would become exponentially impractical if more plugins are added. Not to mention reversion of data to the original primary persistent store if the user decides they don't need the added functionality (e.g., trial users). Please remember, this is only a simplified example of the added app specific data.

The more I write, the more I come to the conclusion that providing different versions of the app may be best. But, before starting down this path, I thought it would be wise to ask all of you your thoughts on the road not taken. Can a plugin be used to merge additional persistent store data to an existing persistent store? Any thoughts on the feasibility of this approach... Any other possible approaches?

Thanks,

Marc
_______________________________________________

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


  • Follow-Ups:
    • Re: Plugins Utilizing Core Data NSManagedObjectContext
      • From: Mike Abdullah <email@hidden>
  • Prev by Date: Re: NSView clickable area
  • Next by Date: Re: Leopard performance penalty (3x slower), NSPopAutoreleasePool
  • Previous by thread: Re: NSView clickable area
  • Next by thread: Re: Plugins Utilizing Core Data NSManagedObjectContext
  • Index(es):
    • Date
    • Thread