CODEWITHSUNDEEP
objective-cioscore-dataormobject-graph
Dave Finster
Dave Finster

Reputation: 88

Core Data Alternatives on iOS

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:

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.

Upvotes: 4

Views: 2473

Answers (2)

TechZen
TechZen

Reputation: 64428

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.

Upvotes: 0

Daniel Dickison
Daniel Dickison

Reputation: 21882

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:

Upvotes: 1

Related Questions