在 CloudKit 私有数据库中,所有者创建自定义区域并执行以下操作:
如何实现第3步?
我观察到:
我看到的一个潜在解决方案是让所有者为 CKRecordShared 创建一个单独的 CKShare 并与每个参与者显式共享。然而,这种方法可能会导致用户错误,因为它需要仔细管理每个参与者的多个共享。例如,如果所有者不小心只向参与者 1 发送了一个邀请,或者参与者 1 没有接受所有者的两份邀请,则应用程序将无法正常工作,因为它只能看到预期数据的子集。
是否有更好的方法来处理这种情况,确保多个参与者可以访问 CKRecordShared,而不会引入不必要的复杂性或潜在错误?
CloudKit 并不真正支持您想要完成的任务。给定的
CKShare
与整个记录区域或记录区域内的单个记录层次结构相关联。 'CKSharecan be invited to zero or more participants. Any given
CKRecord` 只能有一个父记录,这意味着该记录只能属于单个记录层次结构。
我只看到两种(也许三种)可能的解决方案,但都不是理想的。
这是您已经提到的解决方案。它将涉及公共共享记录层次结构的
CKShare
和“私有”共享记录的每个层次结构的 CKShare
。正如您所说,这会导致每个共享参与者收到两个邀请,而给定参与者只接受两个邀请之一。或者,用户最初可以接受两者,但后来只选择退出其中一个,使他们只能访问“公共”数据或仅访问“私有”数据。
另一种解决方案涉及为每个参与者复制每个“公共”共享记录一次。每个参与者只需要通过一个
CKShare
来获得他们的副本。虽然这消除了必须向每个参与者发送多个共享邀请的问题,但它会导致许多其他甚至可能更糟糕的问题。数据库所有者现在必须为每个参与者维护“公共”共享数据的副本。一旦一个参与者更新了共享中的记录,所有者将需要检测该更新并在所有其他副本中为其他每个参与者进行相同的更新。这显然非常复杂并且容易出错,更不用说由于所有冗余而效率很低。
如果您的应用程序和“公共”共享数据始终可供应用程序的所有用户使用,那么您可以通过使用“公共”共享数据的公共数据库来消除前两种解决方案的所有问题,并且只使用使用带有
CKShare
的私人数据库来存储每个参与者的“私人”共享记录。这排除了对任何数据冗余的需要,并且每个参与者只需要一个CKShare
。但这仅在应用程序的所有用户都共享一个“公共”共享数据的公共池时才有效。
即使事实并非如此,通过一些额外的逻辑,您仍然可以将公共数据库用于多组“公共”共享数据。您需要额外的逻辑来确保应用程序的用户副本仅向用户显示公共数据库中的数据部分。
虽然我认为 CloudKit 不会很快更新来支持您的需求,但向 Apple 提交增强请求(通过反馈应用程序)解释您的需求以允许单个
CKShare
/邀请来支持也没有什么坏处多个记录层次结构,而不仅仅是当前支持的记录层次结构。