2010-10-19 11 views
7

Umieściłem to na forach od Apple'a, ponieważ uważałem, że to błąd w prawdziwym SDK, ale pomyślałem, że też go tu zamieszczę i zobaczę, czy ktoś mogę sprawdzić, czy używam tego czegoś niepoprawnie (nie wygląda na to), czy to jest zepsute zachowanie.NSFetchedResultsSectionInfo nie zgadza się z ilością obiektów, które ma

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

-

Po spędzeniu trochę podczas debugowania kodu, odkryłem bardzo dziwne i niepokojące zachowanie instancji NSFetchedResultsSectionInfo.

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]); 

Zasadniczo chwycić FRC, a następnie wyciągnąć jeden z sectionInfo obiektów z nim (nie martw się o tym, dlaczego jestem chwytając za wskaźnik położenia toru 1 zamiast 0 ... nie powinno tutaj sprawa). Interesującą rzeczą jest to, że wyjście NSLog dla powyższego jest taka:

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)` 

Więc tablica [sectionInfo objects] ma dwie rzeczy, ale [sectionInfo numberOfObjects] informuje, że tylko jeden. Aby wyeliminować możliwość wystąpienia problemu z buforowaniem, wyłączałem całe buforowanie w konfiguracji FRC przed uruchomieniem tego kodu.

Dość zakłopotany tutaj. Nie wiem, w jaki sposób pojedynczy obiekt sectionInfo może się nie zgadzać z tym, ile obiektów ma w nim.

Jakieś pomysły od twórców Apple'a? Uruchomienie XCode 3.2.4 i 4.1 SDK.

Edit: FYI prawidłowa obiektu dla tej sekcji jest rzeczywiście pierwsza (TBN.B), więc w moich testów do tej pory wydaje się, że jeśli brać pod uwagę tylko część tablicy obiektów do numberOfObjects następnie dostać odpowiednie wyniki. Niemniej jednak, wciąż ciekawy, dlaczego dodatkowy obiekt pojawia się na końcu tablicy, gdy nie jest częścią tej sekcji.

+0

Może to być związane z emisją miałem: http://stackoverflow.com/questions/10619750/nsfetchedresultscontroller-trying-to-limit-number-of-records-displayed zobaczysz link? – trapper

Odpowiedz

0

Moje testy wykazały, że tablica "obiektów" pierwszej sekcji zawsze zawiera wszystkie obiekty w kontrolerze. Myślę, że to błąd w strukturze.

Ów naprawdę brudne (i powolny) Obejście:

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

tutaj jest 5 pół roku po pierwotnie zadawane pytanie. Jesteśmy na Xcode 7.x i błąd nadal tu jest. Czy ktoś się domyślił, dlaczego tak się dzieje? Rozwiązaniem, które wymyśliłem, jest po prostu sprawdzenie tego warunku w controlDiDChangeContent i jeśli istnieje, odtworzenie FRC. Dla mnie jest ok, ponieważ dzieje się tak tylko wtedy, gdy zaczynasz od 0 sekcji i dodajesz drugą pod nią. Oto bardzo dobry zapis, jak odtworzyć ten błąd. Chyba nie, że wielu ludzi umieszcza sumy w swoich stopkach.

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