I have a UITableView which is configured to allow rows to be moved between sections when in editing mode. The table is backed using NSFetchedResultsController
It’s hard to describe the problem that I’m seeing, but essentially:
1) The users start to drag a row
2) The other rows move out of it’s way as it’s dragged around the table
3) The user releases the touch and I respond to the moveRowAtIndexPath: callback (code
below) by updating the ManagedObject appropriately
4) Now, for some reasons the other rows animate back to where they were before the user started dragging. That is, the all move up or down one row to where they were before, rather than staying in their new position.
Some time later, generally between 0.5 seconds and 3 seconds, the NSFetchResultsController decides to ask me to update the moved cell. At this point I end up calling [table beginUpdates] and [table endUpdates] and the rows move to where they should do.
Now, the late callback from NSFetchResultsController is an oddity but that does seem to matter. What matters is that the UITableView doesn’t leave the rows in the new location and the begin/end updates call is required to put the rows where they should be. Should I be doing something else in this callback:
- (void)tableView:(UITableView *)tableView moveRowAtIndexPath:(NSIndexPath *)fromIndexPath toIndexPath:(NSIndexPath *)toIndexPath
{
NSLog(@"UI is moving row from [%d, %d] to [%d, %d]", fromIndexPath.section, fromIndexPath.row, toIndexPath.section, toIndexPath.row);
self.inManualReorder = YES;
// Here I update the underlying object, code is not relevant as this works.
...
// I've tried saving the context here and delaying it untill later on. It doesn't affect
// the behavior in question.
NSError *error = nil;
if (![self.managedObjectContext save:&error]) {
// Replace this implementation with code to handle the error appropriately.
// abort() causes the application to generate a crash log and terminate. You should not use this function in a shipping application, although it may be useful during development.
NSLog(@"Unresolved error %@, %@", error, [error userInfo]);
abort();
}
self.inManualReorder = NO;
NSLog(@"UI finished moving row");
}
I’ve found it.
In the call backs to controllerWill(Did)ChangeContent I was calling begin(end)Updates. I shouldn’t do that if the reordering comes from a manual intervention:
I was checking this flag for the didChangeObject: callback, but not for these…