Quelles sont les principales fonctionnalités ASIHTTPRequest d'AFNetworking manquantes?


93

Le travail ayant récemment cessé sur ASIHTTPRequest , il semble que l'attention se tourne vers AFNetworking .

Cependant, je n'ai pas encore trouvé une bonne comparaison des fonctionnalités des deux bibliothèques, donc je ne sais pas ce que je pourrais perdre si / quand je change.

Les principales différences que j'ai repérées jusqu'à présent sont:

  1. AFNetworking a une taille de code beaucoup plus petite (ce qui est bien)
  2. AFNetworking est en train d'être rapidement amélioré (il n'est donc peut-être pas encore mature, peut-être pas encore une API stable?)
  3. Les deux semblent avoir une mise en cache, même si j'ai vu des indices selon lesquels, étant donné qu'AFNetworking utilise NSURLConnection, il ne mettra pas en cache les objets de plus de 50K
  4. ASIHTTPRequest a un très bon support pour les proxies http manuels et automatiques (PAC); Je ne trouve aucune information sur le niveau d'assistance d'AFNetworking pour les proxys
  5. AFNetworking nécessite iOS 4+, alors que ASIHTTPRequest fonctionne directement vers iOS 2 (ce n'est pas vraiment un problème pour moi, mais c'est un problème pour certaines personnes)
  6. AFNetworking n'a pas (encore) de cache persistant intégré, mais il existe un cache persistant qui a une pull request en attente: https://github.com/gowalla/AFNetworking/pull/25

Quelqu'un a-t-il vu de bonnes comparaisons des deux bibliothèques ou des expériences documentées de passage de l'une à l'autre?


AFNetworking manque de documentation et d'exemples très détaillés, je ne peux donc pas en dire beaucoup. La principale raison pour laquelle j'utilise ASIHTTPRequest car il prend en charge iOS 3.0 et ASIFallbackToCacheIfLoadFailsCachePolicyest très bon. Et je pense qu'AFNetworking n'a pas de support de cache persistant. C'est interdit pour moi.
iwat le

Remarquez simplement que vous êtes le premier à ajouter des tags afnetworking.
iwat le

Il y a un cache qui attend d'être tiré dans AFNetworking, j'ai ajouté un lien à ma question.
JosephH

1
@iwat AFNetworking prend entièrement en charge NSURLCache. Si vous recherchez un cache disque, je suggérerais chaleureusement le fork SDURLCache de Peter Steinberger .
mattt

2
Avez-vous essayé mon framework de réseau MKNetworkKit? blog.mugunthkumar.com/products/… Authentification de base, Digest et NTLM, mise en cache automatique, mise en cache d'image intégrée, support de téléchargement de fichiers super facile, excellente documentation sont quelques-uns des avantages.
Mugunth

Réponses:


59

J'ai adoré ASIHTTPRequest et j'étais triste de le voir partir. Cependant, le développeur d'ASI avait raison, ASIHTTPRequest est devenu si volumineux et gonflé que même lui ne pouvait pas consacrer de temps à le mettre au niveau des dernières fonctionnalités d'iOS et d'autres frameworks. J'ai évolué et j'utilise maintenant AFNetworking.

Cela dit, je dois dire que AFNetworking est beaucoup plus instable que ASIHTTP, et pour les choses pour lesquelles je l'utilise, il a besoin d'être raffiné.

J'ai souvent besoin de faire des requêtes HTTP à 100 sources HTTP avant d'afficher mes résultats à l'écran, et j'ai placé AFHTTPNetworkOperation dans une file d'attente d'opérations. Avant que tous les résultats ne soient téléchargés, je souhaite pouvoir annuler toutes les opérations dans la file d'attente des opérations, puis ignorer le contrôleur de vue qui contient les résultats.

Cela ne fonctionne pas toujours.

Je reçois des plantages à des moments aléatoires avec AFNetworking, tandis qu'avec ASIHTTPRequest, ces opérations fonctionnaient parfaitement. J'aimerais pouvoir dire quelle partie spécifique d'AFNetworking plante, car elle continue de planter à différents points (cependant, la plupart de ces fois, le débogueur pointe vers le NSRunLoop qui crée un objet NSURLConnection). Ainsi, AFNetworking doit mûrir pour être considéré comme aussi complet que l'était ASIHTTPRequest.

