数据持久化方案解析（十七） —— 基于NSPersistentC

2020-11-11  本文已影响0人  刀客传奇

版本记录

版本号 时间
V1.0 2020.11.11 星期三

前言

数据的持久化存储是移动端不可避免的一个问题，很多时候的业务逻辑都需要我们进行本地化存储解决和完成，我们可以采用很多持久化存储方案，比如说plist文件（属性列表）、preference（偏好设置）、NSKeyedArchiver（归档）、SQLite 3、CoreData，这里基本上我们都用过。这几种方案各有优缺点，其中，CoreData是苹果极力推荐我们使用的一种方式，我已经将它分离出去一个专题进行说明讲解。这个专题主要就是针对另外几种数据持久化存储方案而设立。
1. 数据持久化方案解析（一） —— 一个简单的基于SQLite持久化方案示例（一）
2. 数据持久化方案解析（二） —— 一个简单的基于SQLite持久化方案示例（二）
3. 数据持久化方案解析（三） —— 基于NSCoding的持久化存储（一）
4. 数据持久化方案解析（四） —— 基于NSCoding的持久化存储（二）
5. 数据持久化方案解析（五） —— 基于Realm的持久化存储（一）
6. 数据持久化方案解析（六） —— 基于Realm的持久化存储（二）
7. 数据持久化方案解析（七） —— 基于Realm的持久化存储（三）
8. 数据持久化方案解析（八） —— UIDocument的数据存储（一）
9. 数据持久化方案解析（九） —— UIDocument的数据存储（二）
10. 数据持久化方案解析（十） —— UIDocument的数据存储（三）
11. 数据持久化方案解析（十一） —— 基于Core Data 和 SwiftUI的数据存储示例（一）
12. 数据持久化方案解析（十二） —— 基于Core Data 和 SwiftUI的数据存储示例（二）
13. 数据持久化方案解析（十三） —— 基于Unit Testing的Core Data测试（一）
14. 数据持久化方案解析（十四） —— 基于Unit Testing的Core Data测试（二）
15. 数据持久化方案解析（十五） —— 基于Realm和SwiftUI的数据持久化简单示例（一）
16. 数据持久化方案解析（十六） —— 基于Realm和SwiftUI的数据持久化简单示例（二）

开始

首先看下主要内容：

在本教程中，您将学习如何使用NSPersistentCloudKitContainer集成Core Data和CloudKit。内容来自翻译。

首先看下写作环境：

Swift 5, iOS 14, Xcode 12

在将数据持久保存在应用程序中时，Core Data是一个不错的选择。自OS X Tiger和iOS 3以来，它一直是最古老，最成熟的Apple框架之一。

但是，跨设备同步Core Data的历史比较不稳定。 Apple在iOS 10中弃用了原始的iCloud sync API，直到iOS 13才引入NSPersistentCloudKitContainer，并没有替换它。 NSPersistentCloudKitContainer在您的Core Data存储和CloudKit（Apple的iCloud数据存储框架）之间架起了桥梁。

在本教程中，您将在名为PlaceTag的应用程序中集成CloudKit和Core Data，该应用程序可为您访问的地方保存标题，描述和图像。

具体来说，您将学习如何：

注意：本教程假定您对Core Data，对象图，数据持久性框架和iCloud有一定的了解。有关Core Data框架的更多信息，请参阅Getting Started with Core Data。

此外，iCloud和CloudKit需要付费的Apple开发人员帐户才能运行。如果您未注册Apple Developer Program或Apple Developer Enterprise Program，则将无法跟进。

打开入门项目。 然后，在Xcode中打开starter项目。

选择一个开发团队，因为此步骤涉及根据developer ID设置数据，因此请选择您的（付费）团队以继续。 将bundle ID更新为组织内唯一的名称。 最后，选择一个iCloud容器名称。 此值应该是唯一的，并以iCloud开头。 Apple建议采用iCloud.{reverse DNS}.{app name or name for group}的形式。 例如：iCloud.com.yourcompany.yourapp。

