Keep the scroll position after -reloadData by maintaining and restoring the contentOffset #31

merged 1 commit into from Aug 3, 2011

2 participants

Twitter, Inc. member

To me, this kinda seems like it should be the default behavior but I'll freely admit I might be missing something :)

This tries to ensure that the scroll position doesn't change after calling -reloadData. If, for instance, the table view grows, this makes it behave like you'd probably expect it to (you won't be suddenly scrolled to the bottom).


There's already a mechanism for this (unless I misunderstand). Check out:

  • (void)reloadDataMaintainingVisibleIndexPath:(TUIFastIndexPath *)indexPath relativeOffset:(CGFloat)relativeOffset

(Note it requires participation from the caller because the mapping from items <-> index paths may change after a reload... think if an item gets inserted before another item). The table view doesn't have a semantic understanding of the stuff it's displaying.

Twitter, Inc. member

Yeah, so that's some of the source of my confusion. -reloadDataMaintainingVisibleIndexPath:relativeOffset: is cool but:

  • it seems overly manual to use
  • seems like maintaining scroll position is what I'd want most of the time (or at least is a less surprising behavior)
  • an index path isn't necessarily the best way to express where in the table view I am (at least, not now that we have section headers and table view headers).

I can totally see -reloadDataMaintainingVisibleIndexPath:relativeOffset: being useful, but I think this serves a different purpose.


OK, I buy it.

@atebits atebits merged commit 1bcc4ef into twitter:master Aug 3, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment