Row Height Misses

Old Optimization vs. New Features

I've been fighting with table view layout issues this week, but at least I'm in good company there.

The big edge case that I've hit involves having a table view with radically different row heights, and behaviors which are likely to place cells above the current scroll point. Once this happens, scrolling up the table view will jitter if the a cell's size differs significantly from the estimated size. This means the only way to fix the issue is to throw out height estimation entirely, or to implement a cell size caching mechanism like RZCellSizeManager. Both have drawbacks, but both are valid options depending on the number of objects loaded in the table view, and the complexity of implementing good cell height caching.

As an even more interesting case, how do you implement editing controls like the delete indicator without having to reflow your vertical layout? Because as far as I can figure out, triggering beginEditing: doesn't trigger row height recalculation. Reloading the cells can, but there was no way that I could figure out to get a smooth transition to the editing state and recalculate the row heights. I got it very close, but having the cell height change at all wasn't ideal, and the animation had some hard to address issues.

As a workaround, I embedded all of the cell content in a UIView, bound that to the top, bottom, and left edge of the content view, and then constrained the width of the container view to the cell itself. Then when editing begins, a view on the right hand side of the cell is faded out, which means the overhang from the cell doesn't obscure the delete button beneath it. It's not an obvious solution to the problem, and I think there's room to make it more elegant, but it's the best version of the fix for that issue that I've found so far.

It also highlights a huge part of the issue, there's a difficult interplay between optimization, accuracy, and flexibility. UITableView is built with optimizations to put large numbers of table cells onto a device with 1/8th the RAM in the latest iPhone, and a similarly weak CPU and GPU. Then there's the fact that it's trying to address pretty much every use case possible with one layout manager, and one largely designed around the idea of very simple layout calculations, not dynamic text sizing, autolayout, multiline text, etc.