views:

24

answers:

0

I posted this on the Apple dev forums here since it feels to me like a bug in the actual SDK, but I thought I'd post it here as well and see if anyone could verify whether or not I'm using this thing incorrectly (doesn't seem like it) or this is broken behaviour.

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

--

After spending a little while debugging some code, I have discovered a very strange and worrying behaviour of an instance of 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] );

Basically, I grab a FRC, then pull one of the sectionInfo objects out of it (don't worry about why I'm grabbing for index path position 1 rather than 0 ... it shouldn't matter here). The interesting thing is that the NSLog output for the above is this:

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 only has one. To eliminate the possibility of a caching issue I disabled all caching in the FRC setup prior to running this code.

Pretty stumped here. Don't know how a single sectionInfo object can disagree with itself about how many objects it has in it.

Any ideas from the Apple devs? Running XCode 3.2.4 and the 4.1 SDK.

Edit: FYI the correct object for this section is actually the first one (TBN.B) so in my testing so far it appears that if you only consider the portion of the objects array up to numberOfObjects then you get the right results. Nevertheless, still curious as to why the extra object appears at the end of the array when it isn't part of that section.