iphone - ¿Qué características principales de ASIHTTPRequest es la falta de AFNetworking?

ios ipad

Question

Con el trabajo detenido recientemente en ASIHTTPRequest , parece que la atención se está desplazando a AFNetworking .

Sin embargo, aún no he encontrado una buena comparación de las características de las dos bibliotecas, por lo que no sé qué podría perder si / cuándo cambio.

Las principales diferencias que he visto hasta ahora son:

1. AFNetworking tiene un tamaño de código mucho más pequeño (lo cual es bueno)
2. AFNetworking se está mejorando rápidamente (por lo que es posible que todavía no esté maduro, es posible que todavía no tenga una API estable).
3. Ambos parecen tener almacenamiento en caché, aunque he visto indicios de que, debido a que AFNetworking usa NSURLConnection, no almacenará en caché los objetos de más de 50K.
4. ASIHTTPRequest tiene un muy buen soporte para proxies http manuales y automáticos (PAC); No encuentro ninguna información sobre el nivel de soporte que AFNetworking tiene para los proxies
5. AFNetworking requiere iOS 4+, mientras que ASIHTTPRequest funciona de nuevo con iOS 2 (no es realmente un problema para mí, pero es un problema para algunas personas)
6. AFNetworking todavía no tiene un caché persistente integrado, pero hay un caché persistente que tiene una solicitud de extracción pendiente: https://github.com/gowalla/AFNetworking/pull/25

¿Alguien ha visto alguna buena comparación de las dos bibliotecas o alguna experiencia documentada de cambio de una a la otra?

Answer 1

AFNetwork no tiene la capacidad de cargar archivos de gran tamaño. Asume que el contenido del archivo está en la RAM. ASI fue lo suficientemente inteligente como para simplemente transmitir contenido de archivos desde el disco.

Answer 2

AFNetworking funciona con "bloques", lo cual es más natural para mí que trabajar con delegados como lo hace ASIHTTPRequest.

Trabajar con bloques es como trabajar con la función anónima en JavaScript.

Answer 3

AFNetworking no admite clientCertificateIdentity y clientCertificates para la autenticación de cliente TLS.

