Patrones de diseño recomendados para bloques asíncronos?

Question

Estoy trabajando en una aplicación iOS que tiene un diseño altamente asincrónico. Hay circunstancias en las que una única "operación" conceptual puede poner en cola muchos bloques secundarios que se ejecutarán de forma asincrónica y recibirán sus respuestas (llamadas al servidor remoto) de forma asincrónica. Cualquiera de estos bloques secundarios podría terminar la ejecución en un estado de error. En caso de que ocurra un error en cualquier bloque secundario, cualquier otro bloque secundario debe cancelarse, el estado de error debe filtrarse hasta el padre y debe ejecutarse el bloque de administración de errores del padre.

Me pregunto qué patrones de diseño y otros consejos podrían recomendarse para trabajar en un entorno como este.

Conozco las capacidades dispatch_group_async y dispatch_group_wait de GCD. Puede ser un error en el diseño de esta aplicación, pero no he tenido suerte con dispatch_group_async porque el grupo no parece ser "adherente" a los bloques secundarios.

¡Gracias de antemano!

Answer 1

Hay un video de WWDC (2012) que probablemente lo ayude. Utiliza un NSOperationQueue personalizado y coloca los bloques asíncronos dentro de NSOperations para que pueda mantener un control sobre los bloques y cancelar los bloques restantes en cola.

Una idea sería tener el manejo de errores de los bloques secundarios para llamar a un método en el hilo principal en la clase que maneja el NSOperationQueue. La clase podría cancelar el resto apropiadamente. De esta forma, el bloqueo para niños solo necesita conocer su propio hilo y el hilo principal. Aquí hay un enlace al video

https://developer.apple.com/videos/wwdc/2012/

El video se llama "La construcción de interfaces de usuario concurrentes en iOS". La parte relevante se encuentra principalmente en la segunda mitad, pero es probable que desee ver todo, ya que lo contextualiza.

EDIT:

Si es posible, me gustaría recomendar el manejo de la respuesta en un bloque incorporado, que lo envuelve muy bien juntos, que es lo que pienso que está buscando ..

//Define an NSBlockOperation, and get weak reference to it 
NSBlockOperation *blockOp = [[NSBlockOperation alloc]init]; 
__weak NSBlockOperation *weakBlockOp = blockOp; 

//Define the block and add to the NSOperationQueue, when the view controller is popped 
//we can call -[NSOperationQueue cancelAllOperations] which will cancel all pending threaded ops 
[blockOp addExecutionBlock: ^{ 

    //Once a block is executing, will need to put manual checks to see if cancel flag has been set otherwise 
    //the operation will not be cancelled. The check is rather pointless in this example, but if the 
    //block contained multiple lines of long running code it would make sense to do this at safe points 
    if (![weakBlockOp isCancelled]) { 

     //substitute code in here, possibly use *synchronous* NSURLConnection to get 
     //what you need. This code will block the thread until the server response 
     //completes. Hence not executing the following block and keeping it on the 
     //queue. 
     __block NSData *temp; 
     response = [NSData dataWithContentsOfURL:[NSURL URLWithString:urlString]]; 

     [operationQueue addOperationWithBlock:^{ 
      if (error) { 
        dispatch_async(dispatch_get_main_queue(), ^{ 
         //Call selector on main thread to handle canceling 
         //Main thread can then use handle on NSOperationQueue 
         //to cancel the rest of the blocks 
        }); 
      else { 
       //Continue executing relevant code....  
      } 
     }]; 
    } 
}]; 
[operationQueue addOperation:blockOp]; 

Answer 2

Hay muchas formas de lograr un comportamiento asincrónico en el cacao.

GCD, NSOperationQueue, performSelectorAfterDelay, creando sus propios hilos. Hay momentos apropiados para usar estos mecanismos. Demasiado tiempo para debatir aquí, pero algo que usted mencionó en su publicación debe abordarse.

En caso de que se produzca un error en cualquier bloque secundario, cualquier otro bloque secundario debe cancelarse, el estado de error debe filtrarse hasta el padre y debe ejecutarse el bloque de gestión de errores del padre.

Los bloques no pueden arrojar errores a la pila. Período.

Answer 3

Un patrón que he encontrado desde que publiqué esta pregunta era usando un semáforo para cambiar lo que sería una operación asíncrona en una operación síncrona. Esto ha sido bastante útil. Esta publicación de blog cubre el concepto en mayor detalle.

http://www.g8production.com/post/76942348764/wait-for-blocks-execution-using-a-dispatch-semaphore