4

I've been developing several iOS applications using Core Data and it has been an excellent framework to work with. However, I've encountered an issue whereby we more or less have distributed objects (synced) across multiple platforms. A web/database server backend and mobile devices.

Although it hasn't been a problem until now, the static nature of the data model used by Core Data has me a little stuck. Basically what is being requested is a dynamic forms system whereby forms can be created on a server and propagated to the devices. I'm aware of the technique for performing this with a set number of tables with something like:

  • Forms table
  • Fields table
  • Instance of Forms table
  • Instance Values table

and just linking everything together. What I'm wondering however is if there is an alternative system to Core Data (something above talking to an SQLite database directly) that will allow for a more dynamic object graph. Even a standard ORM would be good if there are options for modifying the schema at runtime. The main reason I want to go down this route is for performance in the sense that I don't want the instance values table exploding with entries (on the local device or server).

My other option is to have the static schema (object-graph) on the iOS devices but have a conversion layer on the server's side which fetches the correct object, populates the properties and saves it to the correct table. Then when the devices comes to sync, it does the reverse and breaks it down into instances. While this saves the server from having a bloated instance value table, it could still be a problem on the device.

Any suggestions are appreciated.

Dave Finster
  • 88
  • 5

2 Answers2

1

Using specific tables/entities for forms and fields, and entities for instances of each, is probably what I would recommend. Trying to manipulate the ORM schema on the fly if it's going to be happening frequently doesn't seem like a good idea in general.

However, if the schema is only going to change infrequently, you can probably do it with Core Data. You can programatically create and/or manipulate the NSManagedObjectModel prior to creating a NSManagedObjectContext. You can also create migration logic so data stored in an old model can be preserved when you update the model and need to recreate the context and stores.

These other SO posts may be helpful:

Community
  • 1
  • 1
Daniel Dickison
  • 21,832
  • 13
  • 69
  • 89
  • Ah I was looking for some details on altering a MOM at runtime. Thanks for those references. In reality, I'm not expecting the model to change frequently - however I'm just keeping app scalability in mind (especially on a mobile device). I'm guessing from the doco that once the model is altered (which thanks to backgrounding, could happen during standard execution), then I'll have to reload the persistent store (and migrate etc) and reinitialise everything database related. It's doable and using this technique I may be able to share the data model between platforms. – Dave Finster Jul 22 '11 at 05:59
0

You need to think carefully about what you are actually modeling.

Are you modeling: (1) the actual "forms" i.e. UI elements, (2) data that might be presented in any number of UI versions e.g. firstName or (3) both?

A data model designed to model forms would have entities like:

Form{
  name:string
  fields<-->Field.form
}

Field{
  width:number
  height:number
  xPos:number
  yPos:number
  label:sting
  nextTab<-->Field.priorTab
  priorTab<-->Field.nextTab
  form<<-->Form.fields
}

You would use this to store data about form as displayed in the user interface. Then you would have a separate entities and probably a separate model to store the actual data that would populate the UI elements that are configured by the first data model.

You can use Core Data to modeling anything you just need to know what you are really modeling.

TechZen
  • 64,370
  • 15
  • 118
  • 145
  • I'm going to be storing both the information for the UI, but also the actual data layout of the form objects. The main thing here is that the forms themselves are dynamic (per client, the backend is multiple-tennent) and as such the object graph changes. I can either model based on fixed tables that describe the objects or dynamically build the object model at runtime based on server. The reason I want to use separate tables for each template is because we could end up with lots of data. I know your not meant to think of Core Data as a database, but performance wise it has to be considered. – Dave Finster Jul 23 '11 at 04:27
  • It sounds like you might actually want a document based design instead of the standard Core Data stack. In the document design, each document has it's own stack and the "document" is really just a persistent store containing just the information associated with one logical document. In your case, each "document" might be composed of two stores: a store for the UI forms and the a store for the data that display in the forms. If everything is different every time there is no design or API need to cram all those differences into one big store. – TechZen Jul 23 '11 at 12:55
  • I know this is for iOS but look at the MacOS NSPersistentDocument class to understand how Core Data works with a document architecture. – TechZen Jul 23 '11 at 12:56