¿Cómo uso NSOperationQueue con NSURLSession?

Conceptualmente, NSURLSession es una cola de operaciones. Si reanuda una tarea de NSURLSession y un punto de interrupción en el controlador de finalización, el seguimiento de pila puede ser bastante revelador.

Aquí hay un extracto del siempre fiel tutorial de Ray Wenderlich sobre NSURLSession con una instrucción NSLog añadida al punto de interrupción al ejecutar el controlador de finalización:

NSURLSession *session = [NSURLSession sharedSession];
[[session dataTaskWithURL:[NSURL URLWithString:londonWeatherUrl]
          completionHandler:^(NSData *data,
                              NSURLResponse *response,
                              NSError *error) {
            // handle response
            NSLog(@"Handle response"); // <-- breakpoint here       

  }] resume];

Arriba, podemos ver el controlador de finalización siendo ejecutado en Thread 5 Queue: NSOperationQueue Serial Queue.

Entonces, mi conjetura es que cada NSURLSession mantiene su propia cola de operaciones, y cada tarea añadida a una sesión se ejecuta, bajo el capó, como una NSOperation. Por lo tanto, no tiene sentido mantener una cola de operaciones que controle los objetos NSURLSession o las tareas NSURLSession.

NSURLSessionTask ya ofrece métodos equivalentes como cancel, resume, suspend, y así sucesivamente.

Es cierto que hay menos control del que tendría con su propia NSOperationQueue. Pero, de nuevo, NSURLSession es un nueva clase cuyo propósito es indudablemente aliviaros de esa carga.

En pocas palabras: si desea menos complicaciones, pero menos control, y confía en Apple para realizar las tareas de red de manera competente en su nombre, use NSURLSession. De lo contrario, haga su propio rollo con NSURLConnection y sus propias colas de operación.

Actualización: Las propiedades executing y finishing contienen el conocimiento sobre el estado del NSOperation actual. Una vez que finishing se establece en YES y executing a NO, su operación se considera terminada. La forma correcta de tratar con él no requiere un dispatch_group y simplemente se puede escribir como un NSOperation asíncrono:

  - (BOOL) isAsynchronous {
     return YES;
  }

  - (void) main
    {
       // We are starting everything
       self.executing = YES;
       self.finished = NO;

       NSURLSession * session = [NSURLSession sharedInstance];

       NSURL *url = [NSURL URLWithString:@"http://someurl"];

       NSURLSessionDataTask * dataTask = [session dataTaskWithURL:url completionHandler:^(NSData *data, NSURLResponse *response, NSError *error){

          /* Do your stuff here */

         NSLog("Will show in second");

         self.executing = NO;
         self.finished = YES;
       }];

       [dataTask resume]
   }

El término asynchronous es bastante engañoso y no se refiere a la diferenciación entre el hilo de interfaz de usuario (principal) y el hilo de fondo.

Si isAsynchronous está establecido to YES, significa que alguna parte del código se ejecuta asíncronamente con respecto al método main . Dicho de otra manera: se realiza una llamada asíncrona dentro del método main y el método terminará después de que el método principal termine.

Tengo algunas diapositivas sobre cómo manejar la concurrencia en el sistema operativo apple: https://speakerdeck.com/yageek/concurrency-on-darwin .

Respuesta antigua : Puedes probar el dispatch_group_t. Usted puede pensar que como retener contador para GCD.

Imagine el siguiente código en el método main de su subclase NSOperation:

- (void) main
{

   self.executing = YES;
   self.finished = NO;

   // Create a group -> value = 0
   dispatch_group_t group = dispatch_group_create();

   NSURLSession * session = [NSURLSession sharedInstance];

   NSURL *url = [NSURL URLWithString:@"http://someurl"];

    // Enter the group manually -> Value = Value + 1
   dispatch_group_enter(group); ¨

   NSURLSessionDataTask * dataTask = [session dataTaskWithURL:url completionHandler:^(NSData *data, NSURLResponse *response, NSError *error){


      /* Do your stuff here */

      NSLog("Will show in first");

      //Leave the group manually -> Value = Value - 1
      dispatch_group_leave(group);
   }];

   [dataTask resume];

  // Wait for the group's value to equals 0
  dispatch_group_wait(group, DISPATCH_TIME_FOREVER);

  NSLog("Will show in second");

  self.executing = NO;
  self.finished = YES;
}

Con NSURLSession no agrega manualmente ninguna operación a una cola. Utiliza el método - (NSURLSessionDataTask *)dataTaskWithRequest:(NSURLRequest *)request en NSURLSession para generar una tarea de datos que luego inicia (llamando al método resume).

Se le permite proporcionar la cola de operaciones para que pueda controlar las propiedades de la cola y también usarla para otras operaciones si lo desea.

Cualquiera de las acciones habituales que desea realizar en una NSOperation (es decir, iniciar, pausar, detener, reanudar) que realiza en los datos tarea.

Para poner en cola 50 imágenes para descargar, simplemente puede crear 50 tareas de datos que NSURLSession pondrá en cola correctamente.

Si está utilizando OperationQueue y no desea que cada operación cree muchas solicitudes de red simultáneas, simplemente puede llamar a la cola.waitUntilAllOperationsAreFinished () después de agregar cada operación a la cola. Ahora solo se ejecutarán después de que se complete el anterior, reduciendo significativamente la cantidad de conexiones de red simultáneas.

Tal vez usted está buscando esto:

Http://www.dribin.org/dave/blog/archives/2009/05/05/concurrent_operations /

Es un poco raro que esto no sea 'builtin', pero si quieres conectar cosas de NSURL con NSOperation parece que tienes que reutilizar el runloop en el hilo principal y hacer que la operación sea 'concurrente' ('concurrente' a la cola).

Aunque en su caso , si se trata de descargas simples, sin operaciones dependientes posteriores conectado-No estoy seguro de lo que ganaría con el uso de NSOperation.