UITableView deleteRowsAtIndexPaths not working

Question

I'm not quite sure what's going on here but I'm running into a contact form that I'm working with. In my form I've added the ability to add an email address to a contact. As pictured below, once the user clicks on "add email", a row is added to the "Emails" section.

Create contact image

However after I click to delete the email, an extra cell appears underneath the add email button (pictured below).

before and after

There's a little red box from what appears to be the prior delete cell as though the table isn't reloaded. Here's my delete code:

- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath
{
    if( editingStyle == UITableViewCellEditingStyleDelete )
    {
        // Update the data source
        NSMutableArray *fields = (NSMutableArray *)self.fields[@(indexPath.section)];
        [fields removeObjectAtIndex:indexPath.row];
        NSMutableArray *values = (NSMutableArray *)self.values[@([self fieldTypeAtIndexPath:indexPath])];
        [values removeObjectAtIndex:indexPath.row];

        [tableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath] withRowAnimation:UITableViewRowAnimationMiddle];
    }
}

So why is that cell remaining afterwards? I can call [tableView reloadData] within the method above and it removes the excess cell but then it messes up the animation. Can you shed some clarity on what I'm doing wrong here?

score 1 · Answer 1 · answered Feb 11 '14 at 00:29

This looks like a bug.

I just noticed that even Apple has this same bug in their Reminders app. It seems to be related to deleting rows from a UITableView with variable height items.

In Apple's Reminders app, when you delete something from a long list with variable height items, you will see the same exact visual artifact for a split second. Then the table jumps and the list looks correct. I am assuming Apple just reloads the entire table view a second after the item is removed in order to fix the visual glitch.

My recommendation is to report this as a bug to Apple. For now you can reload the entire table view like Apple presumably does.

I'm having the exact same issue. Even when I reload, the deleted cell gets dequeued and shows up in its delete state (Delete is visible). — Armin, Apr 17 '14 at 17:34

score 0 · Answer 2 · edited May 23 '17 at 12:28

0

Option 1: Before you call deleteRowsAtIndexPaths, you must make sure that numberOfRowsInSection will return the correct value (e.g. if you originally had 2 rows in that section, it should now return 1 row).

Option 2: If that isn't the problem, I would try a different animation type (e.g. UITableViewRowAnimationAutomatic), just to see if that has any effect.

Option 3: Ensure that cellForRowAtIndexPath is returning a valid cell with its contents being reset. Otherwise it may be reusing an invalid cell or displaying something that was there before.

Option 4: Since the heights are different, ensure that heightForRowAtIndexPath is returning the correct value. You probably need to call reloadRowsAtIndexPaths in order for the table view to know about the height difference.

edited May 23 '17 at 12:28

Community

1
1

answered Dec 27 '13 at 00:06

Senseful

86,719
67
308
465

It does return the correct number. And I believe you mean `numberOfRowsInSection`... – Nick ONeill Dec 27 '13 at 00:06
@NickONeill: Did you try a different animation type? such as automatic? – Senseful Dec 27 '13 at 00:08
So the numberOfRowsInSection is correct. Trying your other question – Nick ONeill Dec 27 '13 at 00:14
Tried your animation theory with no success. This isn't the problem. – Nick ONeill Dec 27 '13 at 00:15
The cell itself is valid. The height of the two rows is slightly different (3 pixels different) which is why the cell is showing underneath. However what's odd is that the old cell is still displaying. – Nick ONeill Dec 27 '13 at 00:18
@NickONeill: Is heightForRowAtIndexPath returning the correct value? – Senseful Dec 27 '13 at 00:19
let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/43954/discussion-between-nick-oneill-and-senseful) – Nick ONeill Dec 27 '13 at 00:21

score 0 · Answer 3 · answered Feb 27 '14 at 09:10

0

I had the same problem and I guess it might be a bug in iOS7 where it doesn't repaint the cells correctly, I fixed it but not in an efficient way, just in the "cellForRowAtIndexPath" , always create a new cell, don't dequeue it.

answered Feb 27 '14 at 09:10

Christopher Nassar

545
3
24

UITableView deleteRowsAtIndexPaths not working

3 Answers3