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

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?

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.

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.

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.

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 *.

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

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.

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.

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.