Jakich głównych funkcji ASIHTTPRequest brakuje w AFNetworking?

Ponieważ praca nad ASIHTTPRequest została niedawno zatrzymana , wydaje się, że uwaga przenosi się na AFNetworking .

Jednak nie znalazłem jeszcze dobrego porównania funkcji obu bibliotek, więc nie wiem, co mogę stracić, jeśli / kiedy się przełączę.

Główne różnice, które zauważyłem do tej pory, to:

1. AFNetworking ma znacznie mniejszy rozmiar kodu (co jest dobre)
2. AFNetworking jest szybko ulepszany (więc może nie być jeszcze dojrzały, może nie ma jeszcze stabilnego API?)
3. Oba wydają się mieć buforowanie, chociaż widziałem wskazówki, że ponieważ AFNetworking używa NSURLConnection, nie buforuje obiektów powyżej 50K
4. ASIHTTPRequest ma bardzo dobrą obsługę ręcznych i automatycznych (PAC) proxy http; Nie mogę znaleźć żadnych informacji na temat poziomu wsparcia AFNetworking dla serwerów proxy
5. AFNetworking wymaga iOS 4+, podczas gdy ASIHTTPRequest działa z powrotem do iOS 2 (nie jest to dla mnie problem, ale dla niektórych jest to problem)
6. AFNetworking nie ma (jeszcze) wbudowanej trwałej pamięci podręcznej, ale istnieje stała pamięć podręczna, która ma oczekujące żądanie ściągnięcia: https://github.com/gowalla/AFNetworking/pull/25

Czy ktoś widział jakieś dobre porównania obu bibliotek lub jakiekolwiek udokumentowane doświadczenia związane z przejściem z jednej do drugiej?

Uwielbiałem ASIHTTPRequest i było mi smutno, że to zniknęło. Jednak twórca ASI miał rację, ASIHTTPRequest stał się tak duży i rozdęty, że nawet on nie mógł poświęcić czasu na dostosowanie go do najnowszych funkcji iOS i innych frameworków. Poszedłem dalej i teraz używam AFNetworking.

To powiedziawszy, muszę powiedzieć, że AFNetworking jest znacznie bardziej niestabilny niż ASIHTTP, a do rzeczy, do których go używam, wymaga dopracowania.

Często muszę wysyłać żądania HTTP do 100 źródeł HTTP, zanim wyświetlę wyniki na ekranie, i umieściłem AFHTTPNetworkOperation w kolejce operacji. Przed pobraniem wszystkich wyników chcę mieć możliwość anulowania wszystkich operacji w kolejce operacji, a następnie odrzucenia kontrolera widoku, który przechowuje wyniki.

To nie zawsze działa.

W przypadku AFNetworking pojawiają się awarie w losowych momentach, podczas gdy w przypadku ASIHTTPRequest te operacje działały bezbłędnie. Chciałbym móc powiedzieć, która konkretna część AFNetworking ulega awarii, ponieważ ciągle ulega awarii w różnych punktach (jednak w większości przypadków debugger wskazuje na NSRunLoop, który tworzy obiekt NSURLConnection). Dlatego AFNetworking musi dojrzeć, aby można było uznać go za tak kompletny, jak ASIHTTPRequest.

Ponadto ASIHTTPRequests obsługuje uwierzytelnianie klienta, którego obecnie brakuje AFNetworking. Jedynym sposobem na jego zaimplementowanie jest podklasa AFHTTPRequestOperation i przesłonięcie metod uwierzytelniania NSURLConnection. Jeśli jednak zaczniesz angażować się w NSURLConnection, zauważysz, że umieszczenie NSURLConnection wewnątrz opakowania NSOperation i pisanie bloków uzupełniania nie jest takie trudne, jak się wydaje, i zaczniesz myśleć, co powstrzymuje Cię przed zrzucaniem bibliotek zewnętrznych.

ASI stosuje zupełnie inne podejście, ponieważ wykorzystuje CFNetworking (platformy bazowe niższego poziomu oparte na C), aby umożliwić pobieranie i przesyłanie plików, całkowicie pomijając NSURLConnection i dotykając koncepcji, których większość z nas, programistów OS X i iOS, boi się. Z tego powodu możesz lepiej ładować i pobierać pliki, nawet pamięci podręczne stron internetowych.

Co wolę? Trudno powiedzieć. Jeśli AFNetworking dostatecznie dojrzeje, spodoba mi się bardziej niż ASI. Do tego czasu nie mogę się powstrzymać od podziwiania ASI i sposobu, w jaki stał się jednym z najczęściej używanych frameworków wszechczasów dla OS X i iOS.

EDYCJA: Myślę, że czas zaktualizować tę odpowiedź, ponieważ po tym poście sytuacja nieco się zmieniła.

