Plugins Utilizing Core Data NSManagedObjectContext

  • 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
  • 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.
    >
    > 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
  • 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.
    >>
    >>
previous month november 2007 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Go to today