запустить это приложение, а потом взглянуть в окно консоли, то там окажется выведен следующий результат:
We are here…
Firing synchronous url connection…
2 52117 bytes of data was returned.
We are done.
Итак, вполне очевидно, что актуальный поток написал на консоли строку We are here…, дождался окончания соединения (поскольку это синхронное соединение, блокирующее актуальный поток), а потом вывел в окне консоли текст We are done. Теперь проведем эксперимент. Поместим то же самое синхронное соединение в глобальной параллельной очереди в GCD, то есть гарантированно обеспечим параллелизм, и посмотрим, что произойдет:
Итак, в данном примере текущий поток вывел текст We are done в окне консоли, не дожидаясь, пока синхронное соединение завершит считывание с заданного URL. Интересно, правда? Таким образом, этот пример доказывает, что при умелом обращении синхронное URL-соединение не обязательно блокирует главный поток. Тем не менее оно гарантированно блокирует текущий поток.
11.4. Изменение URL-запроса с применением NSMutableURLRequest
Постановка задачи
Требуется корректировать различные HTTP-заголовки и настройки URL-запроса перед передачей его URL-соединению.
Решение
Эта техника лежит в основе некоторых разделов, рассмотренных далее в этой главе. Пользуйтесь NSMutableURLRequest вместо NSURLRequest.
Обсуждение
URL-запрос может быть изменяемым или неизменяемым. URL-запросы, относящиеся к первой категории, поддаются изменениям после выделения и инициализации, а те, что относятся ко второй категории, — нет. Этот раздел посвящен изменяемым URL-запросам. Их можно создавать с помощью класса NSMutableURLRequest.