En outre, ASIHTTPRequests prend en charge l'authentification client, ce qui manque à AFNetworking pour le moment. La seule façon de l'implémenter est de sous-classer AFHTTPRequestOperation et de remplacer les méthodes d'authentification de NSURLConnection. Cependant, si vous commencez à vous impliquer dans NSURLConnection, vous remarquerez que placer NSURLConnection dans un wrapper NSOperation et écrire des blocs de complétion n'est pas si difficile qu'il y paraît et vous commencerez à penser à ce qui vous empêche de vider des bibliothèques tierces.

ASI utilise une approche complètement différente, car il utilise CFNetworking (frameworks de base de niveau inférieur basés sur C) pour rendre possible le téléchargement et le téléchargement de fichiers, en ignorant complètement NSURLConnection et en touchant aux concepts que la plupart d'entre nous, les développeurs OS X et iOS ont trop peur. Pour cette raison, vous obtenez un meilleur téléchargement et téléchargement de fichiers, même les caches de pages Web.

Lequel est-ce que je préfère? C'est difficile à dire. Si AFNetworking mûrit suffisamment, je l'aimerai plus que ASI. Jusque-là, je ne peux m'empêcher d'admirer ASI et la façon dont il est devenu l'un des frameworks les plus utilisés de tous les temps pour OS X et iOS.

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

Ce message a été rédigé il y a quelque temps et AFNetworking a suffisamment mûri. Il y a 1 à 2 mois, AF a publié une petite mise à jour pour les opérations POST qui était ma dernière plainte concernant le framework (une petite erreur de fin de ligne était la raison pour laquelle les téléchargements d'écho ont échoué avec AF mais se sont bien déroulés avec ASI). L'authentification n'est pas un problème avec AFnetworking, car pour les méthodes d'authentification complexes, vous pouvez sous-classer l'opération et effectuer vos propres appels et AFHTTPClient fait de l'authentification de base un jeu d'enfant. En sous-classant AFHTTPClient, vous pouvez créer un consommateur de service complet en peu de temps.

Sans parler des ajouts UIImage absolument nécessaires qu'offre AFNetworking. Avec des blocs et des blocs de complétion personnalisés et un algorithme intelligent, vous pouvez créer des vues de table avec un téléchargement d'image asynchrone et un remplissage de cellule assez facilement, alors que dans ASI, vous deviez créer des files d'attente d'opérations pour la limitation de la bande passante et vous occuper d'annuler et de reprendre la file d'attente des opérations selon visibilité de la vue de la table, et des trucs comme ça. Le temps de développement de ces opérations a été divisé par deux.

J'aime aussi les blocs de réussite et d'échec. ASI n'a qu'un bloc d'achèvement (qui est en fait le bloc d'achèvement de NSOperation). Vous deviez vérifier si vous aviez une erreur à la fin et agir en conséquence. Pour les services Web complexes, vous pourriez vous perdre dans tous les «si» et «elses»; Dans AFNetworking, les choses sont beaucoup plus simples et intuitives.

ASI était génial pour l'époque, mais avec AF, vous pouvez changer complètement la façon dont vous gérez les services Web et rendre les applications évolutives plus facilement. Je crois vraiment qu'il n'y a aucune raison de rester avec ASI, à moins que vous ne souhaitiez cibler iOS 3 et inférieur.


1
+1 très perspicace. Cela vaut peut-être la peine de poster vos plantages sous forme de question sur stackoverflow? Je serais intéressé de voir plus de détails.
JosephH

Merci. Lorsque j'aurai des données concrètes sur les accidents, je le ferai.
csotiriou

3
Le problème de stabilité est-il toujours un problème?
Johan Karlsson

1
Sur des données préliminaires basées sur des tests que j'ai effectués il y a quelques jours, non. Ce n'est pas. Cependant, même avec la dernière version du framework, j'ai un exemple qui plante parfois sur la boucle d'exécution d'AFURLConnection lorsqu'il est suffisamment stressé avec une série d'actions sous certaines conditions (allouer / annuler immédiatement / désallouer / réallouer / démarrer). Cela doit cependant avoir quelque chose à voir avec les blocs d'achèvement NSOperation et NSRunLoop. J'ai vérifié la mise en œuvre d'AFNetworking et je n'ai pas trouvé de cause à ce sujet.
csotiriou

ASI a un bloc de défaillance.
Kekoa

17

Je termine juste un projet dans lequel j'utilise AFNetworking au lieu d'ASI. Avoir utilisé ASI sur des projets précédents; cela a été d'une grande aide dans le passé.

Voici ce qui manque à AFNetworking (à ce jour) que vous devriez savoir:

  • Rien

