Я смотрел класс NSURLConnection
, который можно было использовать для установления синхронизации или асинхронного подключения к URL-адресу, а затем для извлечения его данных... было внесено много изменений в этот класс с помощью IOS 5 и я " мы видели, что они ввели некоторые формальные протоколы, связанные с аутентификацией или загрузкой, но я не вижу, например, если сообщение connection:didReceiveResponse:
(которое ранее было отправлено делегату и что оно больше недоступно) по-прежнему доступно в некоторых протоколы. Как реализовать асинхронное соединение и получить, например, HTTP-заголовки, как только будет получен ответ? Я уверен, что есть способ лучше, чем использовать NSURLConnection
вместе с сообщением connection:didReceiveResponse:
. Такие методы, как stringWithContentsOfURL
, всегда загружают контент синхронно? Что вы используете для реализации асинхронных загрузок в ваших приложениях, избегая устаревших методов и реагируя на такие события, как _http response received_m и т.д.? Запускаете ли вы синхронные загрузки в фоновых задачах, если это возможно?
Методы NSURLConnection больше недоступны в IOS5
Ответ 1
NSURLConnectionDelegate
стал формальным протоколом (это был неофициальный протокол в предыдущих версиях). В этом протоколе объявляются следующие (не устаревшие) методы:
-
connection:didFailWithError:
-
connectionShouldUseCredentialStorage:
-
connection:willSendRequestForAuthenticationChallenge:
Кроме того, существуют два подпротокола, которые соответствуют NSURLConnectionDelegate
:
NSURLConnectionDataDelegate
используется для делегатов, которые загружают данные в память и объявляют следующие методы, некоторые из которых я уверен, что вы найдете знакомы:
-
connection:willSendRequest:redirectResponse:
-
connection:didReceiveResponse:
-
connection:didReceiveData:
-
connection:needNewBodyStream:
-
connection:didSendBodyData:totalBytesWritten:totalBytesExpectedToWrite:
-
connection:willCacheResponse:
-
connectionDidFinishLoading:
NSURLConnectionDownloadDelegate
используется для делегатов, которые хранят данные непосредственно в файле диска, и объявляет следующие методы:
-
connection:didWriteData:totalBytesWritten:expectedTotalBytes:
-
connectionDidResumeDownloading:totalBytesWritten:expectedTotalBytes:
-
connectionDidFinishDownloading:destinationURL:
Как вы можете видеть, вы все равно можете использовать своих предыдущих делегатов, возможно, с некоторыми незначительными изменениями.
Для получения дополнительной информации см. документ iOS 4.3 в iOS 5.0 API и NSURLConnection.h в локальной установке Xcode. Когда выпущена новая версия SDK, ее не редкость для документации внутри файлов заголовков быть более надежной, чем документация, доступная в библиотеке разработчика. Для последнего требуется некоторое время.
Ответ 2
Я только что столкнулся с этой проблемой. Похоже, что отправка асинхронного запроса упрощается с помощью блоков и NSOperationQueue
.
+ (void)sendAsynchronousRequest:(NSURLRequest *)request queue:(NSOperationQueue *)queue completionHandler:(void (^)(NSURLResponse*, NSData*, NSError*))handler
Это означает, что делегат теперь используется только для проверки подлинности и сбоев.
Ответ 3
НЕТ! Они НЕ предназначены для использования при проверке подлинности и сбоях, если внимательно изучить библиотеку Apple.
Начиная с введения класса +(void)sendAsynchronousRequest:queue:completionHandler:
в объект класса NSConnection, многие вещи, которые могут выполнять как можно больше методов NSConnectionDelegate
по-прежнему, теперь могут использоваться в формальных протоколах под названием "NSConnectionDataDelegate
" и NSConnectionDownloadDelegate
, открывая новую комнату для добавления больше возможностей для методов NSURLConnection
. (от iOS5 включено)
Поэтому я думаю, что это улучшение, а не ограничение их использования.
Ответ 4
Даже я не нашел документацию на веб-сайте Apple
Он должен был быть доступен здесь