Too slow on 'big' tables even with cacheByIndexPath about uitableview-fdtemplatelayoutcell HOT 3 CLOSED

This is UITableView's "bug like" problem in iOS8 (not in iOS7), -tableView:heightForRowAtIndexPath: method will be called many times initially, and re-calculate when cell dequeues even you've scrolled through for more than one time, so this is why I provide a cacheByIndexPath API to avoid a mess of height calculations.
When I implement cacheByIndexPath, I found it's not easy to automatically invalidate caches when data source updates. So I used a tricky way, swizzled a private method who triggers reload ( -reloadData, -insertSection..,-deleteRows... ... all work) and clear all current caches, it's a bit more complex, but makes this cacheByIndexPath API quite easy to use, no need for manual invalidation calls. But it has the "3 times" problem as you pointed, because UITableView itself triggers reload for 2 more times at init when it's being moved to window and layout its subviews. It's hard to solve unless I put the invalidateCaches method public.

So I'm thinking a better solution.

from uitableview-fdtemplatelayoutcell.

Anything on this? I love the idea of this project and want to use it but without this iOS8 support, it kind of beats the purpose of it.

from uitableview-fdtemplatelayoutcell.

@sjapps Just use - (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath api for height calculation, it's iOS6+ and pure. New version's coming and I'll close this issue by then.

from uitableview-fdtemplatelayoutcell.