Cell lag for row along index path
In the cell for the row in the index path, I get information from the master data, based on which I update the text in the cell.
This is not a problem if I have fewer lines, but it is not smooth if I have more cells (500 lines)
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:@"cellIdentifier"];
MyRecord *record = [self fetchDataForIndexPath:indexPath.row]; //This is line which makes the table view scrolling un silky
cell.infolabel.text = record.name;
}
source to share
When linked UITableView
to a master data fetch query, the tool you want is NSFetchedResultsController
. It will handle caching for you, which is your problem. You are almost certainly making selections when you don't need to. You should only update the data when the data changes.
If you are not using select queries directly, then you can handle it manually. Create an object in front of the data API, which is responsible for keeping track of the current displayed state. This object is often referred to as the "view model". See Introduction to MVVM for one good discussion of this pattern. Your viewmodel should cache the most recently retrieved information so you don't have to repeat it each time it is rendered. When the underlying model changes, this is when the table view controller needs to be notified to update some of the cells.
The key consideration is that you should avoid calling reloadData
on such large table views. reloadData
instructs the table view to flush all of its own cache and start over. If possible, you should use the less radical methods, such as reloadRowsAtindexPaths:withRowAnimation:
, insertRowsAtIndexPaths:...:
, deleteRowsAtIndexPaths:...:
, etc. Combined with beginUpdates
this, it is an important part of a good user interface when browsing large tables. See "Batch Insert, Delete, and Reload Rows and Sections" in the Table Programming Guide.
source to share