Ten post został napisany jakiś czas temu, a AFNetworking jest już wystarczająco dojrzały. 1-2 miesiące temu AF opublikował małą aktualizację operacji POST, która była moją ostatnią skargą dotyczącą frameworka (mała usterka końca linii była powodem, że echonest upload nie powiódł się z AF, ale został zakończony dobrze z ASI). Uwierzytelnianie nie jest problemem w przypadku AFnetworking, ponieważ w przypadku złożonych metod uwierzytelniania można podklasować operację i wykonywać własne wywołania, a AFHTTPClient sprawia, że ​​podstawowe uwierzytelnianie to bułka z masłem. Podklasując AFHTTPClient, możesz w krótkim czasie uczynić konsumenta całej usługi.

Nie wspominając o absolutnie niezbędnych dodatkach do UIImage, które oferuje AFNetworking. Dzięki blokom i niestandardowym blokom uzupełniania oraz sprytnemu algorytmowi możesz dość łatwo tworzyć widoki tabeli z asynchronicznym pobieraniem obrazu i wypełnianiem komórek, podczas gdy w ASI trzeba było tworzyć kolejki operacji do ograniczania przepustowości i uważać, aby anulować i wznowić kolejkę operacji zgodnie z widoczność widoku tabeli i tym podobne. Czas opracowywania takich operacji skrócił się o połowę.

Uwielbiam też bloki sukcesu i porażki. ASI ma tylko blok uzupełniania (który w rzeczywistości jest blokiem uzupełniania operacji NSO). Trzeba było sprawdzić, czy po ukończeniu wystąpił błąd i odpowiednio postępować. W przypadku złożonych usług internetowych możesz zagubić się we wszystkich „jeśli” i „else”; W AFNetworking rzeczy są znacznie prostsze i bardziej intuicyjne.

ASI był świetny jak na swoje czasy, ale dzięki AF możesz całkowicie zmienić sposób obsługi usług internetowych w dobry sposób i łatwiej tworzyć skalowalne aplikacje. Naprawdę wierzę, że nie ma żadnego powodu, aby trzymać się ASI, chyba że chcesz kierować reklamy na iOS 3 i starsze.

Właśnie kończę projekt, w którym używam AFNetworking zamiast ASI. Korzystałem z ASI w poprzednich projektach; w przeszłości było to bardzo pomocne.

Oto, czego brakuje AFNetworking (na dzień dzisiejszy), o czym powinieneś wiedzieć:

• Nic

ASI odchodzi . Użyj AF teraz. Jest mały, działa i będzie nadal obsługiwany. Jest również zorganizowany bardziej logicznie, szczególnie dla klientów API. Zawiera wiele świetnych klas dla często używanych przypadków specjalnych, takich jak asynchroniczne ładowanie obrazów w widokach tabel.

AFNetworking nie obsługuje clientCertificateIdentity i clientCertificates do uwierzytelniania klienta TLS.

Możemy to zrobić za pomocą - (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challengemetody w podklasie AFURLConnectionOperation, ale nie jest to takie proste.

Używam ASI * od jakiegoś czasu i absolutnie uwielbiam podejście ASI do przesyłania plików i chociaż jestem podekscytowany, mogąc przejść do AFNetworking, obsługa przesyłania plików w AfNetworking nie jest tak łatwa w użyciu w porównaniu do ASI *.

Do tej pory nie mogłem wymyślić, jak ustawić limit czasu za pomocą AFNetworking podczas wykonywania synchronicznego żądania POST . AKTUALIZACJA: w końcu się zorientowałem: https://stackoverflow.com/a/8774125/601466
Teraz przechodzę na AFNetworking:]

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

Apple zastępuje limit czasu dla POST, ustawiając go na 240 sekund (w przypadku, gdy został ustawiony na krótszy niż 240 sekund) i nie możesz tego zmienić. Dzięki ASIHTTP wystarczy ustawić limit czasu i działa.

Przykład kodu z synchronicznym żądaniem 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;

Próbowałem ustawić tutaj limit czasu, ale nic nie działało. Ten problem uniemożliwia mi migrację do AFNetworking.

Zobacz także tutaj: Jak ustawić limit czasu w AFNetworking

AFNetwork nie ma możliwości przesyłania dużych plików. Zakłada, że ​​zawartość pliku jest w pamięci RAM. ASI był wystarczająco inteligentny, aby po prostu przesyłać strumieniowo zawartość plików z dysku.

W ASIHTTP bardzo mi się podobało, że mogłem dołączać słownik informacji o użytkowniku do poszczególnych zapytań. O ile widzę, nie ma dla tego bezpośredniego wsparcia w AFHTTPRequestOperation. Czy ktoś wymyślił już eleganckie obejście? Pomijając oczywiście trywialne podklasy.

AFNetworking działa z „blokami”, co jest dla mnie bardziej naturalne niż praca z delegatami, jak robi to ASIHTTPRequest.

Praca z blokami przypomina pracę z funkcją anonimową w javascript.