5

Setup: UITableView mit FRC. Zeilen sind eine einfache Liste von Textinhalten, die der Benutzer abrufen kann, um das Neueste zu erhalten.NSFetchedResultsController (und UITableView) Delegieren Methodenaufrufe wachsenden und wachsenden

Ich sehe seltsames Verhalten, wo CellForRow für jede Zeile mehrmals aufgerufen wird. Also sehe ich es für 0,0 0,1 0,2 0,3 (sichtbare Zeilen), aber diese 4 Zeilen haben alle cellForRow mehrfach aufgerufen. Beim ersten Aufruf der Liste werden sie jedoch einmal aufgerufen. Das zweite Mal, zweimal usw. Zum siebten Mal, nachdem der Benutzer den Inhalt gesehen hat, versucht er hinter den Kulissen die Zelle immer wieder zu konfigurieren und stürzt schließlich ab.

Also, wenn Sie zu einer Liste von Inhalten gehen, es trifft den Server, lädt die Geschichten, erstellt NSMOs und zeigt an. In den Protokollen sehe ich configureCell für jede sichtbare Zeile einmal aufgerufen. Wenn ich mich aktualisiere, sehe ich das Gleiche. ABER wenn ich zu einem anderen Bildschirm navigiere, dann komm zurück, wenn ich zum Aktualisieren ziehe merke ich, dass Cellforrow für jede Zeile zweimal aufgerufen wird. Wenn ich diesen Prozess des Verlassens und Zurückkommens fortsetze, wird Cellforrow jedes Mal, wenn ich es tue, eine zusätzliche Zeit genannt. Wenn ich einige der abgerufenen Controller-Delegiertenmethoden protokolliere, sehe ich den Änderungsinhalt vor jedem Satz von Cellforrow-Aufrufen. Kann mir jemand helfen herauszufinden, warum meine Cellforrow-Methode immer häufiger genannt wird?

Eine Idee war die Art, wie ich FRC eingerichtet habe. Ich folgte Code wie CoreDataBooks und bewegte die Dinge zu viewdidload, sah aber immer noch Probleme.

Ich habe eine Eigenschaft in der .h und in der .m hat, was ich dachte, war ein Standard-Setup:

- (NSFetchedResultsController *)fetchedResultsController 
{ 
//NSLog(@"fetchedresulscontroller"); 
if (_fetchedResultsController != nil) 
{ 
    return _fetchedResultsController; 
} 

// initialize fetch request. setup predicate, sort, etc. 

NSFetchedResultsController *aFetchedResultsController = [[NSFetchedResultsController alloc] initWithFetchRequest:fetchRequest managedObjectContext:self.managedObjectContext sectionNameKeyPath:@"date" cacheName:nil]; 

aFetchedResultsController.delegate = self; 
self.fetchedResultsController = aFetchedResultsController; 

// perform actual fetch. delegate methods take it from here 
NSError *fetchError = nil; 
if (![self.fetchedResultsController performFetch:&fetchError]) 
{ 
    // 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 %@, %@", fetchError, [fetchError userInfo]); 
    abort(); 
} 

return _fetchedResultsController; 
} 
+0

Ich vermute, dass es etwas mit dem zu tun haben, wenn Sie Ihren 'NSFetchedResultsController' laufen? Mit welcher TVC-Lebenszyklus-Methode? – andrewbuilder

+0

Haben Sie also eine lokale Variable, die den FRC im Speicher hält? Auch wann setzen Sie den FRC - das heißt - welcher Teil Ihres Codes tritt auf? – andrewbuilder

+0

Ich habe eine Eigenschaft und dann setzen Sie die FRC in - (NSFetchedResultsController *) abgeholtResultsController, die oben veröffentlicht. Vielen Dank! – skinsfan00atg

Antwort

3

andrewbuilder auf dem richtigen Weg war. Alles hatte mit der FRC zu tun, aber der Trick war die SWReveal-Bibliothek von Drittanbietern, die für das Menü verwendet wurde. Es stellte sich heraus, dass ich jedes Mal eine neue VC erstellte (vorher wurde die Zuweisung nicht aufgehoben) und der FRC betrachtete alle Live-View-Controller. Jedes Mal, wenn ich auf eine Auswahl aus dem Menü tippte, wurde eine weitere hinzugefügt, und die Konfigurationsaufrufe wurden dafür aufgerufen.

Die Lösung ist auf Null aus der FRC Delegierten in viewwilldisappear und legen Sie es in ViewWillAppear

Verwandte Themen