Closed lxcid closed 8 years ago
To be honest, I think we should leave it as status quo. Feel free to close this issue if you think the same.
Have you had a look at what they are doing here https://github.com/chrisamanse/Changes/blob/master/README.md ?
(I haven't. I just noticed that project is concretely geared towards collection views thus maybe solving your issue).
thanks dude, this also applies to collection views with exceptions like:
> [error] error: Serious application error. An exception was caught from the delegate of NSFetchedResultsController during a call to -controllerDidChangeContent:. attempt to perform an insert and a move to the same index path (<NSIndexPath: 0xc000000000000016> {length = 2, path = 0 - 0}) with userInfo (null)
> CoreData: error: Serious application error. An exception was caught from the delegate of NSFetchedResultsController during a call to -controllerDidChangeContent:. attempt to perform an insert and a move to the same index path (<NSIndexPath: 0xc000000000000016> {length = 2, path = 0 - 0}) with userInfo (null)
Thanks for this 👍
Omg, you totally saved my ass! Thanks so much!
I have some thoughts and suggestions, but I'm not sure about if we need them resolved. Why I want to raise the issue is because maybe someone out there might be interested. They are mostly concerning substitution/reload and how UIKit and its documentation seems to treat it inconsistently.
Expose edit's origin (source) index, at least for substitution.
My translation from changeset's edit operations to UITableView's row operations is as follow:
When executing row operations between
beginUpdates
andendUpdates
, like delete, reload index is expected to be the ones prior to any updates. As stated in its API documentation:Changeset provides the index after update instead. Making it unavailable to be mixed with other operations within
beginUpdates
andendUpdates
.Makes reducing edits to move optional.
As of 1.0.x, in order to use it with UITableView's row operation, I have to do something like this.
Reload is outside the
beginUpdates
andendUpdates
for reason stated previous. But if I exposes the origin index for substitution edit operation, theoretically, I probably can wrap all operations inbeginUpdates
andendUpdates
.But this is not the case. It seems a little counter intuitive but the exception thrown by UITableView is as follows:
It stated that we are trying to attempt an insert and a move row operation but those code have not change. Funny thing is that if I commented out the reload row operation code (which is possible here as their value will just remain outdated), it will no longer complain.
I believe this is more of a wording bug, UIKit probably meant insert and reload of the same index. But this I can't be sure.
The funny things is that the API documentation for move only mention that it can work with insert and delete, but avoid mentioning reload.
As for UICollectionView, its API documentation for batch update only mention that it can work with insert, delete and move but did not mention about reload. Which will make the current solution for UITableView seems correct.
If I remove the reduce edit step. I can make it work nicely with reload in table view.
But the thing about reload is that it is the least obvious row operation visually. And there are several other options that are reasonable as well. For example, we can get visible rows and update the cell manually (no animation), or just not batching it like above (not an issue as well).