NSFetchedResultsController: Fetch in einem hintergrund-thread

Habe ich eine mehr oder weniger grundlegende UITableViewController mit einem NSFetchedResultsController. Die UITableViewController geschoben wird, ist auf die navigationController's stack. Aber die push-animation nicht glatt, da der Abruf NSFetchedResultsController erfolgt über den Haupt-thread, und daher blockiert das UI.

Meine Frage ist: Wie kann ich die abrufen der NSFetchedResultsController in einem hintergrund-thread, damit die animation zu glatt?

Den NSFetchedResultsController und die delegate-Methoden wie folgt Aussehen:

- (NSFetchedResultsController *)fetchedResultsController
{
    if (_fetchedResultsController != nil) {
        return _fetchedResultsController;
    }

    NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
    //Edit the entity name as appropriate.
    NSEntityDescription *entity = [NSEntityDescription entityForName:@"GPGrade" inManagedObjectContext:self.managedObjectContext];
    [fetchRequest setEntity:entity];

    //Set the batch size to a suitable number.
    [fetchRequest setFetchBatchSize:20];

    //Set predicate
    NSPredicate *predicate = [NSPredicate predicateWithFormat:@"parent == %@", self.subject];
    [fetchRequest setPredicate:predicate];


    //Edit the sort key as appropriate.
    NSSortDescriptor *sortDescriptor = [[NSSortDescriptor alloc] initWithKey:@"name" ascending:YES];
    NSArray *sortDescriptors = @[sortDescriptor];

    [fetchRequest setSortDescriptors:sortDescriptors];

    //Edit the section name key path and cache name if appropriate.
    //nil for section name key path means "no sections".
    NSFetchedResultsController *aFetchedResultsController = [[NSFetchedResultsController alloc] initWithFetchRequest:fetchRequest managedObjectContext:self.managedObjectContext sectionNameKeyPath:nil cacheName:@"SubjectMaster"];
    aFetchedResultsController.delegate = self;
    self.fetchedResultsController = aFetchedResultsController;

    NSError *error = nil;
    if (![self.fetchedResultsController performFetch:&error]) {
        //Replace this implementation with code to handle the error appropriately.
        //abort() causes the application to generate a crash log and terminate. You should not use this function in a shipping application, although it may be useful during development.
        NSLog(@"Unresolved error %@, %@", error, [error userInfo]);
        abort();
    }

    return _fetchedResultsController;
}

- (void)controllerWillChangeContent:(NSFetchedResultsController *)controller
{
    [self.tableView beginUpdates];
}

- (void)controller:(NSFetchedResultsController *)controller didChangeSection:(id <NSFetchedResultsSectionInfo>)sectionInfo
           atIndex:(NSUInteger)sectionIndex forChangeType:(NSFetchedResultsChangeType)type
{    
    switch(type) {
        case NSFetchedResultsChangeInsert:
            [self.tableView insertSections:[NSIndexSet indexSetWithIndex:sectionIndex] withRowAnimation:UITableViewRowAnimationFade];
            break;

        case NSFetchedResultsChangeDelete:
            [self.tableView deleteSections:[NSIndexSet indexSetWithIndex:sectionIndex] withRowAnimation:UITableViewRowAnimationFade];
            break;
    }

}

- (void)controller:(NSFetchedResultsController *)controller didChangeObject:(id)anObject
       atIndexPath:(NSIndexPath *)indexPath forChangeType:(NSFetchedResultsChangeType)type
      newIndexPath:(NSIndexPath *)newIndexPath
{    
    UITableView *tableView = self.tableView;

    switch(type) {
        case NSFetchedResultsChangeInsert:
            [tableView insertRowsAtIndexPaths:@[newIndexPath] withRowAnimation:UITableViewRowAnimationTop];
            break;

        case NSFetchedResultsChangeDelete:
            [tableView deleteRowsAtIndexPaths:@[indexPath] withRowAnimation:UITableViewRowAnimationRight];
            break;

        case NSFetchedResultsChangeUpdate:
            //[self configureCell:(GPSubjectOverviewListCell *)[tableView cellForRowAtIndexPath:indexPath] atIndexPath:indexPath];
            break;

        case NSFetchedResultsChangeMove:
            [tableView deleteRowsAtIndexPaths:@[indexPath] withRowAnimation:UITableViewRowAnimationFade];
            [tableView insertRowsAtIndexPaths:@[newIndexPath] withRowAnimation:UITableViewRowAnimationFade];
            break;
    }
}

