Assertion Failure in UICollectionViewData indexPathForItemAtGlobalIndex

Question

I am using performBatchUpdates() to update my collection view, where I am doing a complete refresh, i.e. delete whatever was in it and re-insert everything.

Answer 1

This is the proper workaround to this crash:

Each of your supplementary views are associated with a certain index path. If you don't have a cell at that index path (initial load, you've deleted the row, etc), return a height of 0 for your supplementary view via your layout's delegate.

So, for a flow layout, implement UICollectionViewDelegateFlowLayout's

(CGSize)collectionView:(UICollectionView *)collectionView layout:(UICollectionViewLayout*)collectionViewLayout referenceSizeForHeaderInSection:(NSInteger)section

method (and the corresponding footer method, if you're using footers) with the following logic

if ( you-have-a-cell-at-the-row-for-this-section )
    return myNormalHeaderSize;
else return CGSizeMake( 0,0 );

Hope this helps!

Answer 2

A cheeseball mistake that can lead to this error is reusing the same UICollectionViewFlowLayout on multiple collectionViews on the same viewcontroller! Just init different flowLayouts for each collectionview and you'll be good to go!

Answer 3

Finally! Ok, here's what was causing this crash for me.

As previously noted, I was creating supplementary views in order to provide custom-styled section headers for my collection view.

The problem is this: it appears that the indexPath of a supplementary view MUST correspond to the indexPath of an extant cell in the collection. If the supplementary view's index path has no corresponding ordinary cell, the application will crash. I believe that the collection view attempts to retrieve information for a supplementary view's cell for some reason during the update procedure. It crashes when it cannot find one.

Hopefully this will solve your problem too!

Answer 4

If you remove the last cell from a section containing header/footer the bug appears.

I tried to return nil for header/footer size/element at that time and this sometimes fixes the issue.

Options:

1. Reload the whole table view instead of animating the removal of the last item.
2. Add an additional invisible, basic cell with a size less than 1.

Answer 5

reloadData doesn't work for me, because the whole purpose of using performBatchUpdates is to get the changes animated. If you use reloadData you only refresh the data, but without animations.

So suggestions of "replace performBatchUpdates with reloadData" is pretty much saying "give up on what you're trying to do."

I'm sorry, I'm just frustrated because this error keeps coming up for me while I'm trying to do some great animated updates and my model is 100 % correct, it's some iOS magic inside getting broken and forcing me to change my solutions completely.

My opinion is that Collection Views are still buggy and can't do complicated animated refreshes, even though they should be able to. Because this used to be the same thing for Table Views but those are now pretty stable (it took time, though).

//Edit (Sep 1, 2013) The reported bug is closed now so this issues seems to have been resolved by Apple already.

Answer 6

I ran into this problem when I delete one of the cells from my collection view.

The problem was that I use a custom layout, and the call layoutAttributesForElementsInRect was returning more than the number of cells in the collection view after the delete.

Apparently UICollectionView just iterates through the array returned by the method without checking the number of cells.

Modifying the method to return the same number of layout attributes solved the crash.