Incorrect handling of NSFetchedResultsChangeUpdate in fetched results controller delegate
kylef opened this issue · 1 comments
Just noticed this repo (and the fetched results controller delegate). I'm not interested in fixing it, but I noticed this bug so I will share.
See this article from Apple on NSFetchedResultsChangeUpdate https://developer.apple.com/library/ios/releasenotes/iPhone/NSFetchedResultsChangeMoveReportedAsNSFetchedResultsChangeUpdate/ which describes it in more detail.
Since we use begin and end updates. If cells have been re-ordered, the cell's wont actually be re-ordered until end updates happens. But if we have a NSFetchedResultsChangeUpdate, we will reconfigure the cell at the index path. If a cell before it has been removed/inserted, this indexpath will reference a different cell until end updates has been called. -- kylef-archive/KFData#24 / kylef-archive/KFData@2d5f2d4
From all of the other implementations I could find for controller:didChangeObject:atIndexPath:forChangeType:newIndexPath:, this was pretty standard. I'm pretty sure I've shipped apps with this, and it worked as expected. Unless anyone else wants to submit a pull request to fix this, I'm content to close this issue.