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.
ASIFallbackToCacheIfLoadFailsCachePolicy
est très bon. Et je pense qu'AFNetworking n'a pas de support de cache persistant. C'est interdit pour moi.