1

I have a CoreData based app that is populated using a web service. When a user changes data on an object in my web service I want to push that change back to my web service.

What is a best practice to accomplish this? I could possibly have a lot of changes objects that need to get sent but the user might not have a connection and I want it to happen in the background.

Do I flag the object in CoreData and needing to be saved remotely? And then batch them every few minutes if possible? I have used Flurry and Google Analytics and they must be doing something like this but I am not sure what the best approach to take is.

Maybe a separate table in Core Data that holds the EntityName and ObjectID that needs updating?

vikingosegundo
  • 52,040
  • 14
  • 137
  • 178
Slee
  • 27,498
  • 52
  • 145
  • 243
  • Have a look at this answer I posted last year: http://stackoverflow.com/questions/5035132/how-to-sync-iphone-core-data-with-web-server-and-then-push-to-other-devices/5052208#5052208 – chris Oct 26 '12 at 07:50

2 Answers2

2

Take a look into NSIncrementalStore, particularly AFIncrementalStore (which utilises NSIncrementalStore).

Good article discussing both here: http://nshipster.com/nsincrementalstore/

InsertWittyName
  • 3,930
  • 1
  • 22
  • 27
  • That looks very interesting but it seems that would replace what I have in place, which is my local data store with a complete remote one - awesome but not what I really need. But I think I can get some ides from this. – Slee Oct 24 '12 at 17:15
2

It depends somewhat on the server API and what kind of information it wants.

Adding a modification flag or date on your Core Data entities is a simple way. Just look for every object where the flag is YES or where the date is more recent than the last sync. It's limited though-- how do you handle telling the server that you deleted an object? You'll probably need to keep an external log of some kind-- for example, a plist that contains outgoing changes waiting to be sent.

A general purpose scheme I've used goes something like this:

  1. Add an observer for NSManagedObjectContextWillSaveNotification
  2. When this notification is received, ask the managed object for insertedObjects, updatedObjects, and deletedObjects to find out what's changed.
  3. Update my outgoing change plist based on those results.
  4. When syncing, read the plist, send the changes, and zero out the list (make sure this is synchronized with the did-save notification so you don't accidentally zero out a change without sending it).

There are several other details you'll run into along the way-- for example, don't erase the outgoing change list if the sync fails.

Tom Harrington
  • 69,312
  • 10
  • 146
  • 170
  • This is the road I started going down and a few minutes in I realized the problem with the deleted object issue. Think I am going to keep a log of changed objects and use that to notify my server. If I can't find the object referenced in my log then it has been deleted and I can notify the server of that. – Slee Oct 25 '12 at 13:05