iOS8 Swift: deleteRowsAtIndexPaths crashes

Question

I am having some trouble with deleting a row from my tableView in Swift, iOS 8, Xcode 6 Beta 6. Every time I try to delete a row I get an error along the lines of

Assertion failure in -[UITableView _endCellAnimationsWithContext:], /SourceCache/UIKit_Sim/UIKit-3302.3.1/UITableView.m:1581 2014-08-30 20:31:00.971 Class Directory[13290:3241692] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid update: invalid number of rows in section 1. The number of rows contained in an existing section after the update (25) must be equal to the number of rows contained in that section before the update (25), plus or minus the number of rows inserted or deleted from that section (0 inserted, 1 deleted) and plus or minus the number of rows moved into or out of that section (0 moved in, 0 moved out).

I have read all the answers to this frequent problem, here, and feel I have fulfilled the conditions recommended. The item seems to be removed from the data model -- when I reload the app, the deleted item is gone from the table -- but there seem to be some remnants in the appropriate sqlite file and of course the math doesn't add up. The println that spits out the indexPath shows the correct Section and Row. I'm very puzzled. This should be straightforward but I am missing something dumb I am sure, I suspect in the data model deletion. Full project on Github.

func numberOfSectionsInTableView(tableView: UITableView!) -> Int {

    return fetchedResultController.sections.count

}


func tableView(tableView: UITableView!, numberOfRowsInSection section: Int) -> Int {
    return fetchedResultController.sections[section].numberOfObjects

    }

func tableView(tableView: UITableView!, cellForRowAtIndexPath indexPath: NSIndexPath!) -> UITableViewCell! {
    let cell = tableViewMain.dequeueReusableCellWithIdentifier("CellMain", forIndexPath: indexPath) as UITableViewCell

        let personForRow = fetchedResultController.objectAtIndexPath(indexPath) as Person
        cell.textLabel.text = personForRow.fullName()

        return cell

}

func tableView(tableView: UITableView!, canEditRowAtIndexPath indexPath: NSIndexPath!) -> Bool {
    return true
}

