在UIManagedDocument中使用Core Data对象声明保存和恢复策略 [英] State preservation and restoration strategies with Core Data objects in a UIManagedDocument
问题描述
我开始尝试为我的iOS应用添加对状态保存和恢复的支持，该应用具有可通过UIManagedDocument访问的Core Data组件.
我开始将还原标识符添加到我的视图控制器中，并已在AppDelegate和控制器中连接了所需的功能(当前为空).
我有一个可能由多个视图控制器引用的对象，因此我计划尝试在AppDelegate中尝试并保存和还原该对象，只是让相关的视图控制器从AppDelegate检索该对象.由于所有视图都已经调用了它们自己的encodeRestorableStateWithCoder方法之后，应用程序委托方法didRecodeRestorableState会发生，因此计时可能会很棘手.
我的主要问题是，这个共享类以及多个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加载所有内容之前.这个问题还在继续...
I'm starting to try and add support for state preservation and restoration to my iOS app, which has a Core Data component to it that I access via a UIManagedDocument.
I'm starting to add the restoration identifiers to my view controllers, and have hooked up the required functions (currently empty) within my AppDelegate, and controllers.
I have an object that could potentially be referenced by multiple view controllers so I plan to try and preserve and restore this within my AppDelegate and just have the relevant view controllers retrieve the object from the AppDelegate. Timing of this could be tricky as the app delegate method didRecodeRestorableState occurs after all the views have already called their own decodeRestorableStateWithCoder methods.
My main problem though is that this shared class as well as multiple ViewControllers all want to have NSManagedObject properties preserved and restored. I hope to be able to use the object's URIRepresentation to facilitate this but the problem I have is my AppDelegate will open my UIManagedDocument within my AppDelegate's willFinishLaunchingWithOptions method. It does this via the UIManagedDocument openWithCompletionHandler method. Due to the threading of this opening the document is successfully opened after all my views and app delegate have already tried to restore their saved state. The AppDelegate does send a notification out once the document is ready for use, so all my view controllers can listen to this notification.
I guess I just wonder is this the best, or even only strategy for dealing with this. My objects will need to hold onto the URIRepresentations that they restore and only once the document (and it's NSManagedObjectContext) is ready try to actually find and set the corresponding NSManagedObjects up that they saved out. As such the restoring is happening a lot later than the calls to perform the restoring would I assume usually perform all their restoring work. I worry whether a controller may potentially appear empty for a brief period of time whilst it waits for the document to open and then get properly initialised.
Is there any purpose in blocking and delaying the opening of my document in this case so yes the app takes longer to open but can at least restore more correctly with all the data required before any views appear. Are there any timers being ran to make sure certain methods don't take too long? Would it be more correct to show a different view whilst we're in this limbo state, not quite sure how to go about this but its the sort of thing you may see with other apps like say the Facebook app which is dependant on a network connection.
I can't seem to find any real explanation of this sort of issue within the documentation so far.
Any help is as always very much appreciated! Cheers
In the end I just implemented notifications from when my UIManagedDocument had finished loading. These were picked up by all controllers that had coredata managed objects it wanted to restore. During restoration I keep hold of the encoded URIs, and later when receiving this UIManagedDocument ready notification I just decoded the URIs to their respective managed objects.
The problem with the shared object that I described I solved by encoded and restoring in one place from my appDelegate and then using another notification out to systems to tell them that this shared object was now fully decoded and available for use.
Not ideal and involved creating quite a lot of hierarchies of methods to ensure all objects were decoded correctly but it works ok.
Sadly since then I've hit a stumbling block where UIDataSourceModelAssociation protocol methods are being called by the OS before my UIManagedDocument has finished opening. Sadly this means that I'm unable to do anything useful. So what i really need to do somehow is defer my app restoration until everything is loaded from a CoreData UIManagedDocument POV. That problem continues...
这篇关于在UIManagedDocument中使用Core Data对象声明保存和恢复策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
