Is Apple's iPhone SDK 3.0 CoreDataBooks example broken?

Question

I've come across this issue in my application, and have reproduced it using Apple's CoreDataBooks codebase with 0 modifications to the code. The problem is if you make an edit to a managed object, and save the context, with the result being a section with only one row now having no rows, and a new section created with the resulting object added to it, then you get the invalid update exception. It also seems to depend on the ordering of the rows.

To recreate follow these steps:

1. Open a new instance of CoreDataBooks example
2. Edit Richard Dawkins book, "The Selfish Gene" and change the author to Ben. Save it. If you return to the main view you'll notice that the book is under a new section named Ben.

3. Edit this book again, and change the author to Doug. Save it. You'll get the following exception:

   2009-10-01 15:14:29.050 CoreDataBooks[10898:20b] *** Assertion failure in -[UITableView_endCellAnimationsWithContext:], /SourceCache/UIKit/UIKit-963.10/UITableView.m:729 2009-10-01 15:14:29.051 CoreDataBooks[10898:20b] Serious application error.  Exception was caught during Core Data change processing: Invalid update: invalid number of rows in section 1.  The number of rows contained in an existing section after the update (2) must be equal to the number of rows contained in that section before the update (2), plus or minus the number of rows inserted or deleted from that section (0 inserted, 0 deleted). with userInfo (null)
   

I'd post the code from my own app to make sure I'm not missing any required delegate methods, except as the example above shows it's an issue which affects Apple's CoreDataBooks example straight off the shelf. The NSFetchedResultsController delegate methods are all implemented as per their own examples. Their code doesn't seem to forget to handle newly created sections either, as it works in other cases with different section orderings.

Any help would be appreciated. Example modified code from the CoreDataBooks example would be great.

Answer 1

One recommendation is that you completely delete the application from your iPhone and/or reset the Simulator, to ensure that you don't have any remnants of a corrupted data store.

After you delete the app or reset the Simulator, recompile this app from scratch. This will create a fresh copy of the application and, more importantly, a fresh data store.

Re-run your test after doing that, to see if you run into the same problem.

Answer 2

The way to fix this seems to be to change these lines in the table updates section of the RootViewController:

    case NSFetchedResultsChangeMove:
  [tableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath] withRowAnimation:UITableViewRowAnimationFade];

  // Reloading the section inserts a new row and ensures that titles are updated appropriately.
  [tableView reloadSections:[NSIndexSet indexSetWithIndex:newIndexPath.section] withRowAnimation:UITableViewRowAnimationFade];
   break;

to:

         case NSFetchedResultsChangeMove:
      [tableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath] withRowAnimation:UITableViewRowAnimationFade];
      [tableView insertRowsAtIndexPaths:[NSArray arrayWithObject:newIndexPath] withRowAnimation:UITableViewRowAnimationFade];
      break;

for some reason. The problem seems to come from deleting the last row in a section; it appears that unless you add the extra insertRows, the UITableView freaks out over the fact that the section which has been deleted suddenly gains a whole bunch of extra rows.

Took me hours to figure that one out....