NSFetchedResultsSectionInfo does not agree on how many objects it has

I posted this on the Apple dev forums here, as it feels to me like an error in the actual SDK, but I thought I would post it too and see if anyone could check if I was using it (not like this ) or this is a violation of behavior.

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

-

After spending some time debugging some code, I found a very strange and disturbing behavior of the NSFetchedResultsSectionInfo instance.

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

Basically, I take FRC and then pull one of the sectionInfo objects out of it (don't worry about why I grab the position of index position 1 and not 0 ... it doesn't matter here). Interestingly, the NSLog output for the above is as follows:

 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, the [sectionInfo objects] array has two things in it, but [sectionInfo numberOfObjects] reports that it has only one. To eliminate the possibility of caching, I turned off all caching in the FRC setting before running this code.

Pretty here. I don’t know how one sectionInfo object can disagree with itself about how many objects it has in it.

Any ideas from Apple developers? Launch Xcode 3.2.4 and 4.1 SDK.

Edit: FYI the correct object for this section is actually the first (TBN.B), so in my testing so far it shows that if you consider only part of the array of objects before numberOfObjects , then you will get the correct results. However, it is still curious why the extra object appears at the end of the array when it is not part of this section.

+7
iphone nsfetchedresultscontroller
source share
2 answers

Here 5 years after the question was originally asked. We are on Xcode 7.x, and the error seems to be still here. Has anyone understood why this is happening. The solution I came up with is just to check this condition in the DiDChangeContent controller, and if it exists, recreate the FRC. This is normal for me, as it only happens when you start from 0 sections and add a second under it. Here is a very good entry on how to recreate this error. I think not many people invest totals in their footers.

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

+1
source share

My tests showed that the array of "objects" of the first section always contains all the objects in the controller. I think this is a structure error.

This is a really dirty (and slow) workaround:

 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]; } } 
0
source share

All Articles