Welche wichtigen ASIHTTPRequest-Funktionen fehlen AFNetworking?

Mit der Arbeit auf ASIHTTPRequest vor kurzem aufgehört zu haben , wie es scheint , die Aufmerksamkeit auf verlagert AFNetworking .

Ich habe jedoch noch keinen guten Vergleich der Funktionen der beiden Bibliotheken gefunden, sodass ich nicht weiß, was ich verlieren könnte, wenn ich umschalte.

Hauptunterschiede, die ich bisher entdeckt habe, sind:

1. AFNetworking hat eine viel kleinere Codegröße (was gut ist)
2. AFNetworking wird schnell verbessert (es ist also möglicherweise noch nicht ausgereift, hat möglicherweise noch keine stabile API?)
3. Beide scheinen Caching zu haben, obwohl ich Hinweise gesehen habe, dass AFNetworking, da es NSURLConnection verwendet , keine Objekte über 50.000 zwischenspeichert
4. ASIHTTPRequest bietet sehr gute Unterstützung für manuelle und automatische (PAC) http-Proxys. Ich kann keine Informationen darüber finden, welche Unterstützung AFNetworking für Proxys bietet
5. AFNetworking erfordert iOS 4+, während ASIHTTPRequest direkt auf iOS 2 zurückgeht (für mich kein wirkliches Problem, aber für einige Leute ein Problem).
6. AFNetworking verfügt (noch) nicht über einen integrierten persistenten Cache, aber es gibt einen persistenten Cache mit einer ausstehenden Pull-Anforderung: https://github.com/gowalla/AFNetworking/pull/25

Hat jemand gute Vergleiche der beiden Bibliotheken oder dokumentierte Erfahrungen beim Wechsel von einer zur anderen gesehen?

Ich habe ASIHTTPRequest geliebt und war traurig, dass es so weit war. Der Entwickler von ASI hatte jedoch Recht, ASIHTTPRequest ist so groß und aufgebläht geworden, dass selbst er keine Zeit darauf verwenden konnte, es mit den neuesten Funktionen von iOS und anderen Frameworks gleichzusetzen. Ich ging weiter und benutze jetzt AFNetworking.

Trotzdem muss ich sagen, dass AFNetworking viel instabiler ist als ASIHTTP, und für die Dinge, für die ich es verwende, muss es verfeinert werden.

Ich muss häufig HTTP-Anforderungen an 100 HTTP-Quellen senden, bevor ich meine Ergebnisse auf dem Bildschirm anzeigen kann, und ich habe AFHTTPNetworkOperation in eine Operationswarteschlange gestellt. Bevor alle Ergebnisse heruntergeladen werden, möchte ich in der Lage sein, alle Vorgänge in der Vorgangswarteschlange abzubrechen und dann den Ansichtscontroller zu schließen, der die Ergebnisse enthält.

Das funktioniert nicht immer.

Ich bekomme zu zufälligen Zeiten Abstürze mit AFNetworking, während mit ASIHTTPRequest diese Operationen einwandfrei funktionierten. Ich wünschte, ich könnte sagen, welcher bestimmte Teil von AFNetworking abstürzt, da es immer wieder an verschiedenen Punkten abstürzt (meistens zeigt der Debugger jedoch auf die NSRunLoop, die ein NSURLConnection-Objekt erstellt). AFNetworking muss also ausgereift sein, um so vollständig wie ASIHTTPRequest zu sein.

Außerdem unterstützt ASIHTTPRequests die Clientauthentifizierung, die AFNetworking derzeit fehlt. Die einzige Möglichkeit, dies zu implementieren, besteht darin, AFHTTPRequestOperation in eine Unterklasse zu unterteilen und die Authentifizierungsmethoden von NSURLConnection zu überschreiben. Wenn Sie sich jedoch mit NSURLConnection beschäftigen, werden Sie feststellen, dass das Einfügen von NSURLConnection in einen NSOperation-Wrapper und das Schreiben von Abschlussblöcken nicht so schwierig ist, wie es sich anhört, und Sie werden darüber nachdenken, was Sie davon abhält, Bibliotheken von Drittanbietern zu sichern.

ASI verwendet einen ganz anderen Ansatz, da es CFNetworking (auf C basierende Frameworks auf niedrigerer Ebene) verwendet, um das Herunterladen und Hochladen von Dateien zu ermöglichen, NSURLConnection vollständig zu überspringen und Konzepte zu berühren, vor denen die meisten von uns OS X- und iOS-Entwicklern zu viel Angst haben. Dadurch erhalten Sie ein besseres Hoch- und Herunterladen von Dateien, sogar Webseiten-Caches.

Welches bevorzuge ich? Es ist schwer zu sagen. Wenn AFNetworking genug reift, wird es mir besser gefallen als ASI. Bis dahin kann ich nicht anders, als ASI zu bewundern und die Art und Weise, wie es zu einem der am häufigsten verwendeten Frameworks aller Zeiten für OS X und iOS wurde.

EDIT: Ich denke, es ist Zeit, diese Antwort zu aktualisieren, da sich die Dinge nach diesem Beitrag etwas geändert haben.

