¿Cuál es la ventaja de usar Alamofire sobre NSURLSession/NSURLConnection para redes?

mobile-application

Question

¿Puede alguien ayudarme a comprender estas preguntas: cuál es la ventaja de usar Alamofire sobre NSURLSession / NSURLConnection?

¿Cuáles son las diferencias entre NSURLSession y NSURLConnection?

Answer 1

Alamofire está construido sobre NSURLSession y tiene menos líneas de código para realizar interacciones REST con (POST / GET / PUT / etc). Le conseguirá el "90%" del camino, pero si necesita hacer llamadas de red súper especializadas, deberá usar NSURLSession.

Ej: Llamada Alamofire simple que obtiene JSON.

Alamofire.request(.GET, "https://www.google.com/",encoding: .JSON).responseJSON {response in
if(response.result.error == nil){
print(response.data)
}else{
print("Network Error")
}
}

NSURLConnection ahora está en desuso, y NSURLSession es el nuevo estándar. https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/URLLoadingSystem/Articles/UsingNSURLSession.html

Answer 2

La ventaja es que hay un nivel más alto de abstracción, por lo que puede escribir menos líneas de código. Sin embargo, todavía no hay apoyo oficial para Codable. La actualización de la versión Swift puede tener sus desventajas, pero creo que esto debería mejorar con la estabilidad ABI en Swift 5. Además, debe tener en cuenta las vulnerabilidades de seguridad.

De vuelta en los días de conexión de Objective C y NSUR, las bibliotecas como AFNetworking tenían mucho sentido, pero con Swift, Codable y URLSession, creo que hay menos razones para usar Alamofire.

Answer 3

NSURLConnection es la antigua API de Apple para hacer redes (por ejemplo, hacer solicitudes HTTP y recibir respuestas), mientras que NSURLSession es la nueva. El último es de nivel superior y, en general, es mucho más fácil e implica menos código de repetición para usar para la mayoría de los desarrolladores de aplicaciones; básicamente, no hay razón para usar el primero, excepto en el código heredado que no desea actualizar.

Un poco de historia: antes de la publicación de NSURLSession, una biblioteca de terceros, AFNetworking, se convirtió en el estándar de facto para hacer redes en Objective C, ya que proporcionaba una API más fácil y más conveniente que NSURLConnection (de la cual era una envoltura). estos días envuelve NSURLSession en su lugar). Más tarde, el mismo desarrollador creó una biblioteca similar para Swift, llamada AlamoFire, con el fin de aprovechar al máximo la "forma rápida de hacer las cosas" (en lugar de simplemente agregar enlaces Swift a AFNetworking). Casi al mismo tiempo salió NSURLSession y parecía bastante obvio que Apple se había inspirado en AFNetworking y quería hacer que su nueva API de red fuera tan conveniente para trabajar, en general creo que lo lograron. Lo que esto significa es que si bien anteriormente, usar AFNetworking en lugar de NSURLConnection era la única opción sensata para la mayoría de los desarrolladores, hoy en día las ventajas de usar AFNetworking o AlamoFire sobre NSURLSession son mucho más pequeñas, y para la mayoría de los desarrolladores que inician nuevos proyectos, les recomendaría Comience utilizando NSURLSession y solo busque en AlamoFire si sienten que se encuentran con alguna limitación o inconveniente que es lo suficientemente grande como para justificar agregar otra dependencia.

Answer 4

Para Swift 3.0 y superior, Alamofire es el mejor porque está bien optimizado y también es reutilizable y también tiene muchas funciones integradas. Alamofire se le exige un enfoque similar para crear un enrutador conforme a un protocolo, URLRequestConvertible. Bajo el capó, Alamofire requiere un patrón de singleton que se construya sobre una configuración de configuración de NSURLS.

Answer 5

Primero déjame contestar la diferencia entre NSURLSession y NSURLConnection

1. NSURLConnection: si tenemos una conexión abierta con NSURLConnection y supongamos que cierra su aplicación, entonces todo lo que recibimos o enviamos se pierde.

2. NSURLSession: aquí este caso se maneja con la ayuda de un método de delegado de aplicación

   application:handleEventsForBackgroundURLSession:completionHandler

Aquí hay un enlace que encontré que podría ser útil para explicar mejor la diferencia entre los dos

vamos a su pregunta inicial de ventaja de Alamofire sobre la clase de marco por defecto, y solo estoy compartiendo mi experiencia sobre lo que hice hasta ahora, así que prepárese ya que es una lectura larga.

Para mí, la regla del pulgar nunca es pasar por alto el marco a menos que tenga una razón sólida para hacerlo, independientemente de la tecnología que esté utilizando.

La razón es que he usado una biblioteca de terceros en el pasado y que no terminó bien con las últimas actualizaciones de iOS y digamos que si tiene una aplicación de pago y su biblioteca de terceros deja de funcionar, entonces la aplicación de su cliente perderá su valor y Terminará teniendo comentarios negativos en la tienda de aplicaciones.

Aconsejo antes de utilizar cualquier biblioteca de terceros, asegúrese de verificar las preguntas dadas.

1. ¿Cuál es la frecuencia de las actualizaciones?
2. ¿Cuántos errores abiertos están abiertos?
3. ¿Realmente vale la pena usarlo o puedes aprovechar las clases de marco?
4. ¿Cuál es la licencia de esta biblioteca?

Volviendo a la pregunta, utilicé Alamofire en un proyecto que solo estaba haciendo llamadas para poner, publicar y poner, tenía algunas funciones de sincronización sin conexión.

Ahora que lo pensaba, podría haber hecho mi propia clase con URLSessions y manejar la respuesta en consecuencia, no había necesidad de usar Alamofire ya que no estaba haciendo nada especial aquí.

Creo que todo esto se podía lograr con el marco predeterminado que con un tercero, pero lo usé de todos modos. ¿Por qué lo usé? No sé. Tal vez tuve curiosidad, pero una lección aprendida aquí fue que pude haber logrado lo mismo al usar clases marco. Si digamos que la biblioteca deja de funcionar, no tendría idea de por qué lo hizo y lo haría. tiene que depender de una solución de la persona encargada de la toma / autor de la biblioteca, que puede tardar un mes, una semana, un día, quién sabe

Una vez usé una biblioteca para una función que quería pero esa misma característica tenía un defecto abierto y nunca se actualizó, así que terminé haciendo mi propia versión personalizada y hasta hoy está funcionando bien, así que vaya a través de la sección de defectos abiertos para Evita sorpresas imprevistas.

Además, como se mencionó en la respuesta anterior, use solo componentes de terceros y solo cuando se encuentre con limitaciones con el marco predeterminado e incluso antes de hacerlo, verifique cuándo fue la última vez que se actualizó esta biblioteca, qué licencia tiene y cuántos defectos abiertos. hay.