我开始尝试向我的 iOS 应用程序添加对状态保存和恢复的支持，该应用程序有一个核心数据组件，我可以通过 UIManagedDocument 访问该组件。
我开始将恢复标识符添加到我的视图控制器中，并在我的 AppDelegate 和控制器中连接所需的函数（当前为空）。
我有一个可能被多个视图控制器引用的对象，因此我计划尝试在我的 AppDelegate 中保留和恢复它，然后让相关的视图控制器从 AppDelegate 检索该对象。这个时间可能很棘手，因为应用程序委托方法 didRecodeRestorableState 发生在所有视图已经调用自己的decodeRestorableStateWithCoder 方法之后。
我的主要问题是这个共享类以及多个 ViewController 都希望保留和恢复 NSManagedObject 属性。我希望能够使用对象的 URIRepresentation 来促进这一点，但我遇到的问题是我的 AppDelegate 将在 AppDelegate 的 willFinishLaunchingWithOptions 方法中打开我的 UIManagedDocument。它通过 UIManagedDocument openWithCompletionHandler 方法执行此操作。由于此打开的线程，在我的所有视图和应用程序委托已尝试恢复其保存的状态后，文档已成功打开。一旦文档可供使用，AppDelegate 就会发送通知，因此我的所有视图控制器都可以监听此通知。
我想我只是想知道这是处理这个问题的最佳策略，甚至是唯一的策略。我的对象需要保留它们恢复的 URIRepresentations，并且只有在文档（及其 NSManagedObjectContext）准备好后，才尝试实际查找并设置它们保存的相应 NSManagedObjects。因此，恢复发生的时间比执行恢复的调用晚得多，我假设通常会执行所有恢复工作。我担心控制器在等待文档打开然后正确初始化时是否可能会在短时间内显示为空。
在这种情况下，阻止和延迟打开我的文档是否有任何目的，所以是的，该应用程序需要更长的时间才能打开，但至少可以更正确地恢复任何视图出现之前所需的所有数据。是否运行任何计时器来确保某些方法不会花费太长时间？当我们处于这种不确定状态时，显示不同的视图会更正确吗？不太确定如何解决这个问题，但您可能会在其他应用程序中看到这种情况，例如依赖于网络的 Facebook 应用程序联系。
到目前为止，我似乎在文档中找不到此类问题的任何真正解释。
一如既往，非常感谢任何帮助！干杯
最后，我只是实现了 UIManagedDocument 加载完成时的通知。这些由所有具有要恢复的 coredata 管理对象的控制器拾取。在恢复期间，我保留编码的 URI，稍后当收到此 UIManagedDocument 就绪通知时，我只是将 URI 解码为各自的托管对象。
我描述的共享对象的问题是通过从 appDelegate 在一个地方进行编码和恢复来解决的，然后使用另一个通知发送给系统，告诉他们该共享对象现在已完全解码并可供使用。
不理想，涉及创建相当多的方法层次结构以确保所有对象都正确解码，但它工作正常。
遗憾的是，从那时起，我遇到了一个绊脚石，在我的 UIManagedDocument 完成打开之前，操作系统正在调用 UIDataSourceModelAssociation 协议方法。可悲的是，这意味着我无法做任何有用的事情。所以我真正需要做的就是推迟我的应用程序恢复，直到从 CoreData UIManagedDocument POV 加载所有内容。这个问题还在继续...
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
