如果在客户端生成 CKRecordID.recordName 有什么缺点吗？答案

【问题标题】：Any drawback if CKRecordID.recordName is generated on client?如果在客户端生成 CKRecordID.recordName 有什么缺点吗？
【发布时间】：2015-02-23 16:10:36
【问题描述】：

如果在客户端生成recordName，可以提供更流畅的用户体验。

var uuid = NSUUID().UUIDString

你知道这样做有什么缺点吗？

【问题讨论】：

好主意！那样有用吗？这确实可以加速某些情况。
它可以工作，有时它可以加快速度，即，如果我想在客户端上的所有字段都已填充的情况下显示内容，recordName 的字段也适合然后不需要等待审批表服务器
你是怎么做到的？我尝试设置record.RecordID，但那个是只读的。当我尝试设置 record.setValue(recordId.recordName, forKey: "RecordID") 我收到 RecordID 是保留关键字的错误
啊，抱歉，找到了。它在构造函数中：CKRecord(recordType: , recordID: )
Brilliant... 这个建议你应该得到几百分。像这样创建 RecordID 现在是 EVCloudKitDao 的默认行为。 Ik 使演示应用更具响应性。

标签： ios cloudkit ckrecord

【解决方案1】：

recordName 总是在客户端生成。

如果您的应用程序没有提供recordName，CloudKit 框架将在客户端生成一个 UUID，然后再将其发送到服务器。

与让 CloudKit 框架为您生成 UUID 相比，在您自己的代码中生成 UUID 并没有加速。

客户端创建的recordNames 可以帮助您的应用程序将 CloudKit 记录映射到您自己的本地数据存储。如果您不需要这样做，则可以将其留给 CloudKit。

【讨论】：

由于保存操作是异步操作，因此您将能够在回调返回之前知道 id。因此，您可以保存并忘记并仍然使用该 ID。您也可以预先定义多个相互关联的对象，而无需先保存它们。
谢谢-你是对的。我专注于网络上的性能。定义您自己的 recordName 会让您知道在保存完成之前 ID 是什么。
例外情况，如果你可以这样称呼它，是当你不“拥有”记录时——也就是说，我在想CKUserIdentity.userRecordID，它代表 iCloud 帐户持有人，并且是不是你生成的。如果您的架构是围绕 UUID 构建的（如果从 uuidString 构建，则必须采用 8-4-4-12 格式），那么这可能会让您陷入循环[我是根据严酷的经验说的。]

【解决方案2】：

这应该正是给定 CKRecordID 构造函数的设计目的。

只要您不尝试将相同的生成 ID 插入到多条记录中（这可能会迫使您添加更多错误处理），我看不出这里有任何缺点。

【讨论】：