Des Alternatives à dispatch_get_current_queue() pour la réalisation des blocs dans iOS 6?

Sur le modèle de "l'exécuter sur n'importe quel file d'attente de l'appelant était" est séduisante, mais finalement pas une bonne idée. Cette file d'attente pourrait être une priorité de la file d'attente, la file d'attente principale, ou une autre file d'attente avec de curieuses propriétés.

Mon approche préférée pour ce est-à-dire "la fin du bloc s'exécute sur une mise en œuvre définies file d'attente avec les propriétés suivantes: x, y, z", et de laisser le bloc d'envoi à une file d'attente particulière si l'appelant veut plus de contrôle que cela. Typique d'un ensemble de propriétés pour spécifier serait quelque chose comme "série, non réentrant, et asynchrone par rapport à tout autre visible par l'application de la file d'attente".

** EDIT **

Catfish_Man mis un exemple dans les commentaires ci-dessous, je suis juste de l'ajouter à sa réponse.

- (void) aMethodWithCompletionBlock:(dispatch_block_t)completionHandler     
{ 
    dispatch_async(self.workQueue, ^{ 
        [self doSomeWork]; 
        dispatch_async(self.callbackQueue, completionHandler); 
    } 
}

Autres réponses sont grands, mais pour moi la réponse est d'ordre structurel. J'ai une méthode comme ceci sur un Singleton:

- (void) dispatchOnHighPriorityNonMainQueue:(simplest_block)block forceAsync:(BOOL)forceAsync {
    if (forceAsync || [NSThread isMainThread])
        dispatch_async_on_high_priority_queue(block);
    else
        block();
}

qui a deux dépendances, qui sont:

static void dispatch_async_on_high_priority_queue(dispatch_block_t block) {
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), block);
}

et

typedef void (^simplest_block)(void); //also could use dispatch_block_t

De cette façon je peux centraliser mes appels à l'expédition sur l'autre fil.

Pour ceux qui doivent encore dans la file d'attente de comparaison, vous pourrez comparer les files d'attente de par leur étiquette ou précise.
Cochez cette https://stackoverflow.com/a/23220741/1531141

C'est un moi trop de réponse. Je vais donc parler de notre cas d'utilisation.

Nous avons une couche de services et la couche d'INTERFACE utilisateur (parmi d'autres couches). La couche de services exécute des tâches en arrière-plan. (Tâches de manipulation de données, CoreData tâches, appels Réseau, etc). La couche de service a un couple de fonctionnement des files d'attente à satisfaire les besoins de la couche d'INTERFACE utilisateur.

La couche d'INTERFACE utilisateur repose sur la couche de services pour faire son travail et puis exécutez le succès de l'achèvement du bloc. Ce bloc peut avoir UIKit du code. Un cas d'utilisation simple pour obtenir tous les messages sur le serveur et de le recharger l'affichage de la collection.

Ici, nous garantissons que les blocs qui sont transmis à la couche de services sont envoyés sur la liste d'attente sur laquelle le service a été invoqué sur. Depuis dispatch_get_current_queue est une méthode dépréciée, nous utilisons la NSOperationQueue.currentQueue pour obtenir de l'appelant file d'attente en cours. Remarque importante sur cette propriété.

L'appel de cette méthode à partir de l'extérieur du contexte d'une opération
en général, les résultats dans nil est retourné.

Depuis que nous avons toujours demander l'aide de nos services sur une file d'attente connu (à Notre clientèle les files d'attente et de la file d'attente Principale) cela fonctionne bien pour nous. Nous avons des cas où serviceA peut appeler serviceB qui peut appeler serviceC. Depuis que nous avons de contrôle où le premier appel de service est effectué à partir d', nous savons que le reste de la les services suivent les mêmes règles.

Donc NSOperationQueue.currentQueue retournera toujours un de nos Files d'attente ou les MainQueue.