在 Rails 应用程序和 iPhone 应用程序之间同步数据的策略
我编写了许多从 Web 服务中提取数据的 iPhone 应用程序，并且致力于在 iPhone 应用程序和 Web 应用程序之间同步数据，但我一直认为可能有更好的方法来处理同步。
我想知道您使用什么策略在 iPhone（阅读：移动）应用程序和 Rails（阅读：网络）应用程序之间同步数据。
- 是否有任何可扩展性特别好的策略？
- 您是如何处理大量数据的？ （您使用分页响应吗？）
- 如何确保数据不被覆盖？
- 有理由避免使用 Ruby on Rails 吗？
- 如果是这样，您能提出替代方案吗？替代方案有什么更好的地方？
- 哪些策略失败了？
- 您为什么认为这些策略失败了？
我希望能够将所有数据修改保留在服务器上，但是我即将开始工作的特定应用程序需要能够在与网络断开连接时进行操作。
用户将能够在移动设备上更新数据并通过网络应用程序更新数据。
当用户的移动设备连接到服务器时，任何本地更改都将被推送到服务器。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
自从我问这个问题以来已经过去了大约两年，情况已经发生了巨大的变化。现在是后端即服务提供商，例如 Kinvey，Apple 发布了 iCloud，还有一些开放用于与外部数据源同步的源项目如雨后春笋般涌现。
最终，我最终只需要在设备上保留最新服务器数据的副本，因此我向每个模型对象添加了一个时间戳，并设置 Web 服务以提供自我传入的时间戳以来更新的所有对象。 API 将以 FIFO 顺序输出所有对象，我可以在手机上使用这些对象，并且对于后续调用，我会要求提供自设备上的最大时间戳以来更新的所有内容。在实践中，这效果非常好。
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.
这不是你整个问题的答案，但我开始做的从移动角度来看有帮助的事情是在发送服务器同步数据的逻辑和 Web 服务器本身之间放置一个层。
我创建了一个数据实体，它只是一个通用同步对象，我存储了唯一的 ID、有效负载和上次尝试的交付日期。我还有另一段逻辑，从核心数据中获取同步对象并将其发送出去。如果收到良好的响应（即响应实际返回并且响应文本正是我所期望的），则删除该 Sync 对象。这有助于确保您的同步数据正确到达目的地，而不仅仅是迷失在海上。这也是一个很好的线下运营模式。您可以在离线时存储同步对象，并在返回在线后开始按顺序发送它们。
从网络角度来看，Rails Metal 听起来可能适合这种情况。我自己从未使用过它，但根据一些阅读，Metal 似乎适用于可能存在高流量且快速响应至关重要的情况。它基本上消除了 Rails 路由器等的开销。希望有帮助。
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.
如果您使用的是 Rails，您可以看看我刚刚写的 plistifier 插件：查看我的 plistifier 插件 http: //github.com/jeena/plistifier
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