views:

270

answers:

2

I've written many iPhone Applications that have pulled data from web services and I've worked on synchronizing data between an iPhone App and a Web Application, but I've always felt that there is probably a better way to handle the synchronization.

I'd like to know what strategies you have used to synchronize data between your iPhone(read: mobile) Apps and your Rails(read: web) Applications.

  • Are there any strategies that scale particularly well?
  • How have you dealt with large amounts of data? (Do you use paged responses?)
  • How do you make sure that data is not overwritten?
  • Is there a reason to avoid Ruby on Rails?
    • if so, can you suggest an alternative? What is better about the alternative?
  • What strategies have failed?
    • Why do you believe that those strategies failed?

I would like to be able to keep all of the data modifications on the server, but the particular application I am about to start work on will need the ability to operate while disconnected from the network.

The user will be able to update data on the mobile device and update data through the web application.

When the user's mobile device connects to the server any local changes will be pushed to the server.

+1  A: 

Not an answer to your whole question, but something that I started doing that helps from a mobile perspective is putting a layer between the logic that's sending the server sync data and the web server itself.

I've created a data entity that's just a generic sync object that I'm storing a unique ID, the Payload, and last attempted delivery date. I've got another bit of logic that's grabbing Sync objects from core data and sending them off. If a good response is received (i.e. a response actually came back and the response text is what I expected it to be), that Sync object is deleted. This helps to ensure your sync data is getting to the destination properly and isn't just getting lost at sea. This is also a good model for operating offline. You can just store your sync objects while offline and start sending them off in order once you're back online.

From the web perspective, Rails Metal sounds like it might be appropriate for a situation like this. I've never used it myself, but based on some reading it looks like Metal is intended for situations where high traffic could be possible and quick responses are critical. It basically cuts out the overhead of the Rails router and such. Hope that helps.

jtrim
I've been doing something similar, although my synch objects handle the communications as well. I think that I like your approach a little better. Are you saving sync objects in CoreData? Or just Archiving them?
jessecurry
Yeah, they're saved as coredata objects.
jtrim
A: 

If you're using rails you could have a look at my plistifier plugin I just wrote: Check out my plistifier plugin http://github.com/jeena/plistifier

Jeena