在UIManagedDocument中使用Core Data對象的狀態保存和恢復策略

Question

我開始嘗試添加對狀態保存和恢復的支持到我的iOS應用程序，該應用程序具有我通過UIManagedDocument訪問的Core Data組件。

我開始將恢復標識符添加到我的視圖控制器中，並在我的AppDelegate和控制器中連接了所需的功能（當前為空）。

我有一個可能被多個視圖控制器引用的對象，所以我打算嘗試在AppDelegate中保留和恢復它，並讓相關的視圖控制器從AppDelegate中檢索對象。 這可能是棘手的，因為app委托方法didRecodeRestorableState發生在所有視圖已經調用自己的decodeRestorableStateWithCoder方法之后。

我的主要問題是這個共享類以及多個ViewControllers都希望保留和恢復NSManagedObject屬性。 我希望能夠使用對象的URIRepresentation來促進這一點，但我遇到的問題是我的AppDelegate將在我的AppDelegate的willFinishLaunchingWithOptions方法中打開我的UIManagedDocument。 它通過UIManagedDocument openWithCompletionHandler方法完成此操作。 由於此開頭的線程，在我的所有觀看和應用委托代表已經嘗試恢復其保存狀態后，文檔成功打開。 一旦文檔准備好使用，AppDelegate會發送通知，因此我的所有視圖控制器都可以收聽此通知。

我想我只是想知道這是處理這個問題的最好的，甚至是唯一的策略。 我的對象需要保留它們恢復的URIRepresentations，並且只有在文檔（和它的NSManagedObjectContext）准備就緒時才嘗試實際查找並設置它們保存的相應NSManagedObjects。 因此，恢復比執行恢復的調用要晚得多，我認為通常會執行所有恢復工作。 我擔心控制器是否可能在短時間內顯示為空，同時它等待文檔打開然后正確初始化。

在這種情況下阻止和延遲打開我的文檔是否有任何目的，是的，應用程序需要更長時間才能打開，但至少可以在任何視圖出現之前使用所需的所有數據更正確地恢復。 是否有任何計時器被運行以確保某些方法不會花太長時間？ 在我們處於這種不穩定的狀態時顯示不同的視圖會更正確，不太確定如何解決這個問題，但是你可能會看到其他應用程序，例如依賴於網絡的Facebook應用程序連接。

到目前為止，我似乎無法在文檔中找到任何關於此類問題的真正解釋。

任何幫助一如既往地非常感謝！ 干杯

Answer 1

最后，我剛剛從我的UIManagedDocument完成加載時實現了通知。 所有具有想要恢復的coredata托管對象的控制器都會選擇這些。 在恢復期間，我保持編碼的URI，稍后當收到此UIManagedDocument就緒通知時，我只是將URI解碼為各自的托管對象。

我描述的共享對象的問題我通過編碼和從appDelegate在一個地方恢復然后使用另一個通知系統告訴他們這個共享對象現在已完全解碼並可供使用來解決。

不理想並且涉及創建相當多的方法層次結構以確保所有對象都被正確解碼但它工作正常。

可悲的是，從那時起，我遇到了一個絆腳石，在我的UIManagedDocument完成打開之前，操作系統正在調用UIDataSourceModelAssociation協議方法。 可悲的是，這意味着我無法做任何有用的事情。 所以我真正需要做的是延遲我的應用程序恢復，直到從CoreData UIManagedDocument POV加載所有內容。 那問題還在繼續......