blindingskies / bsfetchedresultscontroller Goto Github PK

There seems to be a bit of a bug during the change notification when lots of changes occur which impact the sort ordering of the sections/rows.

Single, isolated, changes don't seem to cause a problem, at least for trivial objects and block functions. It could be that if the block functions are too complex, in the sense that they query the object graph too heavily, then we have problems.

Need to add some UIAutomation to the Demo application to more throughly test this.

If you have a predicate that has results but a postFetchFilterTest that removes them all, and then save a new managed object that does match the filter test, it crashes. It appears to be an issue with how the sections handle no objects, possibly the sorted section logic, it ends up calling didChangeSection with an NSNotFound sectionIndex.

WiFiFoFum-Passwords[29459:8411491] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[__NSArrayI objectAtIndex:]: index 9223372036854775807 beyond bounds for empty array'
*** First throw call stack:
(
    0   CoreFoundation                      0x000000010dc57c65 __exceptionPreprocess + 165
    1   libobjc.A.dylib                     0x000000010d262bb7 objc_exception_throw + 45
    2   CoreFoundation                      0x000000010db4e17e -[__NSArrayI objectAtIndex:] + 190
    3   WiFiFoFum-Passwords                 0x000000010cc66d13 -[BSFetchedResultsController updateObjects:] + 1571
    4   WiFiFoFum-Passwords                 0x000000010cc63f04 __58-[BSFetchedResultsController registerNotificationHandlers]_block_invoke + 772
    5   Foundation                          0x000000010cdd53b1 -[__NSObserver _doit:] + 291
    6   CoreFoundation                      0x000000010dc2754c __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12
    7   CoreFoundation                      0x000000010db25a04 _CFXNotificationPost + 2484
    8   Foundation                          0x000000010cdb8968 -[NSNotificationCenter postNotificationName:object:userInfo:] + 66
    9   CoreData                            0x000000010d55babe -[NSManagedObjectContext(_NSInternalChangeProcessing) _createAndPostChangeNotification:withDeletions:withUpdates:withRefreshes:] + 334
    10  CoreData                            0x000000010d4ca791 -[NSManagedObjectContext(_NSInternalChangeProcessing) _processRecentChanges:] + 2897
    11  CoreData                            0x000000010d4ce0f3 -[NSManagedObjectContext save:] + 131

I had a crash with it trying to call the delegate after it has been dealloced because the view using the controller was long gone, then I discovered the controller was still alive using Instruments. I believe the problem is the block inside registerNotificationHandlers causes a retain cycle to "self". If I comment out the call to registerNotificationHandlers then the controller is dealloced as normal. I'm using the class in an ARC project but with this file flagged as non-ARC.

Doesn't support rollback:
There is a strange bug in the rollback notifications that deleted objects are notified twice causing an error because on the second notification the index of the existing object isn't found, and then it assumes it's trying to insert a new object so uses an index path one higher than the highest, which crashes the table. The underlying issue was actually my first question on stack overflow and theres been two very interesting replies but no reason known yet. The work around is to check if objects are already deleted in the notification so that would be the fix for this.

Changing the fetchRequest predicate doesn't clear out the previously fetched objects:
With NSFetchedResultsController when you change the predicate and then get the fetched objects there are zero, however this controller doesn't have this behaviour. I suppose a work around would be to change the entire fetch request, as I read a comment that was possible with this class but I didn't try it.

Well I've finally given up on using this class. I've subclassed NSFetchedResultsController myself and added the the postFetchComparator I was after. It was actually very simple to do, just had to trick it into using a mutable array for the section objects and that could be sorted. Should have taken your advice sooner ha!