Is there a way to update the height of a single UITableViewCell, without recalculating the height for every cell?

Question

I have a UITableView with a few different sections. One section contains cells that will resize as a user types text into a UITextView. Another section contains cells that render HTML content, for which calculating the height is relatively expensive.

Right now when the user types into the UITextView, in order to get the table view to update the height of the cell, I call

[self.tableView beginUpdates]; [self.tableView endUpdates]; 

However, this causes the table to recalculate the height of every cell in the table, when I really only need to update the single cell that was typed into. Not only that, but instead of recalculating the estimated height using tableView:estimatedHeightForRowAtIndexPath:, it calls tableView:heightForRowAtIndexPath: for every cell, even those not being displayed.

Is there any way to ask the table view to update just the height of a single cell, without doing all of this unnecessary work?

Update

I'm still looking for a solution to this. As suggested, I've tried using reloadRowsAtIndexPaths:, but it doesn't look like this will work. Calling reloadRowsAtIndexPaths: with even a single row will still cause heightForRowAtIndexPath: to be called for every row, even though cellForRowAtIndexPath: will only be called for the row you requested. In fact, it looks like any time a row is inserted, deleted, or reloaded, heightForRowAtIndexPath: is called for every row in the table cell.

I've also tried putting code in willDisplayCell:forRowAtIndexPath: to calculate the height just before a cell is going to appear. In order for this to work, I would need to force the table view to re-request the height for the row after I do the calculation. Unfortunately, calling [self.tableView beginUpdates]; [self.tableView endUpdates]; from willDisplayCell:forRowAtIndexPath: causes an index out of bounds exception deep in UITableView's internal code. I guess they don't expect us to do this.

I can't help but feel like it's a bug in the SDK that in response to [self.tableView endUpdates] it doesn't call estimatedHeightForRowAtIndexPath: for cells that aren't visible, but I'm still trying to find some kind of workaround. Any help is appreciated.

Answer 1

As noted, reloadRowsAtIndexPaths:withRowAnimation: will only cause the table view to ask its UITableViewDataSource for a new cell view but won't ask the UITableViewDelegate for an updated cell height.

Unfortunately the height will only be refreshed by calling:

[tableView beginUpdates]; [tableView endUpdates]; 

Even without any change between the two calls.

If your algorithm to calculate heights is too time consuming maybe you should cache those values. Something like:

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {     CGFloat height = [self cachedHeightForIndexPath:indexPath];      // Not cached ?     if (height < 0)     {         height = [self heightForIndexPath:indexPath];         [self setCachedHeight:height                  forIndexPath:indexPath];     }      return height; } 

And making sure to reset those heights to -1 when the contents change or at init time.

Edit:

Also if you want to delay height calculation as much as possible (until they are scrolled to) you should try implementing this (iOS 7+ only):

@property (nonatomic) CGFloat estimatedRowHeight

Providing a nonnegative estimate of the height of rows can improve the performance of loading the table view. If the table contains variable height rows, it might be expensive to calculate all their heights when the table loads. Using estimation allows you to defer some of the cost of geometry calculation from load time to scrolling time.

The default value is 0, which means there is no estimate.