#objective-c #concurrency #nsurlconnection
#objective-c #параллелизм #nsurlconnection
Вопрос:
Недавно я исследовал и работал с NSURLConnection
параллелизмом и. Похоже, существует несколько разных подходов, и те, которые я пробовал (очереди отправки и очереди операций), в конечном итоге, похоже, работали правильно.
Одна из проблем, с которой я столкнулся с параллелизмом и NSURLConnection
, заключается в том, что методы делегирования не вызываются. После некоторых исследований я выяснил NSURLConnection
, что их необходимо либо запланировать в основном цикле выполнения, либо NSOperation
запустить в основном потоке. В первом случае я вызываю NSURLConnection
так:
connection = [[NSURLConnection alloc] initWithRequest:request delegate:self startImmediately:NO];
[connection scheduleInRunLoop:[NSRunLoop mainRunLoop] forMode:NSDefaultRunLoopMode];
[connection start];
И в последнем случае, как это:
- (void)start
{
if (![NSThread isMainThread])
{
[self performSelectorOnMainThread:@selector(start) withObject:nil waitUntilDone:NO];
return;
}
connection = [[NSURLConnection alloc] initWithRequest:request delegate:self];
}
Методы делегирования обрабатывают все остальное, и оба, похоже, работают правильно.
В случае, когда я использовал очередь отправки, я сделал то же самое, что и в первом случае (запланируйте NSURLConnection
в основном цикле выполнения).
Мой вопрос в том, в чем разница между этими двумя подходами? Или они на самом деле одинаковы, но просто другой способ их реализации?
Второй вопрос: зачем это нужно? Я также использую NSXMLParser
inside an NSOperation
, и для этого, похоже, не требуется основной цикл выполнения или основной поток, он просто работает.
Ответ №1:
Думаю, я сам это понял. Поскольку оба NSURLConnection
и NSXMLParser
являются асинхронными, они требуют цикла выполнения для сообщений делегата, когда они выполняются в фоновом режиме. Насколько я знаю сейчас, основной поток автоматически поддерживает цикл выполнения; основной цикл выполнения. Таким образом, оба решения для NSURLConnection
I posted гарантируют, что основной цикл выполнения используется для асинхронной части, либо сообщая соединению использовать основной цикл выполнения для сообщений делегата, либо перенося всю операцию в основной поток, который также автоматически запланирует соединение в основном потоке.
То, что я придумал сейчас, заключается в том, чтобы поддерживать цикл выполнения в моих пользовательских NSOperation
классах, поэтому мне больше не нужно выполнять какое-либо планирование или проверку потоков. В конце метода я реализовал следующее (void)start
:
// Keep running the run loop until all asynchronous operations are completed
while (![self isFinished]) {
[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
}
Комментарии:
1. СПАСИБО ВАМ ООООООЧЕНЬ БОЛЬШОЕ! вы, сэр, потрясающий!
2. Всегда пожалуйста 🙂 Кстати, в настоящее время я бы рекомендовал вместо этого использовать AFNetworking , я думаю, что это намного проще в использовании, чем
NSURLConnection
etc.