Abrufen von Kerndaten im Hintergrund über den neuen NSPrivateQueueConcurrencyType

Question

Ist es jetzt in iOS5 wirklich so einfach?

Ich habe mit diesem Code in meinem AppDelegate einen Hintergrundabruf durchgeführt:

dispatch_queue_t downloadQueue = dispatch_queue_create("DownloadQueue", NULL);
dispatch_async(downloadQueue, ^{
        self.myDownloadClass = [[MyDownloadClass alloc]initInManagedObjectContext:self.managedObjectContext];
        [self.myDownloadClass download];
    });

dispatch_release(downloadQueue);

Meine Download-Klasse führt eine NSURLConnection aus, um einige XML-Daten abzurufen, verwendet NSXMLParser, um die Daten zu parsen, und aktualisiert dann ein komplexes Schema in den Kerndaten. Ich würde immer zum Hauptthread wechseln, um die Kerndaten zu aktualisieren. Unübersichtlicher Code mit vielen Aufrufen von dispatch_sync(dispatch_get_main_queue()....

Mein neuer Code sieht wie folgt aus:

NSManagedObjectContext *child = [[NSManagedObjectContext alloc]initWithConcurrencyType:NSPrivateQueueConcurrencyType];
[child setParentContext:self.managedObjectContext];

[child performBlock:^{
    self.myDownloadClass = [[MyDownloadClass alloc]initInManagedObjectContext:child];
    [self.myDownloadClass download];
    }];

zusammen mit einer kleinen Änderung an etwas anderem Code in meinem AppDelegate, um den übergeordneten Modellobjektkontexttyp auf NSMainQueueConcurrencyType zu setzen:

- (NSManagedObjectContext *)managedObjectContext
{
    if (__managedObjectContext != nil)
    {
        return __managedObjectContext;
    }

    NSPersistentStoreCoordinator *coordinator = [self persistentStoreCoordinator];
    if (coordinator != nil)
    {
        __managedObjectContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSMainQueueConcurrencyType];
        [__managedObjectContext setPersistentStoreCoordinator:coordinator];
    }
    return __managedObjectContext;
}

Es scheint sehr gut zu funktionieren. Der gesamte Aktualisierungsprozess läuft immer noch in einem separaten Thread, aber ich musste keinen neuen Thread erstellen. Scheint wie Magie.

Denken Sie daran, dass Sie auch im übergeordneten Kontext save: aufrufen müssen, wenn Sie Ihre Änderungen an den physischen Kerndateien festschreiben wollen.

Ich habe hier nicht wirklich eine Frage gestellt. Ich poste dies, damit es anderen hilft, weil alles, was ich bei der Suche nach den neuen iOS5 verwalteten Objektkontextmethoden gefunden habe, nur High-Level-Details ohne Code-Beispiele gab und alle anderen Suchen für das Abrufen von Kerndaten im Hintergrund alt sind, manchmal sehr alt, und diskutieren, wie man es vor iOS5 zu tun.

Answer 1

Ja - es ist jetzt wirklich so einfach (in iOS 5.0). Für iOS 4 Kompatibilität, die früheren Hürden bleiben, aber die Dokumentation ist nicht zu schlecht auf Thread-Einschränkung. Vielleicht sollten Sie dies zu einem Wiki-Abschnitt hinzufügen?

Answer 2

Ich versuche zu verstehen, wie diese neue API implementiert ist. Mein übliches Muster für Multithreading-Kerndaten ist in etwa so:

Normalerweise in einer NSOperation aber vereinfacht durch dispatch_async in diesem Beispiel:

dispatch_queue_t coredata_queue; // some static queue

dispatch_async(coredata_queue, ^() {
    // get a new context for this thread, based on common persistent coordinator
    NSManagedObjectContext *context = [[MyModelSingleton model] threadedContext];

    // do something expensive

    NSError *error = nil;
    BOOL success = [context save:&error];
    if (!success) {
        // the usual.
    }

    // callback on mainthread using dispatch_get_main_queue();
});

Dann reagiert der Hauptthread mit der Aktualisierung der Benutzeroberfläche auf der Grundlage von NSManagedObjectContextDidSaveNotification um den Hauptkontext zusammenzuführen.

Die neuen APIs scheinen eine Umhüllung dieses Musters zu sein, wobei die child Kontext sieht so aus, als würde er einfach den persistenten Koordinator aus seinem übergeordneten Kontext übernehmen, um einen neuen Kontext zu erstellen. Und die Angabe von NSPrivateQueueConcurrencyType bei init stellt sicher, dass die performBlock wird in der privaten Warteschlange ausgeführt.

Die neue API scheint nicht viel weniger Code zu enthalten. Gibt es Vorteile gegenüber dem "traditionellen" Threading?