Geek Answers Handbook

Basic data alternatives in iOS

I am developing several iOS apps using Core Data, and it is a great environment to work with. However, I ran into a problem on which we more or less distributed objects (synchronized) on several platforms. Backend server and web server database and mobile devices.

Although this has not been a problem so far, the static nature of the data model used by Core Data has made me a bit stuck. Basically, a system of dynamic forms is requested, through which forms can be created on the server and distributed to devices. I know a technique for doing this with a given number of tables with something like:

  • Table of forms
  • Field table
  • Form Instances Table
  • Instance Value Table

and just put it all together. However, I am wondering if there is an alternative system for Core Data (something above that speaks directly to the SQLite database) that will allow the use of a more dynamic graph of objects. Even a standard ORM would be nice if there were options for changing the circuit at runtime. The main reason I want to go along this route is performance in the sense that I do not want the table of instance values ​​to explode with records (on the local device or server).

Another option is to have a static diagram (object-graph) on iOS devices, but with a conversion level on the server side, which extracts the correct object, fills in the properties and saves them in the correct table. Then, when the devices are synchronized, he does the opposite and breaks it into instances. Although this saves the server from having a bloated table of instance values, it can still be a problem on the device.

Any suggestions are welcome.

+4
source share
2 answers

Using certain tables / entities for forms and fields and entities for instances of each of them would probably be recommended. Trying to manipulate an ORM scheme on the fly, if it happens often, does not seem like a good idea in general.

However, if the scheme will only change infrequently, perhaps you can do it with Core Data. You can programmatically create and / or manage an NSManagedObjectModel before creating an NSManagedObjectContext . You can also create migration logic so that data stored in the old model can be saved when the model is updated and the context needs to be recreated and saved.

These other SO posts may be helpful:

+1
source

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

You model: (1) the actual "forms", that is, user interface elements, (2) data that can be represented in any number of versions of the user interface, for example. firstName or (3) both?

The data model intended for modeling forms will have such objects as:

 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 form data, as shown in the user interface. Then you will have separate objects and, possibly, a separate model for storing the actual data, which will fill in the user interface elements that are configured by the first data model.

You can use Core Data to model everything you need to know what you are really modeling.

0
source

More articles:


All Articles