UITableView scrollToRowAtIndexPath scrolls to wrong offset with estimatedRowHeight on iOS 7

Question

I am using the estimatedRowHeight method from UITableView in iOS 7, which works perfectly for fast loading of a UITableView with 5000 rows of variable heights.

Answer 1

try to add this code in -cellForRowAtIndexPath: right before return the cell

[cell layoutIfNeeded]

Answer 2

The solution for me was to set the estimatedRowHeight to 0

Answer 3

Still no solid solution but for me it was acceptable to perform a scroll without animation which worked well in the sense that it scrolls to the expected cell with the correct offset, despite of what is mentioned in http://www.openradar.me/20829131.

self.tableView.scrollToRowAtIndexPath(indexPath, atScrollPosition:.Top, animated: false)

Answer 4

When scrollToRowAtIndexPath is called, height of all the cells b/w current position and target offset are not calculated. Only some of them are.

Instead, UITableView uses estimatedRowHeight to calculate target offset which leads to wrong offset.

I'm facing the same issue and I found a small trick(which I don't really like) to calculate exact cell height only once after initial relaodData. I inserted two lines below:

tableView.reloadData()

// only for the initial reloadData

let numSections = tableView.numberOfSections
let numRowsInLastSection = tableView.numberOfRowsInSection(numSections-1)

// scrolls to the last row in the tableView
tableView.scrollToRowAtIndexPath(NSIndexPath(forRow: numRows-1, inSection: numSections-1), atScrollPosition: .Bottom, animated: false)

// back again to the original position(which is 0 for this is only called right after the initial reloadData)
tableView.scrollToRowAtIndexPath(NSIndexPath(forRow: 0, inSection: 0), atScrollPosition: .Top, animated: false)

This results in the tableView appearing on the screen late, but I think it's acceptable rather than freezing UI after the tableView appeared. It's even better when you call an API on the beginning because it feels like a little delay on the network, not the UI lag.

After this, tableView jumps to exact position of the cells.

Yeah, I don't really like this solution either :|

EDIT:

The only reason I did this was to calculate actual row height by calling cellForRowAtIndexPath:, but I found out when giving proper estimatedHeight for every row by delegate method estimatedHeightForRowAtIndexPath: instead of giving static value to UITableView.estimatedRowHeight solves the issue.

What I finally did was to cache the heights of rows from willDisplayCell:forRowAtIndexPath: to disk and use that value on estimatedHeightForRowAtIndexPath:.

By doing this, estimatedHeightForRowAtIndexPath: for all rows are called in the beginning and scrollToRowAtIndexPath works well.

Answer 5

It seems to work after the view was layouted by the system. I'm calling scrollToRowAtIndexPath with correct results in the VC's viewDidAppear. Which is not very beautiful of course, because it scrolls when the view is already visible...

Answer 6

It's not the prettiest solution but I use a workaround for this issue who do the trick. Always update the estimatedRowHeight to the tallest computed cell and then use something like this :

1. Scroll the content of the tableView to offset zero.

2. Finish by calling scrollToRowAtIndexPath to index path zero.

   [self.tableView setContentOffset:CGPointZero animated:YES];
   dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(0.2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
       [self.tableView scrollToRowAtIndexPath:[NSIndexPath indexPathForRow:0 inSection:0]
                             atScrollPosition:UITableViewScrollPositionTop
                                     animated:YES];
   });
   

As result the tableView should scroll to the top quite smoothly.