I’m using an NSFetchedResultsController and NSFetchedResultsControllerDelegate to drive a UITableViewController/UITableView. A button click triggers the deletion of an NSManagedObject via [managedObjectContext deleteObject:aManagedObject].
The NSFetchedResultsControllerDelegate methods fire properly and the row is deleted from the UITableView.
Here’s where things get weird. When I call [managedObjectContext save:&error] the NSFetchedResultsControllerDelegate method controller:didChangeObject:atIndexPath:forChangeType:newIndexPath: is called with the deleted NSManagedObject as the object (and isDeleted is YES on the managed object) and the change type is NSFetchedResultsChangeInsert which adds the deleted NSManagedObject back to the UITableView.
I’ve attempted to suppress the insert by checking the isDeleted flag in the delegate method but this causes the beginUpdates and endUpdates assertions to fail.
Am I doing something wrong or out of order? Did I miss a step somewhere?
Facing an exactly issue as yours I could realize that only a single reference to a deleted object by another object or context will keep it alive as a fault until the reference is removed. If the application try to access that deleted object again, it will crash. A single reference may be the reason why the deleted object is reappearing.
Into my case, releasing a UIViewController instance reference to the object which are going to be deleted before calling the asynchronously deletion operation fixed this issue.
Ignoring the
Release all references to the objectpart would make the object reappears asisDeletedafter being deleted into aNSFetchedResultsControllerobserver instance.