构建并运行。 您会看到一个空列表，准备好亲爱的日记！

点击Add Place按钮并创建一个条目。 如果需要，可以附加照片库中的图像。

完成后，点击Save Place，该位置将出现在列表中。

您可能已经注意到，Xcode在构建项目时会向您发出警告，指出NSPersistentStoreUbiquitousContentNameKey在iOS 10.0中已弃用。 这是因为该应用程序已经通过iCloud同步了Core Data，但是使用了不推荐使用的旧方法。 在更新到新的同步系统之前，您将接下来查看该代码。

Core Data Stack Initialization

在本教程中，您将把应用程序从旧的Core Data iCloud同步转换为新的CloudKit系统。 许多此类工作将在一个文件中进行。 打开CoreDataStack.swift并签出init（）：

private init() {
  //1
  guard let modelURL = Bundle.main
    .url(forResource: "PlaceTag", withExtension: "momd") else {
    fatalError("Error loading model from bundle")
  }

  //2
  guard let mom = NSManagedObjectModel(contentsOf: modelURL) else {
    fatalError("Error initializing mom from: \(modelURL)")
  }

  //3
  let psc = NSPersistentStoreCoordinator(managedObjectModel: mom)

  //4
  context = NSManagedObjectContext(
    concurrencyType: .mainQueueConcurrencyType)

  //5
  context.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy

  //6
  context.persistentStoreCoordinator = psc

  do {
    //7
    try psc.addPersistentStore(
      ofType: NSSQLiteStoreType,
      configurationName: nil,
      at: CoreDataStack.storeURL,
      options: CoreDataStack.storeOptions)
  } catch {
    fatalError("Error adding store: \(error)")
  }
}

如果您使用的应用已经存在很长时间了，那么您可能会使用与此类似的代码来设置Core Data stack。这是此代码的逐步说明。

storeOptions类属性包含前面提到的不赞成使用的NSPersistentStoreUbiquitousContentNameKey。这告诉系统将应用程序的iCloud文档目录的SQLite文件将保存在一个普遍存在的容器中。

那是很多步骤。您希望新系统更容易，对吗？在更新应用程序之前，是时候了解新方法与旧方法的区别了。

1. How Core Data in iCloud Used to Work

iCloud具有三种用于存储用户数据的系统：

iOS上iCloud中Core Data的第一次迭代是在文档存储之上进行的，并使用了相同的iCloud API。

对于由SQLite支持的存储，Core Data提供了无处不在的持久存储。它使用了位于应用程序无处不在容器中的SQLite事务持久性机制。

在连接到iCloud帐户的每个设备上，您的应用程序的每个实例都维护自己的本地Core Data存储文件。换句话说，当数据在本地更改时，Core Data将更改日志文件写入到您应用的默认遍历容器中。

同样，当更改日志从连接到同一iCloud帐户的另一台设备到达时，Core Data会更新您应用的SQLite数据库本地副本。

看起来很有趣，但这种实现从未可靠地起作用。开发人员必须找到解决问题的方法，才能制定出可行的同步解决方案。这些问题使Apple意识到这是行不通的。

苹果公司推出iOS 10时，它已弃用iCloud中的Core Data和NSPersistentStoreUbiquitousContentNameKey，并建议开发人员改用CloudKit。这使开发人员可以选择使用废弃的API或滚动自己的CloudKit支持的同步。

2. Core Data and CloudKit Today

从iOS 13和Xcode 11开始，Core Data项目的Xcode模板还可以选择集成CloudKit。

Core Data和CloudKit在定义中都具有三个主要元素： objects, models and stores。 简而言之，models描述objects，而stores则是objects持久化的地方。

查看下表：

您熟悉Core Data列中的项目。 在CloudKit命名法中，您可以将NSManagedObject的概念映射到CKRecord，将NSManagedObjectModel的概念映射到Schema，将NSPersistentStore的概念映射到CKRecordZone或CKDatabase。

根据session in WWDC 2019的一次会议，苹果工程师编写了数千行代码来封装用于同步，调度和错误恢复的常用模式，以使Core Data与CloudKit一起使用。 幸运的是，这次苹果表现出色。

