How to animate UITableView rows when IndexPathsForVisibleRows[0] is moved or removed

0
votes

I am experimenting with the UITableView, but animations are not occurring as I would expect.

Given a list of cells, I want to delete the top-most cell (the item at IndexPathsForVisibleRows[0]), and have all the rows beneath it, animate upwards into their new position. However, it appears that any time IndexPathsForVisibleRows[0] (or any invisible cell ABOVE the first visible one for that matter) is touched (moved, deleted, etc), the UITableView refuses to animate the results of the transaction.

I have included 2 gifs to demonstrate the issue.

The first GIF demonstrates the desired behavior. I am removing the cell at IndexPathsForVisibleRows[1] (the second on-screen cell). Notice how all cells below animate correctly into position.

Correct animation behavior

The second GIF demonstrates what happens when removing the top-most cell (IndexPathsForVisibleRows[0]). Note how all the cells below move immediately into the new position, without animation.

enter image description here

(note: the entire table change is wrapped in a BeginUpdates/EndUpdates block).

Am I missing something which causes the 2 scenarios to behave differently, or I have I just stumbled upon a UITableView bug/limitation?

1
iosuitableview
beginUpdates/endUpdates is overestimated. It's only required for multiple simultaneous insert/delete/move operations. The appearance depends on the methods you use. reload... does not animate the view, deleteRows... does when passing an appropriate animation parameter. – vadian
@vadian - I am intending to perform multiple changes in a single animated operation - hence the entire experiment needs to be done wrapped in a transaction. For this example however, I have simplified it down to just the delete, but left the transaction in place. Whether or not the transaction is used, the symptom is the same. – Adam

1 Answers

0
votes

After much investigation, including several new code projects distilling the UITableView down to the various different factors that could be contributing to this behavior, I have found the simple answer.

Don't use the UITableView

I, like many others, have relied heavily on the UITableView in many applications, due to its simplicity and performance, however, if you really want it to behave in fluid, sensible ways, it just cannot deliver. There are some inherent bugs in it's behavior which don't appear to bet getting addressed by Apple - and not surprisingly, when there is a much better alternative already in the SDK.

Enter the UICollectionView.

I took all my backend logic for and adapted it to supply a UICollectionView instead (all the work took about half an hour), and lo and behold, everything just worked as originally intended.

So, all my code was correct, the UITableView was just getting in the way.

This is how it now looks. Notice have all deletion scenarios animate correctly, no jankiness.

UICollectionView correct row animation

I'm not the first to have found UITableView lacking: https://pspdfkit.com/blog/2017/the-case-for-deprecating-uitableview/

Additional benefits to UICollectionView:

  • customizable layouts
  • easily customizable cell animations
  • update transaction does not halt currently running scroll animations (this one is great, if you have a background thread refreshing data, you won't get a sudden 'jerk' when rows get rearranged)