Quelles sont les principales caractéristiques ASIHTTPRequest AFNetworking est manquant ?

Question

Avec le travail ayant récemment arrêté sur ASIHTTPRequest, il semble que l'attention se déplace vers AFNetworking.

Cependant, je n'ai pas encore trouvé une bonne comparaison des caractéristiques des deux bibliothèques, donc je ne sais pas ce que je risque de perdre si/quand j'ai passer dessus.

Principales différences que j'ai vu jusqu'à présent sont:

1. AFNetworking a une beaucoup plus petite de la taille du code (qui est bonne)
2. AFNetworking est rapidement améliorée (de sorte qu'il peut ne pas être de maturité, peuvent ne pas avoir une API stable encore?)
3. Les deux semblent avoir la mise en cache, si j'ai vu des allusions à cause AFNetworking utilise NSURLConnection il ne met pas en cache des objets de plus de 50K
4. ASIHTTPRequest a un très bon support pour le manuel et automatique (PAC) http procurations; je ne trouve aucune information sur ce niveau de soutien AFNetworking a pour les proxys
5. AFNetworking nécessite iOS 4+, alors que le ASIHTTPRequest œuvres de retour à iOS 2 (pas vraiment un problème pour moi, mais c'est un problème pour certaines personnes)
6. AFNetworking n'a pas (encore) intégré dans le cache persistant, mais il y a un cache persistant qui a une attente de la demande d'extraction: https://github.com/gowalla/AFNetworking/pull/25

Quelqu'un a vu de bonnes comparaisons des deux bibliothèques ou de la documentation sur les expériences de passer de l'une à l'autre?

Answer 1

J'ai adoré ASIHTTPRequest et j'ai été triste de le voir aller. Cependant, le développeur de l'ASI a droite, ASIHTTPRequest est devenu si grand et gonflé que même lui ne pouvait pas consacrer du temps pour la mettre à niveau avec de nouvelles fonctionnalités d'iOS et d'autres cadres. J'ai déménagé et maintenant utiliser AFNetworking.

Cela dit, je dois dire que AFNetworking est beaucoup plus instable que ASIHTTP, et pour les choses que j'ai faites, il a besoin de raffinement.

J'ai souvent besoin de faire des requêtes HTTP à 100 HTTP sources avant de m'afficher mes résultats sur l'écran, et j'ai mis AFHTTPNetworkOperation dans une opération de la file d'attente. Avant que tous les résultats sont téléchargés, je veux être en mesure d'annuler toutes les opérations à l'intérieur de la file d'attente des opérations, puis de rejeter le point de vue du contrôleur qui détient les résultats.

Cela ne fonctionne pas toujours.

Je reçois se bloque de façon aléatoire avec AFNetworking, tandis qu'avec ASIHTTPRequest, ces opérations ont été parfaitement bien fonctionné. Je souhaite que je pourrais dire de la AFNetworking est en panne, qu'il continue à s'écraser à différents points (cependant, la plupart de ces périodes, le débogueur points à la NSRunLoop qui crée un NSURLConnection objet). Donc, AFNetworking besoin de mûrir pour être considérée comme complète que ASIHTTPRequest a été.

Aussi, ASIHTTPRequests prend en charge l'authentification du client, qui AFNetworking manque en ce moment. La seule façon de mettre en œuvre, il est à la sous-classe AFHTTPRequestOperation et de remplacer NSURLConnection de méthodes d'authentification. Toutefois, si vous commencez à être impliqué avec NSURLConnection, vous remarquerez que la mise NSURLConnection à l'intérieur d'un NSOperation wrapper et écrit de l'achèvement des blocs n'est pas si dur que ça, et vous commencez à penser à ce qui vous empêche de dumping 3ème partie les bibliothèques.

ASI utilise une approche complètement différente, car il utilise CFNetworking (niveau inférieur de la fondation des cadres fondés sur C) pour rendre le téléchargement de fichier et de téléchargement possible, en sautant NSURLConnection complètement, et de toucher les concepts de la plupart d'entre nous OS X et iOS, les développeurs ont trop peur. En raison de cela, vous obtenez un meilleur transfert de fichier et de téléchargement, même page web caches.

Qui dois-je préférer? C'est difficile à dire. Si AFNetworking mûrit assez, je l'aime plus que ASI. Jusqu'alors, je ne peux m'empêcher d'admirer l'ASI, et la façon dont il est devenu l'un des plus utilisés de cadres de tous les temps pour OS X et iOS.

EDIT: *Je pense qu'il est temps de mettre à jour cette réponse, que les choses ont un peu changé après ce post.*

Ce post a été écrit dôme de temps, et AFNetworking a suffisamment mûri. 1-2 mois AF posté une petite mise à jour pour les opérations POST c'était ma dernière plainte sur le cadre (une petite de fin de ligne de faille est la raison pour laquelle echonest uplaods a échoué avec l'AF, mais ont été achevés fine avec ASI). L'authentification n'est pas un problème avec AFnetworking, comme pour les complexes, les méthodes d'authentification, vous pouvez sous-classe de l'opération et de faire vos propres appels et AFHTTPClient rend l'authentification de base d'un morceau de gâteau. Par sous-classement AFHTTPClient vous pouvez effectuer l'ensemble d'un consommateur de services, dans peu de temps.

Pour ne pas mentionner absolument nécessaire UIImage ajouts que AFNetworking offre. Avec des blocs et personnalisé achèvement des blocs et un certain algorithme intelligent, vous pouvez faire des vues de table avec asynchrone image du téléchargement et de la cellule de remplissage assez facilement, alors que dans l'ASI vous avez eu à faire l'opération des files d'attente pour la limitation de bande passante et de l'esprit-vous à annuler et reprendre le fonctionnement de la file d'attente en fonction de la vue de la table de la visibilité, et des trucs comme ça. Le temps de développement de ces opérations a été réduit de moitié.

J'aime aussi le succès et l'échec des blocs. ASI a seulement un achèvement bloc (qui est en fait la fin du bloc de NSOperation). Vous avez eu à vérifier si vous avez eu une erreur sur l'achèvement et d'agir en conséquence. Pour des complexes de services web, vous pourriez vous perdre dans tous les "si" et de "elses"; Dans AFNetworking, les choses sont beaucoup plus simple et intuitif.

ASI était grand pour son époque, mais avec AF vous pouvez modifier la vous gérer les services web complètement dans le bon sens, et de faire évolutive des applications plus facilement. Je crois vraiment qu'il n'y a pas de raison que ce soit, pour coller avec l'ASI plus, à moins que vous souhaitez cibler iOS 3 et ci-dessous.

Answer 2

Juste de finir un projet pour lequel je suis en utilisant AFNetworking au lieu de l'ASI. Ont utilisé des ASI de projets antérieurs; il a été d'une grande aide dans le passé.

Voici ce que AFNetworking est manquante (comme aujourd'hui) que vous devriez connaître:

• Rien

ASI s'en va. Utilisez AF maintenant. Il est petit, il fonctionne, et il va continuer à être pris en charge. Il est également organisée, en particulier pour les clients API. Il a un certain nombre de grandes classes pour souvent utilisé à des cas particuliers comme le chargement asynchrone des images dans les vues de table.

Answer 3

AFNetworking ne supporte pas clientCertificateIdentity et clientCertificates pour l’authentification du client TLS.

Nous pouvons le faire avec la `` méthode dans une sous-classe de AFURLConnectionOperation, mais il n’est pas aussi facile.

Answer 4

Je me sers ASI pendant un certain temps maintenant et j’adore l’approche fileupload de l’ASI, et même si je suis très heureux d’aller à AFNetworking, soutien de fileupload dans AfNetworking n’est pas aussi facile à utiliser par rapport à ASI .

Answer 5

Jusqu'à présent, je ne pouvais pas comprendre comment définir un délai d'expiration avec AFNetworking lors d'une synchrone de la requête POST. Mise à JOUR: j'ai enfin compris: http://stackoverflow.com/a/8774125/601466
Maintenant commutation de AFNetworking : ]

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

Apple remplace le délai d'attente pour un POSTE, pour l'établir à 240 secondes (dans le cas où il a été mis plus court que la 240 secondes), et vous ne pouvez pas la modifier. Avec ASIHTTP que vous venez de définir un délai d'attente et il fonctionne.

Un exemple de code avec un synchrones requête 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;

J'ai essayé de définir un délai d'attente ici, mais rien n'a fonctionné. Ce problème m'empêche de migrer vers AFNetworking.

Voir aussi ici: Comment définir un délai d'attente avec AFNetworking