问题描述
我有一个基本的问题，同步openWithCompletionHandler：（UIManagedDocument）与主要活动。
I have a basic problem synchronizing openWithCompletionHandler: (UIManagedDocument) with the main activities.
情况：
我有一个单例类管理共享UIManagedDocument。这个类提供了一种应该在正常状态下递送文档的方法（即创建或打开它，无论什么是必要的）。
但是因为openWithCompletionHandler：它的主要工作在后台我的程序应该等待设置fetchedResultsController异步，直到文档真正打开。当数据库未就绪时，viewWillAppear方法（当前）不生成有用的输出。
等待会对我确定，但收到通知可能是更好的方式。也许viewWillAppear证明不是一个正确的点，因为没有在runloop中调用setupFetchedResultsController。
Situation:I have a singleton class managing a shared UIManagedDocument. This class provides one method which should deliver the document in a normal state (i.e. creates or opens it, whatever is neccessary).But because openWithCompletionHandler: does its main job asynchronously in the background my program should wait with setting up the fetchedResultsController until the document is really open. The "viewWillAppear" method (currently) produces no useful output when the database is not ready.Waiting would be ok for me, but getting notified probably would be the better way. Maybe viewWillAppear turns out not to be the right point to setupFetchedResultsController because not called in a runloop.
是否有标准模式来实现这一点？
Is there a standard pattern to achieve this?
更多的背景（不是那么重要我假设）
我正在一个小的iOS 5.1应用程序涉及CoreData UIManagedDocument。
我类似于从去年秋天的第14课在iTunes-U的斯坦福课程的例子。一切工作正常，直到我试图将UIManagedDocument的处理从UITableViewController类移动到一个单独的类处理我的文档。
在原始版本中，FetchedResultsController在完成处理程序中设置。
Bit more of background (not so important I assume)I am working on a little iOS 5.1 app involving a CoreData UIManagedDocument.I resembled the example from Lesson 14 from last fall's Stanford course in iTunes-U. Everything was working fine until I tried to put the handling of the UIManagedDocument away from the UITableViewController class into a seperate class handling my document.In the original version the FetchedResultsController was set up in the completion handler.
推荐答案
我建议遵循在。
writeup on UIManagedDocument单例和一个关于performWithDocument的例子。您的fetchedResultsController设置代码应该放在performWithDocument：^ {}块中。
You will find a complete writeup on UIManagedDocument singleton and an example on performWithDocument. Your fetchedResultsController setup code should really go in the performWithDocument:^{} block.
还要注意，openWithCompletionHandler不是线程安全的 - 打开文档时并发调用performWithDocument会导致崩溃。对我来说，解决方案是非平凡的（而且完全针对特定应用），因此如果遇到相同的问题，我建议您查看，它通知文档状态更改，可以是多个文档打开器的同步点。
Also note that openWithCompletionHandler is not thread safe - concurrent invocations of performWithDocument while opening the document will cause a crash. The solution for me was non-trivial (and quite app-specific), so if you run into the same problem, I suggest you looking into UIDocumentStateChangedNotification which notifies document state changes and can be your synchronization point for multiple document openers.
如果你有兴趣，有一些片段，
Some snippet if you are interested,
首先在MYDocumentHandler的init中，设置一个额外的通知：
First in MYDocumentHandler's init, setup an additional notification at the end:
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(documentStateDidChange:)
name:UIDocumentStateChangedNotification
object:self.document];
然后在关键打开/创建部分的performWithDocument，@synchronized（self.document）
Then in performWithDocument, @synchronized (self.document) on the critical open/creation sections to make sure only one thread enters at a time, and block further threads until open/creation succeeds.
最后添加以下函数：
- (void)documentStateDidChange:(NSNotification *)notification
{
if (self.document.documentState == UIDocumentStateNormal)
@synchronized (self.document) {
... unblock other document openers ...
}
}
对于阻塞/解除阻塞线程，YMMV。我使用dispatch_semaphore_t和一些dispatch_queues来满足应用程序特定的要求。你的情况可能就像等待完成或放弃其他线程一样简单。
As for block/unblocking threads, YMMV. I used a dispatch_semaphore_t along with some dispatch_queues to satisfy app-specific requirements. Your case could be as simple as waiting for completion or dropping other threads.
这篇关于iOS5.1：同步任务（等待完成）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！