- (void)controllerDidChangeContent:(NSFetchedResultsController *)controller
{
    [self.tableView endUpdates];
}

Wollte nicht, diese in die Antwort - bist du dir sicher, dass die Core-Daten abrufen, die das problem verursacht? Geht das problem Weg, wenn Sie nicht instanziieren, die die gefundenen Ergebnisse-Controller?

InformationsquelleAutor burki | 2013-02-10

1

Der Regel mit Core Data ist eine Managed-Object-Context-pro-thread und ein thread pro MOC. Mit diesem im Verstand, den Sie brauchen, um den Abruf für die gefundenen Ergebnisse-Controller auf dem main-thread, da dies der thread, der Interaktion mit der FRC Verwalteten Objekte. (Siehe Core Data Programming Guide - Parallelität mit Core Data)

Wenn Sie performance-Probleme mit der animation, die Sie sollten wahrscheinlich betrachten Möglichkeiten, um sicherzustellen, dass der Abruf durchgeführt wird, bevor oder nachdem die Ansicht geschoben wird. Normalerweise würden Sie die Holen in der view controller ist viewDidLoad: und der navigation-controller würde nicht schieben Sie die Ansicht, bis der Abruf beendet ist.
- Die Frage war - wie kann ich verwenden NSFetchedResultsController zu abrufen von Daten im hintergrund? Gibt es irgendeine moderne Muster mit zwei MOCs (hintergrund & main queue) verschmelzen oder anderen trick?
- versuchen Sie, diese duckrowing.com/2010/03/11/using-core-data-on-multiple-threads
- Der link in deiner Antwort ist gebrochen.
- Dank behoben
- "Wenn Sie performance-Probleme mit der animation, die Sie sollten wahrscheinlich betrachten Möglichkeiten, um sicherzustellen, dass der Abruf durchgeführt wird, bevor oder nachdem die Ansicht gedrückt wird.". Nein. Einfach führen Sie es auf einem hintergrund. Das ist absoluter Unsinn.
- Es könnte scheinen, wie "Unsinn", wenn Sie nicht verstehen, thread confinement oder wie Core Data im Allgemeinen funktioniert. Auch wenn es hier eine Antwort, die zeigen, wie zu Holen, aus dem hintergrund, es ist gefährlich, zu tun, die für eine Vielzahl von Gründen. Core Data ist leicht zu hacken wie diese und ebenso leicht einführen, schwer zu Debuggen, Absturz induzieren Fehler.
InformationsquelleAutor ChrisH
20

TL;DR; Es gibt keinen guten Grund für die Verwendung von einem Kontext auf das Haupt-queue.

können NSFetchedResultsController zu abrufen von Daten im hintergrund

Absolut. NSFetchedResultsController verwendet werden kann, mit einer privaten Warteschlange Kontext. Es ist in der Tat sehr glücklich und leistungsfähig ist, wenn er so tut. Es ist ein bug , die verhindert, dass NSFetchedResultsController von der Verwendung des cache, wenn Sie eine private Warteschlange, aber der cache nicht gewinnen Sie so viel, wie in iOS 3.0. Legen Sie eine cacheName im nil, und Sie werden in Ordnung sein.

1. Einen Kontext schaffen, mit NSPrivateQueueConcurrencyType. Vorzugsweise nicht die, die Sie verwenden für die IO.

2. Erstellen der gefundenen Ergebnisse-controller mit, dass der Kontext, und einen cache-name nil.

3. Führen Sie Ihre ersten Abruf aus einem performBlock: block:
```
 [[[self fetchedResultsController] managedObjectContext] performBlock:^{
    NSError *fetchError = nil;
    if (![self fetchedResultsController] performFetch:&error]){
        ///handle the error. Don't just log it.
    } else {
        //Update the view from the main queue.
        [[NSOperationQueue mainQueue] addOperationWithBlock:^{
            [tableView reloadData];
         }];
    }
 }];
```
4. Alle Ihre Delegierten Rückrufe passieren wird, aus dem Kontext der Warteschlange. Wenn Sie diese verwenden, um Ansichten aktualisieren, so tun Sie es durch Versand an die main queue wie Sie oben sehen.

5. ...

6. Gewinn!

