What's the order of heightForRowAtIndexPath being called?

Question

I ask this because I find it's strange that heightForRowAtIndexPath firstly work with the last cell in my tableView.

Here's what I got, I've 13 sections, each section has only one cell. So when I called reloadData and log the indexPath.section in heightForRowAtIndexPath, the last section's indexPath got printed. Then it started from section 0, then 1, 2, 3, till 11 in order.

This is tested on both device & simulator and both iOS 7 & iOS 8.

Is this the fixed order or only for the case that I test?

Answer 1

Apple doesn't specify the order in which -tableView:heightForRowAtIndexPath: is called.

This means you cannot rely on any particular order. When you call -endUpdates, or any of the reload/insert/delete/move methods, the row heights will be recalculated. UITableView may take advantage of special knowledge (like the currently visible cells) and recalculated row heights in a different order.

Worse, even if you test every version of iOS on every Apple device and get the exact same order every time, the next point release could change it.

Answer 2

If you are using AutoLayout . Fix Constrains Properly . They might make the difference. In iOS * you don't even have to use -tableView:heightForRowAtIndexPath:.