Dieser Beitrag wurde vor einiger Zeit geschrieben und AFNetworking ist genug gereift. Vor 1-2 Monaten hat AF ein kleines Update für POST-Vorgänge veröffentlicht, das meine letzte Beschwerde über das Framework war (ein kleiner Fehler beim Beenden der Leitung war der Grund dafür, dass echoneste Uploads mit AF fehlgeschlagen sind, aber mit ASI einwandfrei abgeschlossen wurden). Die Authentifizierung ist bei AFnetworking kein Problem, da Sie bei komplexen Authentifizierungsmethoden den Vorgang in Unterklassen unterteilen und Ihre eigenen Anrufe tätigen können. AFHTTPClient macht die Basisauthentifizierung zum Kinderspiel. Durch die Unterklasse AFHTTPClient können Sie in kurzer Zeit einen gesamten Service-Consumer erstellen.

Ganz zu schweigen von den absolut notwendigen UIImage-Ergänzungen, die AFNetworking anbietet. Mit Blöcken und benutzerdefinierten Vervollständigungsblöcken und einem cleveren Algorithmus können Sie Tabellenansichten mit asynchronem Herunterladen von Bildern und Füllen von Zellen ganz einfach erstellen, während Sie in ASI Operationswarteschlangen für die Bandbreitendrosselung erstellen und darauf achten mussten, die Operationswarteschlange entsprechend abzubrechen und fortzusetzen Sichtbarkeit der Tabellenansicht und ähnliches. Die Entwicklungszeit solcher Operationen wurde halbiert.

Ich liebe auch die Erfolgs- und Misserfolgsblöcke. ASI hat nur einen Abschlussblock (der eigentlich der Abschlussblock von NSOperation ist). Sie mussten überprüfen, ob Sie nach Abschluss einen Fehler hatten, und entsprechend handeln. Bei komplexen Webdiensten können Sie sich in allen "Wenns" und "Anderen" verlieren. In AFNetworking sind die Dinge viel einfacher und intuitiver.

ASI war für seine Zeit großartig, aber mit AF können Sie die Art und Weise, wie Sie Webdienste vollständig handhaben, auf eine gute Weise ändern und skalierbare Anwendungen einfacher machen. Ich glaube wirklich, dass es keinen Grund mehr gibt, bei ASI zu bleiben, es sei denn, Sie möchten auf iOS 3 und darunter abzielen.

Ich beende gerade ein Projekt, in dem ich AFNetworking anstelle von ASI verwende. Haben ASI in früheren Projekten verwendet; Es war in der Vergangenheit eine große Hilfe.

Folgendes fehlt AFNetworking (ab heute), über das Sie Bescheid wissen sollten:

• Nichts

ASI geht weg . Verwenden Sie jetzt AF. Es ist klein, es funktioniert und es wird weiterhin unterstützt. Es ist auch logischer organisiert, insbesondere für API-Clients. Es gibt eine Reihe großartiger Klassen für häufig verwendete Sonderfälle wie das asynchrone Laden von Bildern in Tabellenansichten.

AFNetworking unterstützt clientCertificateIdentity und clientCertificates für die TLS-Clientauthentifizierung nicht.

Wir können das mit der - (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challengeMethode in einer Unterklasse von AFURLConnectionOperation tun, aber es ist nicht so einfach.

Ich verwende ASI * bereits seit einiger Zeit und ich liebe den Fileupload-Ansatz von ASI. Obwohl ich begeistert bin, zu AFNetworking zu wechseln, ist die Unterstützung für Fileupload in AfNetworking im Vergleich zu ASI * nicht so einfach zu verwenden.

Bisher konnte ich bei einer synchronen POST-Anforderung nicht herausfinden, wie mit AFNetworking ein Timeout festgelegt werden kann . UPDATE: Ich habe es endlich herausgefunden: https://stackoverflow.com/a/8774125/601466
Jetzt zu AFNetworking wechseln:]

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

Apple überschreibt das Zeitlimit für einen POST und setzt es auf 240 Sekunden (falls es kürzer als 240 Sekunden eingestellt wurde), und Sie können es nicht ändern. Mit ASIHTTP stellen Sie einfach ein Timeout ein und es funktioniert.

Ein Codebeispiel mit einer synchronen POST-Anforderung:

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;

Ich habe versucht, hier eine Zeitüberschreitung festzulegen, aber nichts hat funktioniert. Dieses Problem hindert mich daran, auf AFNetworking zu migrieren.

Siehe auch hier: So legen Sie eine Zeitüberschreitung mit AFNetworking fest

AFNetwork ist nicht in der Lage, große Dateien hochzuladen. Es wird davon ausgegangen, dass sich der Dateiinhalt im RAM befindet. ASI war intelligent genug, um einfach Dateiinhalte von der Festplatte zu streamen.

In ASIHTTP fand ich es toll, dass ich einzelnen Anfragen ein Benutzerinfo-Wörterbuch hinzufügen konnte. Soweit ich sehe, gibt es dafür keine direkte Unterstützung AFHTTPRequestOperation. Hat sich schon jemand eine elegante Problemumgehung ausgedacht? Abgesehen von der trivialen Unterklasse natürlich.

AFNetworking arbeitet mit "Blöcken", was für mich natürlicher ist als die Arbeit mit Delegierten wie ASIHTTPRequest.

Das Arbeiten mit Blöcken ist wie das Arbeiten mit der anonymen Funktion in Javascript.