что именно NSUrlConnection ASynchronous означает?

Question

я запутался, в чем разница между синхронным NSUrlConnection и ASynchronous NSUrlConnection? Есть синхронный или ASynchronous? если мы используем detachNewThreadSelector в методе connectionDidFinishLoading, это ASynchronous NSUrlConnection? какой способ лучше? любой учебник ...

Answer 1

Синхронный означает, что вы запускаете запрос NSURLConnection и ждете его выполнения.

Асинхронный означает, что вы можете инициировать запрос и выполнять другие действия, пока NSURLConnection загружает данные.

Что является "лучшим"?

Синхронность очень проста: вы настраиваете ее, запускаете и ждете возвращения данных. Но ваше приложение находится там и ничего не делает, пока все данные не будут загружены, не произойдет какая-либо ошибка или не истечет время ожидания запроса. Если вы имеете дело с чем-то большим, чем небольшой объем данных, ваш пользователь будет сидеть там в ожидании, что не принесет хорошего впечатления пользователю.

Асинхронный требует немного больше работы, но ваш пользователь может делать другие вещи, пока запрос делает свое дело, что обычно предпочтительнее. Вы настроили некоторые методы делегатов, которые позволяют отслеживать данные по мере их поступления, что полезно для отслеживания хода загрузки. Этот подход, вероятно, лучше для большинства случаев использования.

Вы можете выполнять как синхронные, так и асинхронные запросы с помощью NSURLConnection. Документация Apple содержит четкое объяснение двух подходов и методов делегирования, необходимых для последнего подхода.

Answer 2

Кажется, что вы объединяете синхронные / асинхронные соединения и потоки. В своем приложении я использовал асинхронные соединения в качестве альтернативы многопоточности.

Допустим, вы хотите загрузить большой файл, не вызывая зависания интерфейса. У вас есть два основных варианта:

1. Асинхронное соединение. Вы начинаете с + connectionWithRequest:delegate: (или одной из других опций, не связанных с автоматическим выпуском), и она загружает биты файла, вызывая вашего делегата, когда происходит интересная вещь. Runloop все еще продолжается, поэтому ваш пользовательский интерфейс остается отзывчивым. Конечно, вы должны быть осторожны, чтобы ваш делегат не вышел за рамки.

2. Синхронный. Вы начинаете соединение с + sendSynchronousRequest:returningResponse:error:, но код ждет, пока загрузка не будет завершена. Вам действительно нужно создать новый поток (или одну из операций с потоками более высокого уровня, которые поддерживает Какао), иначе пользовательский интерфейс будет блокироваться.

Какой вариант «лучший» или наименее болезненный, будет зависеть от архитектуры вашего приложения и того, чего вы пытаетесь достичь. Если вам все равно нужно создать поток для продолжительного процесса, вы можете выбрать второй вариант. Вообще я бы сказал, что первый вариант самый простой.

Все это очень хорошо задокументировано на сайте разработчика Apple .

Answer 3

Что-то, что не было упомянуто в других ответах, - это размер запроса. Например, если вы загружаете большой файл, лучше использовать асинхронное соединение. Ваш делегат будет получать блоки данных по мере их поступления. Для сравнения, синхронный метод будет ждать всех данных, прежде чем сделать их доступными для вас. Делегат может начать обработку ответа раньше (лучший пользовательский опыт) или сохранить его в файле вместо памяти (лучшее использование ресурсов). У вас также есть возможность остановить ответ, не дожидаясь всех данных.

По сути, асинхронный метод дает вам больший контроль над соединением, но за счет сложности. Синхронный метод намного проще, но его не следует использовать в основном потоке пользовательского интерфейса, потому что он блокирует.

Answer 4

В ответ на другие ответы, касающиеся размера файла: я думаю, что размер файла не имеет значения. Если сервер реагирует очень медленно и вы загружаете данные синхронно, ваш пользовательский интерфейс по-прежнему зависает, даже если вы загружаете небольшой объем данных, например 3 КБ.

Так что я бы выбрал асинхронный вариант в любой ситуации, потому что вы никогда не знаете, что вы получите в отношении размера файла, скорости отклика сервера или скорости сети.