Lesen Sie mehr über dieses hier.
- Meinst du: [[fetchedResultsController managedObjectContext] performBlock^{...}];?
- Ja. Aktualisierte Antwort.
- sollte performBlockAndWait: ODER performBlock: verwendet so viel wie möglich, vorausgesetzt, MOC wird erstellt unter "NSPrivateQueueConcurrencyType" oder "NSMainQueueConcurrencyType"?
- Die queue-Zugriffsmethoden sind erforderlich, um verwendet werden für alles was mit den anderen Kontext, dass der Kontext die accessor-Methoden. Dies bedeutet, dass nur über alles-ja, auch den Zugriff auf die verwalteten Objekte und Ihre Eigenschaften.
- Ich habe Probleme bei der Umsetzung numberOfRowsInSection. Die sectionInfo gibt die gleiche Anzahl von Objekten, nachdem ich ein Objekt eingefügt, um den Kontext. Gibt es da eine spezielle threading-tricks umgesetzt werden sollten numberOfRowsInSection beim Zugriff auf eine FRC sectionInfo?
- Oh, nur higured heraus, dass im laden der Tabelle, während beginUpdates wurden nicht geschlossen mit endUpdates
- Bist du sicher, dass das thread-safe? Irgendwann, wenn Sie die Implementierung einer table view data source haben Sie Zugriff auf Eigenschaften/Methoden des NSFetchedResultsController aus dem Haupt-thread. Zum Beispiel[fetchedResultsController objectAtIndexPath:], fetchedResultsController.sections.count usw. Aber wenn Ihr NSFetchedResultsController erstellt wurde, auf einem hintergrund-thread und hört änderungen zu den managed object context, kann es sein, aktualisieren sich eigenständig, was in den Haupt-thread.
- was Sie beschreiben, ist mit dem Wert aus dem CoreData-call-Website auf dem Haupt-thread. Den Zugriff auf die call-Seite nicht haben, geschehen auf dem Haupt-thread - genau wie in der Antwort.
- In deinem verlinkten Beitrag, den Sie anrufen objectAtIndexPath: innen willDisplayCell:forRowAtIndexPath:, das Auftritt, im Haupt-thread. Woher wissen Sie, dass objectAtIndexPath: zurückkehren wird konsequent zwischen den aufrufen der willDisplayCell:forRowAtIndexPath:? Es scheint mir, die gefundenen Ergebnisse Steuerung lässt sich ändern unter Ihnen auf unvorhersehbare Weise. Bedenken Sie: kehren Sie zurück fetchedResultsController.sections.count um die Tabelle anzuzeigen. Es fordert Sie dann für die Zelle in der ersten index-Pfad. Aber heimlich im hintergrund-thread alles gelöscht wurde.
- wissen Sie, dass objectAtIndexPath: zurückkehren wird konsequent zwischen den aufrufen der willDisplayCell:forRowAtIndexPath:". Es ist keine Voraussetzung für objectAtIndexPath: Rückkehr desselben Objekts für die verschiedenen Anrufungen der willDisplayCell....
- Es ist nicht nur objectAtIndexPath:, es ist jeden NSFetchedResultsController API, die Sie am Ende Zugriff aus dem Haupt-thread. sections , section.numberOfObjects usw. All dies kann ändern, unter Sie, wenn das verwaltete Objekt-Kontext ändert sich im hintergrund.
- In dem Haupt-thread UITableView geht, rufen Sie Ihren numberOfSectionsInTableView, numberOfRowsInSection, cellForRowAtIndexPath in Folge. Überlegen Sie, was passieren könnte, wenn zwischen jedem dieser Aufrufe, wird der Inhalt der NSFetchedResultsController ist die gleichzeitige änderung in einem hintergrund-thread. Wie kann das möglich sein thread-safe?
- und performBlockAndWait: Betrieb an einer seriellen queue, mit dem VORBEHALT, dass performBlockAndWait: ablaufinvariant ist. Wie beschrieben in der Antwort (und Artikel), Zugriff auf alles Eigentum, die durch den Kontext geschehen sollte, durch diese Methoden - das sorgt für thread-Sicherheit.
- nicht lösen dieses problem. Ihre UITableView ruft numberOfSectionsInTableView, numberOfRows, und cellForRowAtIndexPath in Folge in der main-thread. Zwischen jedem dieser Aufrufe anderer code sein könnte, der Ausführung der hintergrund-thread, dass änderungen der zugrunde liegenden Daten und ungültig, was du zurückgegeben. Sie können nicht garantieren, dass die NSFetchedResultsController hat sich nicht geändert zwischen der Zeit, die Sie sagen, die UITableView "ich habe 3 Abschnitte" und die Zeit es fordert Sie für die Anzahl der Zeilen, die im ersten Abschnitt.
- Ja, tut es. Ihre Umsetzung, zum Beispiel numberOfSectionsInTableView brauchen würde, um den Zugriff auf die sectionInfo des NSFetchedResultsController Instanz und einen Wert zurückgeben. Es würde tun mit einem synchronen Aufruf aus der main queue auf den Kontext der Warteschlange und gibt das Ergebnis zurück an die main queue. Unabhängig davon, ob änderungen vorgenommen werden, um den Kontext, die Auswirkungen auf die NSFetchedResultsController die Stellvertretung informiert wird, die - synchron. Es ist die Verantwortung delegieren zu aktualisieren, die den Zustand der tableview entsprechend.
- Lassen Sie uns sagen, dass Sie wieder 10 Sektionen in numberOfSectionsInTableView. Neben der UITableView Anrufe numberOfRowsInSection. Zwischen diesen beiden Gesprächen gibt es die Gelegenheit für die NSFetchedResultsController verändert zu haben, sagen, indem ein (oder mehrere) Abschnitte. Der Haupt-thread ist immer noch die Ausführung der UITableView's Logik zum füllen der 10 Abschnitte, die Sie gesagt hatte. Er bittet Sie, für die Anzahl der Zeilen in jedem Abschnitt, von denen einige möglicherweise nicht mehr vorhanden. Sehen Sie das problem? Die NSFetchedResultsController delegieren, ist irrelevant, weil kein anderer code ausgeführt hat, die in der Haupt-thread.
- In Ihrem Szenario, wenn die Abschnitte ändern, die delegieren würde aufgerufen werden - Sperrung keine änderungen mehr an den Rahmen, bis die Steuerung ist freigegeben. Es liegt in der Verantwortung der Delegierten zum aktualisieren der Zustand der Tabelle Ansicht, dass delegate callback. Dies geschieht "zwischen den beiden anrufen". Sehr einfach.
- Aber siehe, das kann eigentlich nicht passieren, weil die Delegierten, die das Feuer auf einem hintergrund-thread. Haben Sie lob ein block auf der main queue ausgeführt werden auf dem Haupt-thread. Aber das wird nicht ausgeführt, bis später in der run loop. Wenn die UITableViewist in der Mitte einrichten (weil Sie genannt reloadData zum Beispiel), wird es nicht unterbrochen zu werden zwischen den aufrufen numberOfSectionsInTableView und numberOfRowsInSection. Aber Ihre Daten-Quelle, seit es existiert, in einem anderen thread, verändern kann.
- Nur um klar zu sein, die gefundenen Ergebnisse-controller delegieren, ist irrelevant. Wenn die UITableView ausführt, deren setup-code in Reaktion auf reloadData und ruft numberOfSectionsInTableView und numberOfRowsInSection gegen Ihre Datenquelle ein, es gibt keine Möglichkeit, Sie können eine beliebige andere code ausführen zwischen. Überprüfen können Sie dies selbst, indem Sie breakpointing durch.
- Folgenden, bis auf diese, ich habe geprüft, die in ein test-Projekt, dass diese Methode ist definitiv nicht thread-safe: wenn reloadData wird aufgerufen, auf dem Haupt-thread und dem privaten Umfeld ist gleichzeitig geändert in einen hintergrund-thread, dadurch entsteht eine race condition, wo die UITableView und NSFetchedResultsController bekommen kann out of sync, die manifestiert sich als die UITableView beantragt, ein Abschnitt oder index-Pfad, der nicht mehr existiert. (Im Grunde machen die privaten Kontext kontinuierlich einfügen/entfernen von Objekten und rufen Sie dann reloadData im Haupt-thread. Es wird brechen.)
- Dies funktioniert nicht für mich. Ich sehe immer noch alle frc-Daten liest, was auf dem Haupt-thread (logging-Objekt-Fehler). Jemand in der Lage, um zu sehen, anders mit core data logging?
- Das ist wirklich schwer zu implementieren ist, alle tableview delegate-Methoden Zugang zu den verwalteten Objekt-Eigenschaft in gewisser Weise, es kann zu seltsamen Verhalten in der Benutzeroberfläche.
InformationsquelleAutor quellish
0

Können Sie gehen durch diese sehr schön post auf Kern-Daten, die mit Multi-Threading Verhalten.

Hoffe es hilft..!!

InformationsquelleAutor Suny

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.