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.
ASIFallbackToCacheIfLoadFailsCachePolicyjest bardzo dobry. Myślę, że AFNetworking nie ma trwałej obsługi pamięci podręcznej. To jest dla mnie nie do przyjęcia.