You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a diff contains a row that is to be deleted, and a row that is to be updated that has the same indexPath as the deleted row (before it was deleted), there is a crash.
Ordering of Operations and Index Paths
... It (the UITableView) defers any insertions of rows or sections until after it has handled the deletions of rows or sections. The table view behaves the same way with reloading methods called inside an update block—the reload takes place with respect to the indexes of rows and sections before the animation block is executed. This behavior happens regardless of the ordering of the insertion, deletion, and reloading method calls.
I put together a sledge-hammer type fix which is somewhat inelegant in my mind. Basically, in the UITableView.applyDiff and UICollectionView.applyDiff I made two update blocks. The first one does the inserts, deletes, and moves. The second one does the updates.
I think a better fix would be to leave the single update block, but that would require the Diff API to change to return both the "before" and "after" indices of the update (or maybe create an internal/private API that the UITableView/UICollectionView extensions use. But this works and I didn't want to try to change the API.
The text was updated successfully, but these errors were encountered:
SuperTango
added a commit
to playlist/HeckelDiff
that referenced
this issue
Feb 7, 2017
mcudich#9
reloadItems is done separately as the update indexes returne by diff() are in respect to the "after" state, but the collectionView.reloadItems() call wants the "before" indexPaths.
mcudich#9
reloadItems is done separately as the update indexes returne by diff() are in respect to the "after" state, but the collectionView.reloadItems() call wants the "before" indexPaths.
If a diff contains a row that is to be deleted, and a row that is to be updated that has the same indexPath as the deleted row (before it was deleted), there is a crash.
For example:
If we do a
it will crash with an internal inconsistency exception.
a full repo showing the issue can be found here: https://github.com/playlist/HeckelDiffUpdateFail
The cause is that the row updates are processed in relation to the indexes BEFORE the update. The
diff()
returns the indexes after.from https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/TableView_iPhone/ManageInsertDeleteRow/ManageInsertDeleteRow.html:
I put together a sledge-hammer type fix which is somewhat inelegant in my mind. Basically, in the
UITableView.applyDiff
andUICollectionView.applyDiff
I made two update blocks. The first one does the inserts, deletes, and moves. The second one does the updates.I think a better fix would be to leave the single update block, but that would require the Diff API to change to return both the "before" and "after" indices of the update (or maybe create an internal/private API that the UITableView/UICollectionView extensions use. But this works and I didn't want to try to change the API.
The text was updated successfully, but these errors were encountered: