Strategies for Synchronizing Data Between a Rails App and iPhone App

Question

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.

Answer 1

It's been about 2 years since I asked this question and the landscape has changed drastically. The are now backend-as-a-service providers such as Kinvey, Apple has released iCloud, and a few open source projects for synchronizing with external datasources have sprung up.

Ultimately, I ended up only needing to keep a replica of the latest server data on the device so I added a timestamp to each of my model objects and setup the webservice to provide all of the objects updated since the timestamp that I passed in. The API would output all of the objects in FIFO order, I could consume those on my phone, and for subsequent calls I would ask for everything updated since the maximum timestamp I had on my device. In practice this worked out very well.

Answer 2

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.