Lost Scroll Position?

[inb4ohnoes]

This utility lists "lost scroll position?" as one of the problems it solves. Am I correct in assuming that there is an ability to insert rows without losing scroll position? If not, is it possible to add this ability by, for example, setting an anchor cell or index that stays while everything mutates around it?

[zats]

It sounds like a great idea, but I think it's somewhat outside of the scope of the tool.

It can be easily achieved though: -[UITableView rectForRowAtIndexPath:] or -[UICollectionViewLayout layoutAttributesForItemAtIndexPath:] measured prior to the update and after it. However there are all sorts of subtleties that need to be considered and would make the API bloated.
Have you considered using -scrollToItemAtIndexPath:atScrollPosition:animated?

[inb4ohnoes]

I have. Currently I have settled on manually setting the offset of the table view after I've calculated the height of everything that is being added. However that isn't the most elegant solution as I can't animate visible deletions and sometimes the table still flashes when things get reloaded. That's why when I saw "lost scroll position" as one of the listed problems this tool was supposed to solve I got really excited, but I suppose you meant something else.

[zats]

Well, what I meant is that you see changes animating in, therefore user understands changes better than simply new cells appearing out of nowhere, but I understand your point, it does sound like a nice addition. Do you have an idea of how this API would look?

[zats]

Couple of additional question, as it seems like you gave this problem some though already 😃

• how do you know which cell is your anchor in advance without calculating diff between you old and new data?
• how would you go around case when all visible cells are being deleted, what would be your anchor?

[inb4ohnoes]

So 'UITableView' has an API called indexPathForVisibleRows that I believe can be used to achieve an API addition to this tool that looks something like this:

- (void)wml_applyBatchChanges:(NSArray *)diffs inSection:(NSInteger)integer withRowAnimation:(UITableViewRowAnimation *)animation andAnchorInVisibleRows:(NSInteger)anchorIndex;

Where everything stays the same except the anchor would refer to a visible cell index returned from the above mentioned table view API. In the event that all visible cells are actually being removed, the anchor would be the first cell above the removed cells that isn't being removed. In the event that there is no cell above the removed cells, there would be no anchor. I haven't thought through all the possible edge cases as I've really only thought about something like this in the context of my own use cases, but I think this adequately covers the most immediate cases. What do you think?

[zats]

So, as I understood, you'd prefer to maintain the original offset from the top of the UITableView viewport for specified indexPath, right?
I think the major problem would be with UITableView where, opposed to UICollectionView, no callback is being fired upon completion of the changes. And I'm always hesitant to add code relying on timers to compensate for the lack of completion callbacks. Any ideas?

[inb4ohnoes]

Yes that is correct. You're also correct that there is no callback or any sort of completion handler, so I do think a timer is the best solution for this. Or maybe something could be done with beginUpdates and endUpdates?

[zats]

Ok, I'll think of a way to deal with it and will try to work something out when I have time.
Pull requests are welcomed by the way :)

[inb4ohnoes]

Thanks! I'll definitely be taking a good long look at it as well, as it is an integral part of a project I'm currently working on. Best of luck!