A quoi sert performBlock: utilisé par NSManagedObjectContext?

Question

Dans iOS 5, NSManagedObjectContext a quelques nouvelles méthodes, performBlock: et performBlockAndWait: . A quoi servent réellement ces méthodes? Que remplacent-ils dans les anciennes versions? Quel type de bloc est censé leur être transmis? Comment puis-je décider lequel utiliser? Si quelqu'un a des exemples d'utilisation, ce serait génial.

Answer 1

Les méthodes d' performBlock: et performBlockAndWait: sont utilisés pour envoyer des messages à votre NSManagedObjectContext exemple si la MOC a été initialisé à l'aide d' NSPrivateQueueConcurrencyType ou NSMainQueueConcurrencyType. Si vous faites quelque chose avec l'un de ces types de contexte, telles que le réglage de la persistance ou de l'enregistrement des modifications, vous le faites dans un bloc.

performBlock: va ajouter le bloc à la sauvegarde de la file d'attente et de planifier pour l'exécuter sur son propre thread. Le bloc sera de retour immédiatement. Vous pouvez l'utiliser pour les longues persistent opérations de la mémoire de sauvegarde.

performBlockAndWait: également ajouter le bloc à la sauvegarde de la file d'attente et de planifier pour l'exécuter sur son propre thread. Cependant, le bloc ne sera pas de retour jusqu'à ce que le bloc est terminée en cours d'exécution. Si vous ne pouvez pas vous déplacer jusqu'à ce que vous savez 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 une performBlockAndWait:, je peux accéder à l'erreur à l'extérieur du bloc. performBlock: nécessiterait une approche différente.

À partir de l' iOS 5 de base de données notes de publication:

NSManagedObjectContext offre maintenant un soutien structuré pour les opérations simultanées. Lorsque vous créez un objet géré contexte à l'aide de initWithConcurrencyType:, vous disposez de trois options pour son filetage (file d'attente) de l'association

• L'Accouchement (NSConfinementConcurrencyType).

  C'est la valeur par défaut. Vous promettez que le contexte ne sera pas utilisé par n'importe quel thread autre que celui sur lequel vous l'avez créé. (C'est exactement le même filetage exigence que vous avez utilisé 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 vous la création et la gestion d'un fil ou de la file d'attente avec qui 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 utilisez le bloc-fondé des méthodes décrites ci-dessous).

• File principale (NSMainQueueConcurrencyType).

  Le contexte est associé à la file d'attente principale, et, comme telle, est liée à l'application de la boucle d'événements, mais il en est autrement semblable à une file d'attente privée contexte. Vous utilisez ce type de file d'attente pour les contextes liés aux contrôleurs et les objets de l'INTERFACE utilisateur qui sont requis pour être utilisé uniquement sur le thread principal.

Answer 2

Ils vous permettent d'accéder à la même managedObjectContext à travers les fils.

Je ne suis pas vraiment sûr que je suis correct, mais c'est la façon dont je l'utilise.

Vous utilisez performBlockAndWait est "comme d'habitude". Vous n'en avez pas besoin si vous exécutez le managedObjectContext sur un seul thread. Si vous exécuter sur le nombre de threads alors oui, vous aurez besoin performBlock.

Donc, si vous êtes sur le thread principal, vous n'avez pas besoin de faire d' performBlockAndWait pour le principal managedObjectContext. Au moins je ne suis pas et se porte bien.

Toutefois, si vous avez accès qu' managedObjectContext sur d'autres threads alors oui, vous aurez besoin de faire performBlockAndWait.

Donc, c'est le but de l' performBlock et performBlockAndWait.

Quelqu'un s'il vous plaît corrigez-moi si je me trompe ici. Bien sûr, si vous accédez au contexte uniquement sur un fil, alors vous pouvez simplement utiliser la valeur par défaut.