在修订后的问题中,听起来您有四个AFNetworking
要依赖的操作。那要容易得多。您可能只是添加一个新操作,并使其依赖于其他四个操作:
NSOperation *operation = [NSBlockOperation blockOperationWithBlock:^{
[[NSOperationQueue mainQueue] addOperationWithBlock:^{
// update UI
}];
}];
[operation addDependency:requestOneOperation];
[operation addDependency:requestTwoOperation];
[operation addDependency:requestThreeOperation];
[operation addDependency:requestFourOperation];
[queue addOperation:operation];
该机制本质上为您执行其他四个操作中的每一个的addDependency
KVO 。isFinished
这是使用NSOperation
像 AFNetworking 这样的基于框架的乐趣之一。这种依赖真的很容易做到。
原答案:
如果你必须这样做,你可能会使用一个信号量,例如,你会创建一个信号量:
dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);
你会让你的异步块等待:
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
dispatch_semaphore_wait(semaphore);
dispatch_sync(dispatch_get_main_queue, ^{
//update the UI here
});
});
当条件满足时,原本设置此条件标志的代码将改为:
dispatch_semaphore_signal(semaphore);
话虽如此,除非绝对必要,否则我宁愿不要看到像这样阻塞的队列(甚至是并发的全局队列)。如果其他代码可以发出信号量信号,我不确定它为什么不能自己启动 UI 更新。如果我确实使用了这种信号量技术,至少我会让这个等待过程发生在我自己创建的队列上,而不是全局队列上。
您可以在许多情况下使用的另一种方法,我可能更喜欢使用键值观察:
例如,我可以观察到someProperty
一个对象的 they 属性的变化,obj
如下所示:
[obj addObserver:self forKeyPath:@"someProperty" options:NSKeyValueObservingOptionNew context:NULL];
然后我会实施observeValueForKeyPath
:
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context
{
if ([keyPath isEqualToString:@"someProperty"])
{
NSLog(@"update UI here");
}
}
每当someProperty
我的obj
对象的属性被更新时,我的observeValueForKeyPath
方法就会被调用。
仅供参考,我还要确保在此对象被释放之前,我会删除以下观察者obj
:
[obj removeObserver:self forKeyPath:@"someProperty"];
显然,这假设它someProperty
是Key Value Coding Compliant。但如果是这样,这是一项很棒的技术。