3

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

我开始将恢复标识符添加到我的视图控制器中，并在我的 AppDelegate 和控制器中连接了所需的功能（当前为空）。

我有一个可能被多个视图控制器引用的对象，因此我计划尝试在我的 AppDelegate 中保留和恢复它，并让相关的视图控制器从 AppDelegate 检索对象。这样做的时机可能很棘手，因为应用程序委托方法 didRecodeRestorableState 在所有视图都已经调用了它们自己的 decodeRestorableStateWithCoder 方法之后发生。

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

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

在这种情况下，是否有任何目的阻止和延迟打开我的文档，所以是的，应用程序需要更长的时间才能打开，但至少可以在任何视图出现之前更正确地恢复所需的所有数据。是否有任何计时器正在运行以确保某些方法不会花费太长时间？当我们处于这种不确定状态时显示不同的视图会更正确吗联系。

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

一如既往地非常感谢任何帮助！干杯

4

1 回答 1

1

最后，我刚刚实现了 UIManagedDocument 完成加载时的通知。这些被所有拥有想要恢复的 coredata 托管对象的控制器拾取。在恢复期间，我保留了编码的 URI，后来在收到此 UIManagedDocument 就绪通知时，我只是将 URI 解码为它们各自的托管对象。

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

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

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

于 2014-09-16T08:29:25.980 回答