ASI s'en va . Utilisez AF maintenant. C'est petit, ça marche et ça va continuer d'être soutenu. Il est également organisé de manière plus logique, en particulier pour les clients API. Il a un certain nombre de classes intéressantes pour les cas spéciaux souvent utilisés comme le chargement asynchrone d'images dans les vues de table.


9
Comme @iwat l'a mentionné dans les commentaires sur la question, AFNetworking manque de mise en cache robuste. C'est intéressant et pertinent par rapport à la question, donc «rien» n'est la mauvaise réponse. Autre que cela, je suis entièrement d'accord avec votre sentiment, tho.
Kenny Winker

1
@KennyWinker Veuillez voir ma réponse dans ce fil de commentaires. Je suis heureux de dire qu'AFNetworking ne crée pas de cache par conception. Au contraire, on est libre d'échanger dans sa NSURLCachesolution préférée .
mattt

1
sur la partie Rien - comment puis-je utiliser des proxies dans les demandes?
Alex Volovoy

@AlexVolovoy, il est probablement préférable de poser cela comme une nouvelle question
JosephH

Je ne dirais pas «rien». Veuillez voir ma réponse ci-dessous.
borisdiakur

4

AFNetworking ne prend pas en charge clientCertificateIdentity et clientCertificates pour l'authentification client TLS.

Nous pouvons le faire avec la - (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challengeméthode dans une sous-classe de AFURLConnectionOperation mais ce n'est pas aussi simple.


5
Vous pouvez maintenant faire setAuthenticationChallengeBlock:sur AFURLConnectionOperationet sa sous-classe, et transmettre la logique pour gérer les défis d'authentification selon vos besoins, sans avoir à sous-classe.
mattt

2

J'utilise ASI * depuis un certain temps maintenant et j'adore l'approche fileupload d'ASI, et bien que je sois ravi de passer à AFNetworking, le support fileupload dans AfNetworking n'est pas aussi facile à utiliser que ASI *.


2

Jusqu'à présent, je ne savais pas comment définir un délai d' expiration avec AFNetworking lors d'une requête POST synchrone . MISE À JOUR: J'ai enfin compris: https://stackoverflow.com/a/8774125/601466
passe maintenant à AFNetworking:]

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

Apple remplace le délai d'expiration d'un POST, le définissant sur 240 secondes (au cas où il aurait été défini plus court que les 240 secondes), et vous ne pouvez pas le modifier. Avec ASIHTTP, vous définissez simplement un délai d'attente et cela fonctionne.

Un exemple de code avec une requête POST synchrone:

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 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 avec AFNetworking


Votre point sur les délais d'attente est bon, merci pour le partage! Je ne comprends pas en quoi cela se rapporte à l'envoi de demandes de manière syncronale, pouvez-vous nous en dire plus?
JosephH

@JosephH Vous avez raison. Bien sûr, parfois, vous devez également définir un délai d'expiration lorsque vous effectuez des requêtes asynchrones. J'ai mis à jour ma réponse:]
borisdiakur

Apple a résolu le problème avec timeoutInterval ne pouvant pas être inférieur à 240 secondes, mais cela reste un problème car même si vous définissez timeoutInterval, la demande ne le respecte pas d'une manière ou d'une autre.
Jasper

2

AFNetwork n'a pas la capacité de télécharger des fichiers volumineux. Il suppose que le contenu du fichier est dans la RAM. ASI était assez intelligent pour simplement diffuser le contenu du fichier à partir du disque.


0

Dans ASIHTTP, j'ai adoré pouvoir joindre un dictionnaire userinfo aux demandes individuelles. Pour autant que je vois, il n'y a pas de soutien direct pour cela AFHTTPRequestOperation. Quelqu'un a-t-il encore proposé une solution de contournement élégante? Mis à part le sous-classement trivial bien sûr.


2
Ne posez pas de questions dans les réponses, vos chances d'obtenir une réponse sont très très faibles. Utilisez plutôt un commentaire ou une nouvelle question;)
Michal

-8

AFNetworking fonctionne avec des «blocs», ce qui est plus naturel pour moi que de travailler avec des délégués comme le fait ASIHTTPRequest.

Travailler avec des blocs, c'est comme travailler avec une fonction anonyme en javascript.


C'est vrai, mais à mon avis, ce n'est pas la principale approche à développer avec ASIHTTPRequest
torhector2

7
C'est uniquement parce que les blocs sont arrivés après l'écriture d'ASIHTTP, j'utilise toujours des blocs avec ASI, jamais un délégué.
hypercrypter
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.