¿Por qué utilizar GCD y bloques para descargas HTTP?

En una entrevista de trabajo, me preguntaron por qué debería usar bloques y GCD en lugar de NSURLConnection para poder download files de forma asíncrona. Después de algunas investigaciones, no encontré una buena razón para hacerlo. Tengo varias aplicaciones donde uso solo NSURLConnection para varias descargas simultáneas. ¿Su pregunta está tratando de determinar si estoy conforme con lo que está de moda (GCD, bloques) o si hay alguna ventaja real y sustancial para hacer búsquedas asíncricas de esta manera? Gracias.

En iOS 7, generalmente no debe utilizar methods basados ​​en bloques para download files de forma asíncrona. Para admitir transferencias en segundo plano, debe utilizar NSURLSession con methods de delegado y no puede usar los methods basados ​​en bloques. Más allá de eso, no estoy seguro de qué significa aquí "en lugar de NSURLConnection " en cualquier caso.

Si querían sendAsynchronousRequest:queue:completionHandler: (que es NSURLConnection ), es conveniente, pero mucho less flexible y potente que la NSURLConnection basada en NSURLConnection , por lo que la única respuesta que tendría sería "porque a veces es más conveniente y mantiene el código más cerca, cuando no necesitas mucha flexibilidad ".

A less que lo que realmente quieren decir es la parte de GCD que realmente hace esto: Dispatch I / O. Hay razones para usar eso directamente (especialmente si está utilizando protocolos que no son HTTP, o si está administrando un server HTTP en lugar de un cliente), pero son raros y no suelen "download files de forma asíncrona". Las API de mayor nivel son las preferidas en la mayoría de los casos.

Si estuvieras haciendo muchas conexiones, transfiriendo una tonelada de datos a través de una connection de networking muy rápida, quizás pueda ver cómo el NSURLConnection usa el runloop para el event handling E / S y las devoluciones de llamada podrían ser problemáticas, si está progtwigndo estas conexiones NSURLConnections en el runloop principal Dicho esto, también podría crear un subprocess de background de menor prioridad con su propio runloop para mantener esas operaciones fuera del hilo principal.

Si no necesitaba toda la maquinaria adicional de NSURLConnection (almacenamiento en caching, authentication, etc.), dispatch_io* es casi seguro que es un mecanismo indirecto más bajo para manejar E / S de networking sin procesar, pero realmente estaría renunciando a un poco de funcionalidad para Lo que espero, prácticamente hablando, es una mejora de performance muy marginal .

No estoy seguro. Principalmente porque el método sendAsynchronousRequest de NSURLConnection tiene incorporado un manejador de finalización que utiliza un bloque.

¿Tal vez una pregunta tramposa? Para mí, parece que el entrevistador solo quería ver si podía concluir que ambos pueden cumplir la misma function.

Los bloques y GCD no son específicamente para descargas, pero pueden facilitar la descarga. Tendrías que usarlos junto con algo que hizo la descarga (como NSURLConnection ).

La ventaja de usar GCD con NSURLConnection es que puede empaquetarlo bien y no tener que depender de los methods de delegado desplegables. Puede limitar el número de conexiones fácilmente también, así como detener y detener conexiones.

Mi "ir a" configurado para una networking compleja es utilizar las subclasss NSOperationQueue y NSOperation para hacer el trabajo.

Cada operación utiliza una NSURLConnection y sus methods delegates para download los datos y luego procesarlos.

En cierto modo, esto ya está usando GCD través de NSOperationQueue pero no puedo ver una razón para usar cualquier otro método que combine bloques y GCD, etc.

¿Le dieron una respuesta "correcta"?