Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

iOS app - architecture/sample for synchronizing CoreData against Web-Service

I am looking for either a sample app or a more architectural discussion to build an app, which maintains a local persistent store (CoreData) and keeps it sync against a Web-Service like Flickr. In my case it is Salesforce, but the pattern should be similar to many apps for Flickr, Twitter, IMAP and so on.

Sample questions: where are the best points to invoke the syncing? what are proven datastructures to maintain local changes - maintain a "changed" BOOL in the local store for every unsynched change; I would prefer a field level flag against a record level flag)?

Of course I have to optimize this on my own, knowing the amount of records (100's) and changes (10's per day) and the probability of conflicts (low in my case on a field level).

like image 357
tschloss Avatar asked Apr 18 '12 10:04

tschloss


People also ask

What is Core Data in iOS?

Core Data is a framework that you use to manage the model layer objects in your application. It provides generalized and automated solutions to common tasks associated with object life cycle and object graph management, including persistence.

Is Core Data a Threadsafe?

Core Data is designed to work in a multithreaded environment. However, not every object under the Core Data framework is thread safe. To use Core Data in a multithreaded environment, ensure that: Managed object contexts are bound to the thread (queue) that they are associated with upon initialization.

What database does Core Data use?

Core Data can use SQLite as its persistent store, but the framework itself is not a database. Core Data is not a database. Core Data is a framework for managing an object graph.

Should I use Core Data?

The next time you need to store data, you should have a better idea of your options. Core Data is unnecessary for random pieces of unrelated data, but it's a perfect fit for a large, relational data set. The defaults system is ideal for small, random pieces of unrelated data, such as settings or the user's preferences.


1 Answers

Here's how I would approach this:

  1. Start by modeling a local CoreData/Sqlite database that mirrors your online database.
  2. Add an NSDate lastModified property to every row of each table. This will allow me to track changes at the record level, instead of field level. This helps reduce sync complexity, and in most real world scenarios, record level syncing is sufficient.
  3. Perform an automatic sync when the app starts, and also provide a prominent "Sync" button in your navigation bar. This way the user always has an updated dataset when the app launches after a long period, and can sync the latest changes over the course of a day. I would avoid doing background sync while the app is being used. This will make your app more complex and error-prone when you're trying to tackle other things. So postpone working on background/automatic sync until you have the rest working.
  4. Once I have my sync working reasonably well at launch and on-demand, I would try and support background sync. I would also try and eliminate the "Sync" button, so the user never has to think about syncing - (it's always up to date as far as the user is concerned). But this would be a longer term enhancement, which i would attempt only after I have "on-demand" syncing working rock solid.

Hope this helps you get started. I would love to hear if you think differently about any of this.

like image 53
melsam Avatar answered Oct 13 '22 10:10

melsam