Preparing PlaceTag for CloudKit

现在该转向新的Core Data CloudKit同步方法了。

1. Setting up the Project

在项目导航器中，单击PlaceTag项目。 选择PlaceTag target，然后单击Signing & Capabilities选项卡项，如下面的屏幕快照中的数字1到3所示。

取消选择iCloud Documents，然后选择CloudKit，如上面屏幕快照中的数字4所示。

许多应用程序和用户都可以访问iCloud。但是，称为容器的分区会隔离并封装数据以保持其私有性。

已经使用CloudKit的应用程序不能将Core Data和CloudKit与它们现有的CloudKit容器一起使用。为了全面管理数据镜像的所有方面，Core Data拥有从Core Data模型创建的CloudKit schema。现有的CloudKit容器与此schema不兼容。

考虑到这一点，您需要创建一个新的容器。此值应该是唯一的，并以iCloud开头。如前所述，Apple建议采用iCloud.{reverse DNS}.{app name or name for group}的形式。例如：iCloud.com.yourcompany.yourapp。

值得注意的是，公司的多个应用可以访问一个容器。

不幸的是，Apple不允许您以后删除容器，因此请明智地选择容器名称。

选择名称后，如果Xcode并未自动为您选择容器，请选择容器。

2. Adding Invisible Push Notification Support

每当容器中的记录发生更改时，CloudKit都会向已注册的设备发送静默推送通知。

要使用此功能，您需要向应用程序添加两项功能。如上图数字5所示，点击+按钮，然后添加Push Notification（如果Xcode并未自动为您添加）。

然后添加Background Modes。

在Background Modes部分中，选择Remote Notifications。

Core Data和CloudKit集成的优点在于，系统可以处理侦听和响应远程通知所需的所有工作。 如果您在没有Core Data的情况下使用CloudKit，则必须执行一些额外的步骤（超出本教程的范围）才能实现。

3. Migrating Existing Data

现在是时候将您的Core Data stack绑定到您刚创建的CloudKit容器了。 打开CoreDataStack.swift。

您需要做的第一件事是更新和移动现有的数据库文件。 使用旧的同步系统，您的SQLite文件位于特殊位置，并且格式略有不同。 NSPersistentStoreCoordinator可以为您处理移动和更新它。 添加以下方法：

func migrateIfRequired(_ psc: NSPersistentStoreCoordinator) {
  //1
  if FileManager.default.fileExists(atPath: CoreDataStack.storeURL.path) {
    return
  }

  do {
    //2
    let store = try psc.addPersistentStore(
      ofType: NSSQLiteStoreType,
      configurationName: nil,
      at: CoreDataStack.storeURL,
      options: CoreDataStack.storeOptions)
    //3
    let newStore = try psc.migratePersistentStore(
      store,
      to: CoreDataStack.storeURL,
      options: [NSPersistentStoreRemoveUbiquitousMetadataOption: true],
      withType: NSSQLiteStoreType)
    //4
    try psc.remove(newStore)
  } catch {
    print("Error migrating store: \(error)")
  }
}

这是此代码的作用：

4. Modernizing the Core Data Stack

现在您已经准备好进行迁移，可以更新到更现代的Core Data stack。正如您所希望的那样，初始化过程已得到简化。您问如何精简？好吧，继续删除整个init（）。

添加类型为NSPersistentContainer的惰性属性：

private lazy var persistentContainer: NSPersistentContainer = {
  //1
  let container = NSPersistentContainer(name: "PlaceTag")
  //2
  migrateIfRequired(container.persistentStoreCoordinator)
  //3
  container.persistentStoreDescriptions.first?.url = CoreDataStack.storeURL
  //4
  container.loadPersistentStores { _, error in
    if let error = error as NSError? {
      fatalError("Unresolved error \(error), \(error.userInfo)")
    }
  }
  return container
}()

使用此代码的操作如下：

persistent container拥有用于UI的managed object context，因此，接下来，您需要从常量更改context的定义：

