Мне понравился ASIHTTPRequest, и мне было грустно его видеть. Однако разработчик ASI был прав: ASIHTTPRequest стал настолько большим и раздутым, что даже он не смог уделить время, чтобы привести его в соответствие с новейшими функциями iOS и других фреймворков. Я пошел дальше и теперь использую AFNetworking.
Тем не менее, я должен сказать, что AFNetworking гораздо более нестабилен, чем ASIHTTP, и что касается вещей, для которых я его использую, он требует доработки.
Мне часто нужно сделать HTTP-запросы к 100 HTTP-источникам, прежде чем я покажу свои результаты на экране, и я поместил AFHTTPNetworkOperation в очередь операций. Перед загрузкой всех результатов я хочу иметь возможность отменить все операции внутри очереди операций, а затем закрыть контроллер представления, содержащий результаты.
Это не всегда работает.
У меня случались сбои в случайное время с AFNetworking, а с ASIHTTPRequest эти операции работали безупречно. Я хотел бы сказать, какая конкретная часть AFNetworking выходит из строя, поскольку она продолжает давать сбой в разных точках (однако в большинстве случаев отладчик указывает на NSRunLoop, который создает объект NSURLConnection). Итак, AFNetworking необходимо развить, чтобы считаться таким же полным, как ASIHTTPRequest.
Кроме того, ASIHTTPRequests поддерживает аутентификацию клиента, которой AFNetworking на данный момент не хватает. Единственный способ реализовать это - создать подкласс AFHTTPRequestOperation и переопределить методы аутентификации NSURLConnection. Однако, если вы начнете заниматься NSURLConnection, вы заметите, что размещение NSURLConnection внутри оболочки NSOperation и запись блоков завершения не так сложно, как кажется, и вы начнете думать, что мешает вам сбрасывать сторонние библиотеки.
ASI использует совершенно другой подход, поскольку он использует CFNetworking (базовые структуры нижнего уровня на основе C), чтобы сделать возможной загрузку и выгрузку файлов, полностью пропуская NSURLConnection и затрагивая концепции, которых большинство из нас, разработчиков OS X и iOS, слишком боятся. Благодаря этому вы улучшаете загрузку и скачивание файлов, даже кешей веб-страниц.
Что я предпочитаю? Сложно сказать. Если AFNetworking достаточно созреет, мне он понравится больше, чем ASI. А пока я не могу не восхищаться ASI и тем, как он стал одним из наиболее часто используемых фреймворков для OS X и iOS.
РЕДАКТИРОВАТЬ:
Я думаю, что пришло время обновить этот ответ, так как после этого сообщения все немного изменилось.
Этот пост был написан некоторое время назад, и AFNetworking достаточно повзрослела. 1-2 месяца назад AF опубликовал небольшое обновление для операций POST, которое было моей последней жалобой на фреймворк (небольшая ошибка окончания строки была причиной того, что загрузка echonest завершилась неудачно с AF, но была завершена с ASI). Аутентификация не является проблемой для AFnetworking, поскольку для сложных методов аутентификации вы можете подклассифицировать операцию и выполнять свои собственные вызовы, а AFHTTPClient упрощает базовую аутентификацию. Создав подкласс AFHTTPClient, вы можете за короткое время создать целого потребителя сервиса.
Не говоря уже об абсолютно необходимых дополнениях UIImage, которые предлагает AFNetworking. С помощью блоков и настраиваемых блоков завершения и некоторого умного алгоритма вы можете довольно легко создавать представления таблиц с асинхронной загрузкой изображений и заполнением ячеек, тогда как в ASI вам нужно было создавать очереди операций для регулирования полосы пропускания и заботиться о себе, чтобы отменить и возобновить очередь операций в соответствии с видимость табличного представления и тому подобное. Сроки разработки таких операций сократились вдвое.
Я также люблю блоки успеха и неудачи. ASI имеет только блок завершения (который фактически является блоком завершения NSOperation). Вы должны были проверить, была ли ошибка при завершении, и действовать соответствующим образом. Для сложных веб-сервисов вы можете потеряться во всех «если» и «еще»; В AFNetworking все намного проще и интуитивно понятнее.
ASI был великолепен для своего времени, но с AF вы можете полностью изменить способ обработки веб-сервисов и упростить масштабируемые приложения. Я действительно считаю, что нет никаких причин больше придерживаться ASI, если только вы не хотите ориентироваться на iOS 3 и ниже.
ASIFallbackToCacheIfLoadFailsCachePolicyочень хорош. И я думаю, что AFNetworking не поддерживает постоянный кеш. Мне это не подходит.