Gérer un groupe de NSOperation avec des dépendances

Un couple de pensées:

1. J'ai tendance à me prévaloir de l'achèvement des blocs parce que vous probablement ne voulez lancer l'opération suivante que si la précédente a réussi. Vous voulez vous assurer que vous gérer correctement les erreurs et peut facilement sortir de votre chaîne d'opérations, si l'on échoue.

2. Si je voulais passer des données d'opération à l'autre et ne voulais pas utiliser une propriété de l'appelant classe, je serais probablement définir ma propre réalisation bloc comme une propriété de mon opération personnalisée qui avait un paramètre qui comprenait le domaine que je voulais passer d'une opération à l'autre. Cela suppose, cependant, que vous êtes en train de faire NSOperation sous-classement.

   Par exemple, je pourrais avoir un FilenameOperation.h qui définit une interface pour mon opération de la sous-classe:

   #import <Foundation/Foundation.h>
   
   typedef void (^FilenameOperationSuccessFailureBlock)(NSString *filename, NSError *error);
   
   @interface FilenameOperation : NSOperation
   
   @property (nonatomic, copy) FilenameOperationSuccessFailureBlock successFailureBlock;
   
   @end

   et si ce n'était pas un fonctionnement parallèle, la mise en œuvre pourrait ressembler à:

   #import "FilenameOperation.h"
   
   @implementation FilenameOperation
   
   - (void)main
   {
       if (self.isCancelled)
           return;
   
       NSString *filename = ...;
       BOOL failure = ...
   
       if (failure)
       {
           NSError *error = [NSError errorWithDomain:... code:... userInfo:...];
           if (self.successFailureBlock)
               self.successFailureBlock(nil, error);                                                    
       }
       else
       {
           if (self.successFailureBlock)
               self.successFailureBlock(filename, nil);
       }
   }
   
   @end

   Clairement, si vous avez un concurrent à l'opération, vous allez mettre en œuvre tous de la norme isConcurrentisFinished et isExecuting logique, mais l'idée est la même. En aparté, parfois, les gens vont distribuer ces succès ou des échecs de retour à la file d'attente principale, de sorte que vous pouvez le faire si vous le souhaitez, trop.

   Peu importe, ce qui illustre l'idée d'une propriété personnalisée avec ma propre réalisation bloc qui transmet les données appropriées. Vous pouvez répéter ce processus pour chacun des types d'opérations, vous pouvez ensuite la chaîne d'eux, tous ensemble, avec quelque chose comme:

   FilenameOperation *filenameOperation = [[FilenameOperation alloc] init];
   GenerateOperation *generateOperation = [[GenerateOperation alloc] init];
   UploadOperation   *uploadOperation   = [[UploadOperation alloc] init];
   
   filenameOperation.successFailureBlock = ^(NSString *filename, NSError *error) {
       if (error)
       {
           //handle error
           NSLog(@"%s: error: %@", __FUNCTION__, error);
       }
       else
       {
           generateOperation.filename = filename;
           [queue addOperation:generateOperation];
       }
   };
   
   generateOperation.successFailureBlock = ^(NSString *filename, NSData *data, NSError *error) {
       if (error)
       {
           //handle error
           NSLog(@"%s: error: %@", __FUNCTION__, error);
       }
       else
       {
           uploadOperation.filename = filename;
           uploadOperation.data     = data;
           [queue addOperation:uploadOperation];
       }
   };
   
   uploadOperation.successFailureBlock = ^(NSString *result, NSError *error) {
       if (error)
       {
           //handle error
           NSLog(@"%s: error: %@", __FUNCTION__, error);
       }
       else
       {
           [[NSOperationQueue mainQueue] addOperationWithBlock:^{
               //update UI here
               NSLog(@"%@", result);
           }];
       }
   };
   
   [queue addOperation:filenameOperation];

3. Une autre approche dans les scénarios plus complexes est d'avoir votre NSOperation sous-classe employer une technique analogue à la façon dont la norme addDependency méthode fonctionne, dans lequel NSOperation définit la isReady état basé sur KVO sur isFinished sur l'autre opération. Non seulement cela vous permet non seulement de créer plus de dépendances complexes entre les opérations, mais aussi pour passer de la base de données entre eux. C'est probablement au-delà de la portée de cette question (et je suis déjà à la souffrance de tl:dr), mais laissez-moi savoir si vous avez besoin de plus ici.

4. Je ne serais pas trop inquiet que uploadImageToCreatedEntry est en train d'envoyer au thread principal. En dessins compliqués, vous pouvez avoir toutes sortes de différentes files d'attente dédiée, pour certains types d'opérations, et le fait que l'INTERFACE utilisateur des mises à jour sont ajoutés à la file d'attente principale est parfaitement compatible avec ce mode. Mais au lieu de dispatch_asyncj'ai peut-être enclins à utiliser l' NSOperationQueue équivalent:

   [[NSOperationQueue mainQueue] addOperationWithBlock:^{
       //do my UI update here
   }];

5. Je me demande si vous avez besoin de toutes ces opérations. Par exemple, j'ai du mal à imaginer que filename est suffisamment complexe pour justifier son propre fonctionnement (mais si vous obtenez le nom de fichier à partir d'une certaine distance de la source, puis d'une opération distincte est parfaitement logique). Je vais supposer que vous êtes en train de faire quelque chose d'assez compliqué qui la justifie, mais les noms de ces opérations, je me demande, si.

6. Si vous le souhaitez, vous voudrez peut-être jeter un oeil à couchdeveloper de RXPromise classe qui utilise promesses (a) le contrôle de la relation logique entre les différentes opérations; et (b) simplifier la transmission des données de l'un à l'autre. Mike Ash a un vieux MAFuture classe qui fait la même chose.

   Je ne suis pas sûr non plus de ceux qui sont assez matures que j'avais contempler les utiliser dans mon propre code, mais c'est une idée intéressante.

Si vous voulez toujours utiliser NSOperation, vous pouvez compter sur ProcedureKit et l'utilisation de l'injection propriétés de la Procedure classe.

Pour chaque opération, précisez de quel type il produit et de l'injecter à la prochaine opération dépendant. Vous pouvez aussi à la fin d'envelopper l'ensemble du processus à l'intérieur d'un GroupProcedure classe.