web-dev-qa-db-fra.com

À quoi sert performBlock de NSManagedObjectContext: utilisé?

Dans iOS 5, NSManagedObjectContext propose quelques nouvelles méthodes, performBlock: et performBlockAndWait:. À quoi ces méthodes sont-elles réellement utilisées? Que remplacent-ils dans les anciennes versions? Quels types de blocs sont censés leur être transmis? Comment puis-je décider lequel utiliser? Si quelqu'un a des exemples de son utilisation, ce serait formidable.

ioscore-dataios5nsmanagedobjectcontextblocking
66
nevan king

Les méthodes performBlock: et performBlockAndWait: sont utilisés pour envoyer des messages à votre instance NSManagedObjectContext si le MOC a été initialisé à l'aide de NSPrivateQueueConcurrencyType ou NSMainQueueConcurrencyType. Si vous faites quoi que ce soit avec l'un de ces types de contexte, comme la définition du magasin persistant ou l'enregistrement des modifications, vous le faites dans un bloc.

performBlock: ajoutera le bloc à la file d'attente de sauvegarde et planifiera son exécution sur son propre thread. Le bloc reviendra immédiatement. Vous pouvez l'utiliser pour les opérations de longue persistance vers le magasin de sauvegarde.

performBlockAndWait: ajoutera également le bloc à la file d'attente de sauvegarde et planifiera son exécution sur son propre thread. Cependant, le bloc ne reviendra pas tant que l'exécution du bloc n'est pas terminée. Si vous ne pouvez pas continuer jusqu'à ce que vous sachiez si l'opération a réussi, alors c'est votre choix.

Par exemple:

__block NSError *error = nil;
[context performBlockAndWait:^{
    myManagedData.field = @"Hello";
    [context save:&error];
}];

if (error) {
    // handle the error.
}

Notez que parce que j'ai fait un performBlockAndWait:, Je peux accéder à l'erreur en dehors du bloc. performBlock: nécessiterait une approche différente.

À partir des Notes de publication des données de base iOS 5 :

NSManagedObjectContext fournit désormais un support structuré pour les opérations simultanées. Lorsque vous créez un contexte d'objet géré à l'aide de initWithConcurrencyType:, vous avez trois options pour son association de thread (file d'attente)

  • Confinement (NSConfinementConcurrencyType).

    C'est la valeur par défaut. Vous promettez que le contexte ne sera utilisé par aucun thread autre que celui sur lequel vous l'avez créé. (Il s'agit exactement de la même exigence de filetage que celle utilisée dans les versions précédentes.)

  • File d'attente privée (NSPrivateQueueConcurrencyType).

    Le contexte crée et gère une file d'attente privée. Au lieu de créer et de gérer un thread ou une file d'attente auquel un contexte est associé, ici le contexte est propriétaire de la file d'attente et gère tous les détails pour vous (à condition que vous utilisiez les méthodes basées sur les blocs comme décrit ci-dessous).

  • File d'attente principale (NSMainQueueConcurrencyType).

    Le contexte est associé à la file d'attente principale et, en tant que tel, est lié à la boucle d'événements de l'application, mais il est par ailleurs similaire à un contexte basé sur une file d'attente privée. Vous utilisez ce type de file d'attente pour les contextes liés aux contrôleurs et aux objets d'interface utilisateur qui doivent être utilisés uniquement sur le thread principal.

124
MikeG