ios - UIManagedDocument 中 Core Data 对象的状态保存和恢复策略

Question

我开始尝试为我的 iOS 应用程序添加对状态保存和恢复的支持，它有一个核心数据组件，我可以通过 UIManagedDocument 访问它。

我开始将恢复标识符添加到我的 View Controller ，并在我的 AppDelegate 和 Controller 中连接了所需的功能(目前为空)。

我有一个可能被多个 View Controller 引用的对象，所以我计划尝试在我的 AppDelegate 中保存和恢复它，并让相关的 View Controller 从 AppDelegate 中检索该对象。由于应用程序委托(delegate)方法 didRecodeRestorableState 发生在所有 View 已经调用了它们自己的 decodeRestorableStateWithCoder 方法之后，因此时机可能会很棘手。

但我的主要问题是这个共享类以及多个 ViewController 都希望保留和恢复 NSManagedObject 属性。我希望能够使用对象的 URIRepresentation 来促进这一点，但我遇到的问题是我的 AppDelegate 将在我的 AppDelegate 的 willFinishLaunchingWithOptions 方法中打开我的 UIManagedDocument。它通过 UIManagedDocument openWithCompletionHandler 方法执行此操作。由于此打开的线程，在我的所有 View 和应用程序委托(delegate)已尝试恢复其已保存状态后，文档已成功打开。 AppDelegate 确实会在文档准备好使用后发出通知，因此我所有的 View Controller 都可以收听此通知。

我想我只是想知道这是不是最好的，甚至是处理这个问题的唯一策略。我的对象将需要保留它们恢复的 URIRepresentations，并且仅在文档(及其 NSManagedObjectContext)准备就绪后尝试实际查找并设置它们保存的相应 NSManagedObjects。因此，恢复发生的时间比执行恢复的调用要晚很多，我认为通常会执行所有恢复工作。我担心 Controller 在等待文档打开然后正确初始化时是否可能会在短时间内显示为空。

在这种情况下，阻止和延迟打开我的文档是否有任何目的，所以是的，该应用程序需要更长的时间才能打开，但至少可以更正确地恢复所有 View 出现之前所需的所有数据。是否运行任何计时器以确保某些方法不会花费太长时间？当我们处于这种边缘状态时显示不同的 View 是否更正确，不太确定如何解决这个问题，但它是您可能会在其他应用程序中看到的那种东西，比如依赖于网络的 Facebook 应用程序连接。

到目前为止，我似乎无法在文档中找到对此类问题的任何真正解释。

我们一如既往地非常感谢您的帮助!干杯

Answer 1

最后，当我的 UIManagedDocument 完成加载时，我只是实现了通知。这些被所有具有要恢复的 coredata 管理对象的 Controller 拾取。在恢复期间，我保留编码的 URI，稍后当收到这个 UIManagedDocument 就绪通知时，我只是将 URI 解码为它们各自的托管对象。

我描述的共享对象的问题是通过在我的 appDelegate 的一个地方编码和恢复，然后使用另一个通知系统告诉他们这个共享对象现在已经完全解码并可以使用来解决的。

p>

不理想，涉及创建很多方法层次结构以确保所有对象都被正确解码，但它工作正常。

可悲的是，从那时起，我遇到了一个绊脚石，在我的 UIManagedDocument 完成打开之前，操作系统正在调用 UIDataSourceModelAssociation 协议(protocol)方法。可悲的是，这意味着我无法做任何有用的事情。所以我真正需要做的是推迟我的应用程序恢复，直到从 CoreData UIManagedDocument POV 加载所有内容。这个问题继续...