Reputation: 2270
In cell for row at index path I am fetching info from core data based on which I update the text on the cell..
It is not a problem if I have less number of rows but It is not smooth if I have more number of cell (500 rows)
- (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;
}
Upvotes: 3
Views: 154
Reputation: 299505
When tying a UITableView
to a core data fetch request, the tool you want is NSFetchedResultsController
. It will handle caching for you, which is your problem. You're almost certainly performing fetches when you don't need to. You should only refetch data when the data changes.
If you aren't using fetch requests directly, then you would manage this by hand. Create an object in front of the data API that is responsible for keeping track of the current displayable state. This object is often called a "view model." See Introduction to MVVM for one good discussion of this pattern. Your view model should cache the latest fetched information so that you don't keep re-fetching it every time you display. When the underlying model changes, that's when to notify the table view controller that certain cells need to update.
A key consideration is that you should avoid calling reloadData
on large table views like this. reloadData
instructs the table view to dump all of its own cache and start over. Whenever possible you should use the less-drastic methods like reloadRowsAtindexPaths:withRowAnimation:
, insertRowsAtIndexPaths:...:
, deleteRowsAtIndexPaths:...:
, etc. Combined with beginUpdates
, this is a critical part of good user experience on large table views. See "Batch Insertion, Deletion, and Reloading of Rows and Sections" from the Table View Programming Guide.
Upvotes: 4