Параллелизм и NSURLConnection

#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.