func tableView(tableView: UITableView!, editingStyleForRowAtIndexPath indexPath: NSIndexPath!) -> UITableViewCellEditingStyle {
    return UITableViewCellEditingStyle.Delete
}

 func tableView(tableView: UITableView!, commitEditingStyle editingStyle: UITableViewCellEditingStyle, forRowAtIndexPath indexPath: NSIndexPath!) {
    println("section and row \(indexPath.section) \(indexPath.row) ")
    if (editingStyle == UITableViewCellEditingStyle.Delete) {
    let personForRow : NSManagedObject = fetchedResultController.objectAtIndexPath(indexPath) as Person
    context?.deleteObject(personForRow)
    context?.save(nil)
        tableViewMain.beginUpdates()
    tableViewMain.deleteRowsAtIndexPaths([indexPath], withRowAnimation: UITableViewRowAnimation.Fade)
        tableViewMain.endUpdates()
    }

possible duplicate of [crash on deleteRowsAtIndexPaths](http://stackoverflow.com/questions/4186251/crash-on-deleterowsatindexpaths) — durron597, Aug 11 '15 at 02:44

Imanou Petit · Accepted Answer · 2014-08-31T06:44:30.810

It's easy to reproduce your crash with a Xcode Core Data Master-Detail template project. As a general rule, when you use NSFetchedResultsController, you should really use NSFetchedResultsControllerDelegate (you have declared it but don't use it).

Delete those lines in your tableView:commitEditingStyle:forRowAtIndexPath: method:

tableViewMain.beginUpdates()
tableViewMain!.deleteRowsAtIndexPaths([indexPath!], withRowAnimation: UITableViewRowAnimation.Fade)
tableViewMain.endUpdates()

And add those lines to your viewController class:

func controllerWillChangeContent(controller: NSFetchedResultsController) {
    tableViewMain.beginUpdates()
}

func controller(controller: NSFetchedResultsController!, didChangeSection sectionInfo: NSFetchedResultsSectionInfo!, atIndex sectionIndex: Int, forChangeType type: NSFetchedResultsChangeType) {
    switch type {
    case .Insert:
        tableViewMain.insertSections(NSIndexSet(index: sectionIndex), withRowAnimation: .Fade)
    case .Delete:
        tableViewMain.deleteSections(NSIndexSet(index: sectionIndex), withRowAnimation: .Fade)
    default:
        return
    }
}

func controller(controller: NSFetchedResultsController!, didChangeObject anObject: AnyObject!, atIndexPath indexPath: NSIndexPath!, forChangeType type: NSFetchedResultsChangeType, newIndexPath: NSIndexPath!) {
    switch type {
    case .Insert:
        tableViewMain.insertRowsAtIndexPaths([newIndexPath], withRowAnimation: .Fade)
    case .Delete:
        tableViewMain.deleteRowsAtIndexPaths([indexPath], withRowAnimation: .Fade)
    case .Update:
        return
        //Should also manage this case!!!
        //self.configureCell(tableView.cellForRowAtIndexPath(indexPath), atIndexPath: indexPath)
    case .Move:
        tableViewMain.deleteRowsAtIndexPaths([indexPath], withRowAnimation: .Fade)
        tableViewMain.insertRowsAtIndexPaths([newIndexPath], withRowAnimation: .Fade)
    default:
        return
    }
}

func controllerDidChangeContent(controller: NSFetchedResultsController!) {
    tableViewMain.endUpdates()
}

This should fix your problem.

thank you for the detailed response. Xcode is giving me an error with this code. By having both func controller(controller: NSFetchedResultsController!, didChangeSection and func controller(controller: NSFetchedResultsController!, didChangeObject it gives the error "Definition conflicts with previous value" on the second controller function. If I comment out the first, the error disappears. Any thoughts? — Nate Birkholz, Aug 31 '14 at 06:53
Ugh, it's late and I pasted the code into the middle of the commitEditingStyle function instead of at the root of the viewController class. That worked perfectly. Much obliged. — Nate Birkholz, Aug 31 '14 at 07:06
This wasn't exactly my issue. The problem with my code was that tableView number of rows function wasn't updating its count after deletion of the row. This post hinted me towards having a look at that piece of my code. Thank you! — Axe, Jul 16 '16 at 23:28

drewag · Answer 2 · 2014-08-31T06:29:18.313

3

I believe this is simply a caching problem. Your fetchedResultController is not going to automatically refetch your results as it caches its results. That means that when tableView:numberOfRowsInSection: is called again, the results count is still returning 25 even though you deleted an item.

edited Aug 31 '14 at 06:29

answered Aug 31 '14 at 06:19

drewag

93,393
28
139
128

1

@NateBirkholz it is calling `tableView:numberOfRowsInSection` internally in the `deleteRowsAtIndexPaths`. That is how it is printing out the error message in the first place, but more importantly, that is how it verifies that the rows you are trying to add/remove are truly removed from the data. – drewag Aug 31 '14 at 06:29
Yep, that's where it's dying... Any ideas on specifics of a resolution? (My initial response was incorrect, I added more debug logging and you were correct, sorry for the error on my part.) – Nate Birkholz Aug 31 '14 at 06:37
1

@NateBirkholz, there may be a way to force `fetchedResultsController` to throw out its cache. However, if it were me, I would store the results in a temporary array member and use that for the data source instead. That way, you can manage the array (remove the element) yourself and not worry about the implementation details of the `fetchedResults` – drewag Aug 31 '14 at 06:39
It used to load into an array, but I was having a lot of problems and my instructor recommended acting directly on the data model. I'll dig around a bit more with this insight. Thank you. – Nate Birkholz Aug 31 '14 at 06:41
1

@NateBirkholz, I would recommend the extra abstraction which will make it is easier to change your app to using a different data source if necessary. Perhaps you will want to add dropbox support or some other syncing service in the future. It is normally a good idea to have an abstraction layer between your controllers and the way that you are actually storing the information. – drewag Aug 31 '14 at 06:43
I'll do that after I finish the project, that sounds like a good learning experience. Thank you very much for the advice. I thought the abstraction was a good idea, too, initially. – Nate Birkholz Aug 31 '14 at 07:08

iOS8 Swift: deleteRowsAtIndexPaths crashes

2 Answers2

Linked