¿Qué características principales de ASIHTTPRequest falta en AFNetworking?

93

Dado que el trabajo se ha detenido recientemente en ASIHTTPRequest , parece que la atención se está desplazando hacia AFNetworking .

Sin embargo, todavía no he encontrado una buena comparación de las características de las dos bibliotecas, así que no sé qué podría perder si / cuando cambio.

Las principales diferencias que he detectado 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 aún no esté maduro, ¿es posible que aún 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 muy buen soporte para proxies http manuales y automáticos (PAC); No puedo encontrar ninguna información sobre el nivel de soporte que AFNetworking tiene para los proxies
  5. AFNetworking requiere iOS 4+, mientras que ASIHTTPRequest funciona directamente en iOS 2 (no es realmente un problema para mí, pero es un problema para algunas personas)
  6. AFNetworking no tiene (todavía) un caché persistente incorporado, pero hay un caché persistente que tiene una solicitud de extracción pendiente: https://github.com/gowalla/AFNetworking/pull/25

¿Alguien ha visto buenas comparaciones de las dos bibliotecas o alguna experiencia documentada de cambio de una a otra?

iphone  ios  ipad  asihttprequest  afnetworking 
— JosephH
fuente
AFNetworking carece de documentación y ejemplos muy detallados, por lo que no puedo decir mucho al respecto. La razón principal por la que uso ASIHTTPRequest es que es compatible con iOS 3.0 y ASIFallbackToCacheIfLoadFailsCachePolicyes muy bueno. Y creo que AFNetworking no tiene soporte de caché persistente. Esto es un no-go para mí.
— iwat
Solo tenga en cuenta que usted es el primero en etiquetar la pregunta afnetworking.
— iwat
Hay un caché que está esperando a ser incluido en AFNetworking, agregué un enlace a mi pregunta.
— JosephH
1
@iwat AFNetworking es totalmente compatible NSURLCache. Si está buscando caché de disco, le sugiero encarecidamente la bifurcación SDURLCache de Peter Steinberger .
— mattt
2
¿Has probado mi marco de trabajo en red MKNetworkKit? blog.mugunthkumar.com/products/… Autenticación básica, Digest y NTLM, almacenamiento en caché automático, almacenamiento en caché de imágenes incorporado, soporte de carga de archivos súper fácil, excelente documentación son algunas de las ventajas.
— Mugunth

Respuestas:

59

Me encantó ASIHTTPRequest y me entristeció verlo desaparecer. Sin embargo, el desarrollador de ASI tenía razón, ASIHTTPRequest se ha vuelto tan grande e hinchado que incluso él no pudo dedicar tiempo a equipararlo con las funciones más nuevas 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 para las que lo uso, necesita refinamiento.

A menudo necesito realizar 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 que se descarguen 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 bloquea, ya que sigue fallando en diferentes puntos (sin embargo, la mayoría de estas veces el depurador apunta al NSRunLoop que crea un objeto NSURLConnection). Entonces, AFNetworking necesita madurar para ser considerado tan completo como lo fue ASIHTTPRequest.

Además, ASIHTTPRequests admite la autenticación del cliente, de la 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é le impide deshacerse de bibliotecas de terceros.

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

Cual 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 algún tiempo y AFNetworking ha madurado lo suficiente. Hace 1 o 2 meses, AF publicó una pequeña actualización para las operaciones POST que fue mi última queja sobre el marco (una pequeña falla al final de la línea fue la razón por la que fallaron las cargas echonest 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 pan comido. Al crear una subclasificación de AFHTTPClient, puede convertirse en un consumidor de servicios completo en poco tiempo.

Sin mencionar las adiciones de UIImage absolutamente necesarias que ofrece AFNetworking. Con bloques y bloques de finalización personalizados y algún algoritmo inteligente, puede crear vistas de tabla con descarga de imágenes asincrónicas y llenado de celdas con bastante facilidad, mientras que en ASI tenía que hacer colas de operaciones para la limitación del ancho de banda y tener cuidado de cancelar y reanudar la cola de operaciones de acuerdo con visibilidad de 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). Debía verificar si tuvo un error al finalizar y actuar en consecuencia. Para servicios web complejos, puede perderse en todos los "si" y "elses"; En AFNetworking, las cosas son mucho más simples e intuitivas.

ASI fue excelente para su época, pero con AF puede cambiar la forma en que maneja los servicios web completamente de una buena manera y hacer aplicaciones escalables más fácilmente. Realmente creo que ya no hay ninguna razón para seguir con ASI, a menos que desee apuntar a iOS 3 y versiones anteriores.

— csotiriou
fuente
1
+1 muy perspicaz. ¿Quizás vale la pena publicar sus bloqueos como una pregunta en stackoverflow? Me interesaría ver más detalles.
— JosephH
Gracias. Cuando tenga datos concretos sobre los accidentes, lo haré.
— csotiriou
3
¿El problema de la estabilidad sigue siendo un problema?
— Johan Karlsson
1
Según datos preliminares basados ​​en pruebas que realicé hace unos días, no. No es. Sin embargo, incluso con la última versión del marco, tengo un ejemplo que a veces se bloquea en el ciclo de ejecución de AFURLConnection cuando se estresa lo suficiente con una serie de acciones bajo ciertas condiciones (asignar / cancelar inmediatamente / desasignar / reasignar / iniciar). Sin embargo, debe tener algo que ver con los bloques de finalización NSOperation y NSRunLoop. He comprobado la implementación de AFNetworking y no pude encontrar una causa al respecto.
— csotiriou
ASI tiene un bloque de fallas.
— Kekoa
17

Acabo de terminar un proyecto en el que estoy usando AFNetworking en lugar de ASI. Ha utilizado ASI en proyectos anteriores; ha sido de gran ayuda en el pasado.

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

  • Nada

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

— Jeff
fuente
9
Como @iwat mencionó en los comentarios de la pregunta, AFNetworking carece de un almacenamiento en caché sólido. Eso es interesante y relevante para la pregunta, por lo que "nada" es la respuesta incorrecta. Aparte de eso, estoy completamente de acuerdo con tu opinión, aunque.
— Kenny Winker
1
@KennyWinker Por favor, vea mi respuesta en ese hilo de comentarios. Me complace decir que AFNetworking no se basa en un caché por diseño. Por el contrario, uno es libre de intercambiar su NSURLCachesolución basada en favoritos .
— mattt
1
en la parte Nada: ¿cómo puedo usar proxies en las solicitudes?
— Alex Volovoy
@AlexVolovoy, probablemente sea mejor hacer eso como una nueva pregunta
— JosephH
Yo no diría 'nada'. Por favor vea mi respuesta a continuación.
— Borisdiakur
4

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

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

— Mathieu Hausherr
fuente
5
Ahora puede hacer setAuthenticationChallengeBlock:on AFURLConnectionOperationy su subclase, y pasar la lógica para manejar cualquier desafío de autenticación que necesite, sin tener que subclase.
— mattt
2

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

— Teo Choong Ping
fuente
2

Hasta ahora no pude averiguar cómo establecer un tiempo de espera con AFNetworking al realizar una solicitud POST sincrónica . ACTUALIZACIÓN: finalmente me di cuenta: https://stackoverflow.com/a/8774125/601466
Ahora cambiando a AFNetworking:]

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

Apple anula el tiempo de espera para una POST, configurándolo en 240 segundos (en caso de que se estableciera 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 sincrónica:

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;

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

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

— borisdiakur
fuente
Su punto sobre los tiempos de espera es bueno, ¡gracias por compartirlo! Sin embargo, no entiendo cómo se relaciona esto con realizar solicitudes de forma sincrónica, ¿puede ampliarlo?
— JosephH
@JosephH Tienes razón. Por supuesto, a veces también necesita establecer un tiempo de espera al realizar solicitudes asincrónicas. He actualizado mi respuesta:]
— borisdiakur
Apple solucionó el problema con timeoutInterval que no podía ser inferior a 240 segundos, sin embargo, esto sigue siendo un problema, ya que incluso si configuras el timeoutInterval, la solicitud no lo respeta de alguna manera.
— Jasper
2

AFNetwork carece de la capacidad de cargar archivos grandes. Asume que el contenido del archivo está en RAM. ASI fue lo suficientemente inteligente como para simplemente transmitir contenido de archivos desde el disco.

— diciembre
fuente
0

En ASIHTTP, me encantó poder adjuntar un diccionario de información de usuario a solicitudes individuales. Por lo que veo, no hay apoyo directo para esto en AFHTTPRequestOperation. ¿Alguien ha encontrado una solución elegante ya? Aparte de la subclasificación trivial, por supuesto.

— Lvsti
fuente
2
No haga preguntas en las respuestas, sus posibilidades de obtener una respuesta son muy bajas. Use un comentario o una nueva pregunta en su lugar;)
— Michal
-8

AFNetworking trabaja 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.

— torhector2
fuente
Es cierto, pero en mi opinión no es el enfoque principal para desarrollar con
— ASIHTTPRequest
7
Eso es solo porque los bloques aparecieron después de que se escribió ASIHTTP, siempre uso bloques con ASI, nunca un delegado.
— hipercrypt
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.