Podemos hacer eso con la - (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge método de - (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge en una subclase de AFURLConnectionOperation pero no es tan fácil.

Answer 4

En ASIHTTP me encantó que pudiera adjuntar un diccionario de información de usuario a las solicitudes individuales. Por lo que veo, no hay soporte directo para esto en AFHTTPRequestOperation . ¿Alguien ha encontrado una solución elegante todavía? Además de la subclasificación trivial por supuesto.

Answer 5

Estoy terminando un proyecto en el que estoy usando AFNetworking en lugar de ASI. Han utilizado ASI en proyectos anteriores; ha sido de gran ayuda en el pasado.

Esto es lo que falta en AFNetworking (a partir de hoy) que debe conocer:

• Nada

ASI se va . Usa AF ahora. Es pequeño, funciona, y seguirá siendo compatible. También está organizado de manera más lógica, especialmente para clientes API. Tiene una serie de grandes clases para casos especiales muy utilizados, como la carga asincrónica de imágenes en vistas de tabla.

Answer 6

He estado usando ASI * desde hace un tiempo y me encanta el enfoque de carga de archivos de ASI, y aunque estoy emocionado de saltar a AFNetworking, la compatibilidad de carga de archivos en AfNetworking no es tan fácil de usar en comparación con ASI *.

Answer 7

Me encantó ASIHTTPRequest y me entristeció verlo ir. Sin embargo, el desarrollador de ASI tenía razón, ASIHTTPRequest se había vuelto tan grande e hinchado que incluso él no podía dedicar tiempo para ponerlo a la altura de las nuevas características de iOS y otros marcos. Seguí adelante y ahora uso AFNetworking.

Dicho esto, debo decir que AFNetworking es mucho más inestable que ASIHTTP, y para las cosas que lo uso, necesita un refinamiento.

A menudo necesito hacer solicitudes HTTP a 100 fuentes HTTP antes de mostrar mis resultados en la pantalla, y he puesto AFHTTPNetworkOperation en una cola de operaciones. Antes de descargar todos los resultados, quiero poder cancelar todas las operaciones dentro de la cola de operaciones y luego descartar el controlador de vista que contiene los resultados.

Eso no siempre funciona

Recibo bloqueos en momentos aleatorios con AFNetworking, mientras que con ASIHTTPRequest, estas operaciones funcionaban sin problemas. Me gustaría poder decir qué parte específica de AFNetworking se está bloqueando, ya que sigue fallando en diferentes puntos (sin embargo, la mayoría de estas veces el depurador apunta a NSRunLoop que crea un objeto NSURLConnection). Por lo tanto, AFNetworking necesita madurar para que se considere tan completo como lo fue ASIHTTPRequest.

Además, ASIHTTPRequests es compatible con la autenticación del cliente, que AFNetworking carece en este momento. La única forma de implementarlo es subclase AFHTTPRequestOperation y anular los métodos de autenticación de NSURLConnection. Sin embargo, si comienza a involucrarse con NSURLConnection, notará que poner NSURLConnection dentro de un contenedor NSOperation y escribir bloques de finalización no es tan difícil como parece y comenzará a pensar qué es lo que le impide descargar bibliotecas de terceros.

ASI usa un enfoque totalmente diferente, ya que usa CFNetworking (marcos de base de nivel inferior basados ​​en C) para posibilitar la descarga y carga de archivos, omitiendo NSURLConnection por completo y tocando conceptos que la mayoría de los desarrolladores de OS X e iOS tememos. Debido a esto, obtiene una mejor carga y descarga de archivos, incluso cachés de páginas web.

¿Cuál prefiero? Es difícil de decir. Si AFNetworking madura lo suficiente, me gustará más que ASI. Hasta entonces, no puedo evitar admirar ASI, y la forma en que se convirtió en uno de los marcos más utilizados de todos los tiempos para OS X e iOS.

EDITAR: Creo que es hora de actualizar esta respuesta, ya que las cosas han cambiado un poco después de esta publicación.

Esta publicación fue escrita hace un tiempo, y AFNetworking ha madurado lo suficiente. Hace 1-2 meses, AF publicó una pequeña actualización para las operaciones de POST que fue mi última queja sobre el marco (una falla de final de línea pequeña fue la razón por la que las cargas de echonest fallaron con AF pero se completaron bien con ASI). La autenticación no es un problema con AFnetworking, ya que para los métodos de autenticación complejos puede subclasificar la operación y hacer sus propias llamadas y AFHTTPClient hace que la autenticación básica sea fácil. Al crear subclases de AFHTTPClient, puede crear un consumidor de servicios completo en poco tiempo.

Sin mencionar las adiciones de UIImage absolutamente necesarias que AFNetworking ofrece. Con bloques y bloques de finalización personalizados y algún algoritmo inteligente, puede realizar vistas de tabla con descarga asíncrona de imágenes y llenado de celdas con bastante facilidad, mientras que en ASI tuvo que hacer colas de operación para el límite de ancho de banda y cancelar y reanudar la cola de operaciones de acuerdo con visibilidad de la vista de tabla, y cosas así. El tiempo de desarrollo de tales operaciones se ha reducido a la mitad.

También me encantan los bloques de éxito y fracaso. ASI solo tiene un bloque de finalización (que en realidad es el bloque de finalización de NSOperation). Debes verificar si tienes un error al finalizar y actuar en consecuencia. Para servicios web complejos, puede perderse en todos los "ifs" y "elses"; En AFNetworking, las cosas son mucho más simples e intuitivas.

ASI fue genial para su época, pero con AF puede cambiar completamente la forma en que maneja los servicios web de una buena manera y hacer que las aplicaciones escalables sean más fáciles. Realmente creo que no hay motivo alguno para seguir con ASI, a menos que desee apuntar a iOS 3 y versiones posteriores.

Answer 8

Hasta ahora no podía encontrar la manera de establecer un tiempo de espera con AFNetworking cuando hacía una solicitud POST síncrona . ACTUALIZACIÓN: finalmente descubrí: https://.com/a/8774125/601466
Ahora cambiando a AFNetworking:]

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

Apple anula el tiempo de espera para un POST, configurándolo en 240 segundos (en caso de que se haya configurado más corto que los 240 segundos), y no puede cambiarlo. Con ASIHTTP, simplemente establece un tiempo de espera y funciona.

Un ejemplo de código con una solicitud POST síncrona:

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;

Traté de establecer un tiempo de espera aquí, pero nada funcionó. Este problema me impide migrar a AFNetworking.

Vea también aquí: Cómo establecer un tiempo de espera con AFNetworking