2010-10-19 3 views
7

Ich postete dies auf den Apple Dev Foren hier, da es sich mir wie ein Bug im eigentlichen SDK anfühlt, aber ich dachte, ich würde es hier auch posten und sehen, ob irgendjemand könnte überprüfen, ob ich dieses Ding falsch benutze oder nicht (scheint nicht so) oder das ist ein gebrochenes Verhalten.NSFetchedResultsSectionInfo stimmt nicht mit sich selbst überein, wie viele Objekte es hat

https://devforums.apple.com/thread/72738

-

Nach einem wenig zu verbringen, während einiger Code debuggen, habe ich ein sehr seltsames und beunruhigendes Verhalten einer Instanz NSFetchedResultsSectionInfo entdeckt.

NSFetchedResultsController *frc = [self frcForTableView:tableView]; 

id <NSFetchedResultsSectionInfo> sectionInfo = [[frc sections] objectAtIndex: 
               [indexPath indexAtPosition:1]]; 

NSLog(@"Looking at %@ with section %@ (%d objects)", 
     indexPath, [sectionInfo objects], [sectionInfo numberOfObjects]); 

Grundsätzlich packe ich einen FRC, dann ziehen Sie eine der sectionInfo aus ihm Objekte (dagegen tun sich keine Sorgen, warum ich für den Index Wegposition bin Grabbing 1 statt 0 ... es sollte nicht Materie hier). Das Interessante daran ist, dass die NSLog Ausgabe für die darüber ist:

Looking at <NSIndexPath 0x8828ee0> 2 indexes [0, 0] with section (
    "TBN.B x 1 for order 1187", 
    "TBN.T x 1 for order 1187" 
) (1 objects)` 

So ist die [sectionInfo objects] Array hat zwei Dinge drin, aber [sectionInfo numberOfObjects] berichtet, dass es nur eine hat. Um die Möglichkeit eines Caching-Problems auszuschließen, habe ich vor der Ausführung dieses Codes das gesamte Caching im FRC-Setup deaktiviert.

Ziemlich ratlos hier. Ich weiß nicht, wie ein einzelnes sectionInfo-Objekt mit sich selbst widersprechen kann, wie viele Objekte es enthält.

Irgendwelche Ideen von den Apple Entwicklern? Ausführen von XCode 3.2.4 und dem 4.1 SDK.

Edit: FYI das richtige Objekt für diesen Abschnitt ist eigentlich die erste (TBN.B) so in meinen Tests so weit scheint es, dass, wenn Sie nur den Teil des Arrays Objekte betrachten bis zu numberOfObjects dann Sie bekommen die richtigen Ergebnisse. Trotzdem neugierig, warum das Extra-Objekt am Ende des Arrays erscheint, wenn es nicht Teil dieses Bereichs ist.

+0

Das könnte ich mit dem Thema in Beziehung gesetzt werden: http://stackoverflow.com/questions/10619750/nsfetchedresultscontroller-trying-to-limit-number-of-records-displayed einen Link sehen? – trapper

Antwort

0

Meine Tests haben gezeigt, dass das Array "objects" des ersten Abschnitts immer alle Objekte im Controller enthält. Ich denke das ist ein Framework Bug.

Das ist eine wirklich schmutzig (und langsam) Abhilfe:

NSArray * allObjects = self.cachedFetchedResultsController.fetchedObjects; 
NSMutableArray * objectsInSectionZero = [NSMutableArray array]; 
for (id obj in allObjects) { 
    if ([[self.cachedFetchedResultsController indexPathForObject:obj] section] == indexPath.section) { 
     [objectsInSectionZero addObject:obj]; 
    } 
} 
1

Hier sind 5 1/2 Jahre nach der Frage ursprünglich gefragt wurde. Wir sind auf Xcode 7.x und der Bug scheint immer noch hier zu sein. Hat jemand herausgefunden, warum das passiert? Die Lösung, die ich gefunden habe, besteht darin, einfach nach dieser Bedingung in controllerDiDChangeContent zu suchen und, wenn sie existiert, den FRC neu zu erstellen. Für mich ist es in Ordnung, da dies nur passiert, wenn Sie mit 0 Abschnitten beginnen und eine zweite darunter hinzufügen. Hier ist eine sehr gute Beschreibung, wie man diesen Fehler neu erstellt. Ich schätze nicht, dass viele Leute Summen in ihre Fußzeilen setzen.

https://devforums.apple.com/message/328077#328077