let context: NSManagedObjectContext

为一个计算属性：

var context: NSManagedObjectContext {
  persistentContainer.viewContext
}

您现在已经现代化了Core Data设置，并删除了旧的iCloud同步。

构建并运行。 您将看到之前添加的相同数据。

您仍然可以像以前一样添加新地点。 但是，您所有的数据现在都是本地的。

5. Moving to CloudKit

只要persistent store是NSSQLiteStoreType存储，并且使用的数据模型与CloudKit的限制兼容，使用Core Data的应用就可以移至CloudKit。 例如，CloudKit不支持唯一约束，未定义属性或所需关系(unique constraints, undefined attributes or required relationships)。

NSPersistentContainer有一个子类，称为NSPersistentCloudKitContainer。 该persistent container能够管理由CloudKit支持的存储和非云存储。

通过将NSPersistentContainer替换为NSPersistentCloudKitContainer，PlaceTag的Core Data stack将启用CloudKit。 过渡就像云本身一样柔和而流畅！ 接下来就是您要做的。

更改persistentContainer属性以反映这些更改。 将所有NSPersistentContainer引用替换为NSPersistentCloudKitContainer：

private lazy var persistentContainer: NSPersistentCloudKitContainer = {

和

let container = NSPersistentCloudKitContainer(name: "PlaceTag")

还要在返回容器之前添加以下行：

container.viewContext.automaticallyMergesChangesFromParent = true

您无需在此进行太多更改，只需更改类和automaticallyMergesChangesFromParent即可。 通过设置此标志，UI将反映自动同步，该同步几乎是通过无声推送通知发生的。

构建并运行。 一切似乎都没有改变。 但是，这一次，如果您在要测试的设备上登录到iCloud，则iCloud会同步添加到PlaceTag的位置。 您可以通过在两台设备上运行该应用程序来验证这一点。 万岁！

注意：确保在真实设备上测试同步。 当涉及静默推送通知时，模拟器并不可靠。

Viewing the Project in CloudKit Dashboard

该应用程序现在应该将您的位置同步到CloudKit，但是下一步是验证它确实是。

打开CloudKit Dashboard，并使用您在测试设备上使用的相同Apple ID登录。 CloudKit仪表板向您致意。

您会在左侧看到为应用程序创建的容器，在右侧看到每个容器的可用选项。

选择PlaceTag的容器，然后单击Data。 将显示Records页面。

在此页面上，选择com.apple.coredata.cloudkit.zone作为zone。 现在，您可以使用过滤器查询可用数据。

选择查询Query按钮，然后选择CD_Place作为Type。

CD_是什么？ CD代表Core Data。 苹果正在繁重地将Core Data转换为CloudKit对象。 此前缀是他们防止命名空间冲突的工作的一部分。

在Filter下，选择Custom，并查询具有CD_Title of Iceland的记录。 如果您创建了一个带有其他标题的地方，请在此处键入。

单击Save，然后单击Query Records。

您在应用中创建的对象将显示在此处。 您可以编辑或删除对象，更改将通过您设置的远程推送通知反映在应用程序中。

恭喜你！您已成功使用CloudKit转换PlaceTag，因此其数据可在多个设备上持久保存。

您已成功将CloudKit支持添加到您的Core Data应用程序中。尽管CloudKit是一个复杂的框架，但Apple仍使它易于使用-至少与Core Data一起使用。

如前所述，Core Data是一个非常古老的Apple框架。它具有许多功能，超出了本教程的范围。 CloudKit尽管相对较新，但也具有许多有趣的功能。

使用PlaceTag，您几乎不会看到Core Data和CloudKit的表面。模型中的实体与其他实体没有关系。您没有涉及自定义通知处理和许多其他功能。

有关Core Data和CloudKit的大量资源，您可以用来更深入地探讨此主题，包括：

后记

本篇主要讲述了基于NSPersistentCloudKitContainer的Core Data和CloudKit的集成示例，感兴趣的给个赞或者关注~~~

上一篇 下一篇

猜你喜欢

热点阅读