0

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

为什么不使用 iCloud 或Ensembles？我目前在生产应用程序中使用 iCloud 核心数据同步，但对我来说效果不佳。我还想提供独立于 Apple ID 的身份验证，这是我想摆脱 iCloud 的另一个原因。就 Ensembles 而言，由于Dropbox 同步 API的弃用，我不确定这是否仍然适用于 Dropbox 。  

我还没有开始开发图书馆。我正在寻找关于我的计划的反馈，如下所述。此设计基于此 SO answer。 

图书馆的总体设计：

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

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

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

我在这里错过了什么吗？这种方法有哪些潜在的陷阱？我听说同步很难，这种类型的任务应该留给最有经验的开发人员吗？

4

1 回答 1

3

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

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

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

但是让我们假设您决心不使用其他人的框架，那么是的，您的方法在全球范围内听起来都是正确的。

无需通过接口进行 CRUD 操作，您只需观察NSManagedObjectContextDidSaveNotification并从userInfo字典中提取更改即可。

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

如果您的应用程序有少量数据，那么构建这个系统并不是非常困难，但是随着您的数据开始变大，您需要开始使用批处理之类的东西来降低 iOS 上的内存数据。这种事情可能需要很多时间。例如，Ensembles 2 具有与 Ensembles 1 几乎相同的 API，但我花了大约 4 个月的时间来重写诸如批处理之类的东西以提高内存效率。

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

我对像 Ensembles 这样的框架的主张很简单，它已经解决了您需要解决的许多小细节，并且不会将您锁定在特定的后端。如果 Parse 决定提高他们的费用，您将可以自由地搬到其他地方。

于 2015-07-09T08:37:52.357 回答