核心数据通过Parse同步

Question

我有兴趣开发一个库，通过Parse移动后端跨设备同步核心数据模型。我想镜像iCloud核心数据同步尝试提供的功能。

为什么不使用iCloud或Ensembles？ 我目前在生产应用程序中使用iCloud核心数据同步，它是not working well for me。我还想提供独立于Apple ID的身份验证，这是我想要离开iCloud的另一个原因。至于Ensembles，我不确定这是否仍然适用于deprecation of the dropbox sync API的Dropbox。

我还没有开始开发这个库。我正在寻找有关我的计划的反馈，概述如下。此设计基于this SO answer。

图书馆的总体设计：

1. 该库将提供一个标准的核心数据堆栈，用于设置持久性存储协调器和托管对象上下文。所有标准核心数据CRUD操作都将通过库提供的接口进行。

2. 每次进行CUD操作时，同步操作对象将保存到后台的Parse，其中包含重现操作所需的所有信息。这包括：发生的操作类型，操作对象的唯一标识符，以及在创建操作的情况下，将提供父对象和关系。

3. 每个操作都有一个与之关联的change_id编号。每次设备下载并执行操作时，它都会存储与该操作相关的最新change_id。
4. 在上传每个同步操作之前，设备会向服务器发送请求，以确保存储的change_id号码与本地存储的号码匹配。如果服务器上的change_id较高，它将首先下载所有同步操作并执行它们，然后上传自己的同步操作。
5. 冲突（两个设备在离线时编辑相同的值）将通过确定哪个设备最后更改了值来解决。

我在这里遗漏了什么？这种方法有哪些潜在的缺陷？我听说同步很难，如果这类工作留给最有经验的开发人员吗？

Answer 1

我不是最不偏向的响应者，因为我是Ensembles框架的开发者，但让我提出一些想法。

关于Ensembles本身，它是一个后端不可知的框架。是的，它适用于iCloud和Dropbox Sync API，但也适用于CloudKit，Dropbox Core API（不推荐使用）和WebDAV。还有一个定制的Node.js服务器，它有一个软件包，允许您使用Heroku和S3自己托管数据。

所以即使你不想坚持使用Apple，也有其他选择。但更重要的是，您可以编写自己的后端适配器类。大多数是大约500行代码，您可以将其基于现有类之一。这将允许您创建一个存储数据的后端，并使用Parse进行身份验证，并将数据合并到Ensembles中。这样做的另一个好处是，您可以在将来轻松转移到其他后端，或者提供它们作为选项。 （CloudKit绝对值得一看。）

但是我们假设你决定不使用别人的框架，那么是的，你的方法听起来是全球性的。

您可以观察NSManagedObjectContextDidSaveNotification并从userInfo词典中提取更改，而不是让CRUD操作通过界面。

我相信你会发现许多你没想过的小事，而这些细节往往会使同步变得困难。一个这样的例子是你需要构建足够强大的东西来处理失败，例如在应用程序退出之前Parse操作没有完成。您可能需要在每个对象上都有一个更改标记，以便您可以检索自上次同步以来更改的标记。

如果您的应用程序拥有少量数据，那么构建此系统并不是非常困难，但随着您的数据开始变大，您需要开始使用批处理等内容来保持iOS内存数据不足。这种事情可能需要很长时间。例如，Ensembles 2与Ensembles 1具有相同的API，但我花了大约4个月的时间来重写诸如批处理以节省内存的事情。

我使用您描述的方法构建了一个原型应用程序（app是社交的，不是同步的，因此没有Ensembles）。我使用的是CloudKit，它与Parse非常相似。使用本地Core Data缓存，大约有1000行Swift代码可以使整个数据上传/下载正常工作。它肯定是可行的，特别是如果你已经熟悉核心数据的话。否则可能会有学习曲线。

我对像Ensembles这样的框架的倡导只是它已经解决了你需要解决的许多小细节，而且它不会把你锁定在一个特定的后端。如果Parse决定提高他们的费用，你可以自由地搬到其他地方。