Які основні функції ASIHTTPRequest відсутні у AFNetworking?

Оскільки нещодавно зупинилася робота над ASIHTTPRequest , схоже, увага переходить на AFNetworking .

Однак я ще не знайшов хорошого порівняння особливостей двох бібліотек, тому не знаю, що можу втратити, якщо / коли перемкнусь на нього.

Основні відмінності, які я помічав до цього часу:

1. AFNetworking має значно менший розмір коду (що добре)
2. AFNetworking швидко вдосконалюється (тож він ще не може бути зрілим, можливо, ще не має стабільного API?)
3. Здається, що в обох є кешування, хоча я бачив підказки, що оскільки AFNetworking використовує NSURLConnection, він не кешуватиме об'єкти старше 50K
4. ASIHTTPRequest має дуже гарну підтримку ручних та автоматичних (PAC) http-проксі; Я не можу знайти будь-яку інформацію про рівень підтримки AFNetworking для проксі
5. Для AFNetworking потрібен iOS 4+, тоді як ASIHTTPRequest працює прямо на iOS 2 (насправді це не проблема для мене, але для деяких людей це проблема)
6. AFNetworking ще не має вбудованого стійкого кешу, але є стійкий кеш, який має запит на витягнення: https://github.com/gowalla/AFNetworking/pull/25

Хтось бачив якісь хороші порівняння двох бібліотек або будь-який задокументований досвід переходу від однієї до іншої?

Мені подобалось 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.

EDIT: Я думаю, що настав час оновити цю відповідь, оскільки все змінилося трохи після цієї публікації.

Це повідомлення було написане деякий час тому, і AFNetworking досить дозрів. 1-2 місяці тому AF опублікував невелике оновлення для операцій POST, що було моєю останньою скаргою на фреймворк (невелика помилка, що закінчується, стала причиною того, що завантаження не вдалося отримати з AF, але завершено штрафом з ASI). Автентифікація не є проблемою для AFnetworking, оскільки для складних методів аутентифікації ви можете підкласифікувати операцію та здійснити власні дзвінки, а AFHTTPClient робить основну автентифікацію шматочком торта. Підкласифікуючи AFHTTPClient, ви можете за короткий час зробити повного споживача послуги.

Не кажучи вже про абсолютно необхідні доповнення UIImage, які пропонує AFNetworking. За допомогою блоків та спеціальних блоків завершення та деякого розумного алгоритму ви можете легко переглядати таблиці з асинхронним завантаженням зображень та заповненням комірок, тоді як в ASI вам довелося робити черги операцій для зменшення пропускної здатності та пам’ятати про те, щоб скасувати та відновити чергу операцій відповідно до видимість подання таблиці та подібні речі. Час розробки таких операцій скоротився вдвічі.

Я також люблю блоки успіху та невдачі. ASI має лише блок завершення (який фактично є блоком завершення NSOperation). Вам довелося перевірити, чи не відбулася помилка при завершенні, і діяти відповідно. Для складних веб-сервісів ви можете загубитися у всіх "ifs" та "elses"; У AFNetworking справи набагато простіші та інтуїтивніші.

ASI був чудовим для свого часу, але за допомогою AF ви можете повністю змінити спосіб керування веб-сервісами повністю та легше робити масштабовані програми. Я дійсно вважаю, що більше немає причин залишатися з ASI, якщо ви не хочете націлювати на iOS 3 і нижче.

Щойно закінчую проект, де я використовую AFNetworking замість ASI. Використовували ASI у попередніх проектах; це було чудовою допомогою в минулому.

Ось що відсутнє в AFNetworking (станом на сьогодні), про яке слід знати:

• Нічого

ASI йде геть . Використовуйте AF зараз. Він невеликий, він працює, і він буде надалі підтримуватися. Він також організований більш логічно, особливо для клієнтів API. Він має ряд чудових класів для часто використовуваних спеціальних випадків, таких як асинхронне завантаження зображень у поданнях таблиць.

AFNetworking не підтримує clientCertificateIdentity та clientCertificate для аутентифікації клієнта TLS.

Це можна зробити за допомогою - (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challengeметоду в підкласі AFURLConnectionOperation, але це не так просто.

Я вже деякий час використовую ASI *, і я дуже люблю підхід до завантаження файлів ASI, і хоча я з радістю перейшов до AFNetworking, підтримка завантаження файлів у AfNetworking не так проста у використанні порівняно з ASI *.

До сих пір я не міг зрозуміти, як встановити тайм-аут за допомогою AFNetworking при виконанні синхронного POST-запиту . ОНОВЛЕННЯ: я нарешті з’ясував: https://stackoverflow.com/a/8774125/601466
Зараз перехід на AFNetworking:]

===================

Apple перевищує тайм-аут для POST, встановлюючи його на 240 секунд (якщо він встановлений коротше, ніж 240 секунд), і ви не можете його змінити. За допомогою ASIHTTP ви просто встановите тайм-аут, і він працює.

Приклад коду із синхронним запитом POST:

NSDictionary *params = [NSDictionary dictionaryWithObjectsAndKeys:
                                @"doSomething", @"task",
                                @"foo", @"bar",
                                nil];

AFHTTPClient *httpClient = [[AFHTTPClient alloc] initWithBaseURL:[NSURL URLWithString:baseURL]];

NSMutableURLRequest *request = [httpClient requestWithMethod:@"POST" path:requestURL parameters:params];
[httpClient release];

AFHTTPRequestOperation *operation = [[[AFHTTPRequestOperation alloc] initWithRequest:request] autorelease];
[operation setCompletionBlockWithSuccess:^(AFHTTPRequestOperation *operation, id responseObject) {}
failure:^(AFHTTPRequestOperation *operation, NSError *error) {
    NDLog(@"fail! %@", [error localizedDescription]);
}];

NSOperationQueue *queue = [[[NSOperationQueue alloc] init] autorelease];
[[AFNetworkActivityIndicatorManager sharedManager] incrementActivityCount];

[queue addOperation:operation];
[queue waitUntilAllOperationsAreFinished]; // Stuck here for at least 240 seconds!

[[AFNetworkActivityIndicatorManager sharedManager] decrementActivityCount];
if (![[operation responseString] isEqualToString:@""]) {
    return [operation responseString];
}

return nil;

Я намагався тут встановити тайм-аут, але нічого не вийшло. Ця проблема не дозволяє мені перейти на AFNetworking.

Дивіться також тут: Як встановити тайм-аут за допомогою AFNetworking

AFNetwork не має можливості завантажувати великі файли. Він передбачає, що вміст файлу знаходиться в оперативній пам'яті. ASI був досить розумним, щоб просто передавати вміст файлів з диска.

У ASIHTTP мені сподобалось, що я можу приєднати словник довідника користувача до індивідуальних запитів. Наскільки я бачу, в цьому немає прямої підтримки AFHTTPRequestOperation. Хтось ще придумав елегантне рішення? Крім тривіального підкласу звичайно.

AFNetworking працює з "блоками", що для мене більш природно, ніж робота з делегатами, як це робить ASIHTTPRequest.

Робота з блоками - це як робота з функцією Anonymous Function в JavaScript.