UITableView issue (iOS) - ios

Question

I wonder why cellForRowAtIndexPath function is called when scrolling the UITableView. Does it mean on every scrolling cell configuration code runs again? I have a slowness problem when scrolling the table.
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
static NSString *CellIdentifier = #"CountryCell";
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
if (cell == nil) {
cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease];
}
// Configure the cell...
NSString *continent = [self tableView:tableView titleForHeaderInSection:indexPath.section];
NSString *country = [[self.countries valueForKey:continent] objectAtIndex:indexPath.row];
cell.textLabel.text = country;
cell.accessoryType = UITableViewCellAccessoryDisclosureIndicator;
return cell;
}

Answer 1

As others have said, yes, when each new cell is about to scroll onto the screen, cellForRowAtIndexPath is called for each cell. While this may strike you as a performance hit, the alternative (for iOS to create all of the cells up-front) would be worse: If you're finding it slow to create one cell, imagine having to create hundreds, many of which the user may never see. Anyway, the just-in-time nature of cellForRowAtIndexPath is probably more efficient, both in terms of the up-front performance hit, as well as in terms of precious memory consumption on a small mobile device.
In terms of slow performance, there's nothing here that could be the culprit. A lot of us have cellForRowAtIndexPath methods that are significantly more complicated and speed is not an issue. Maybe the there are more efficient alternatives to a valueForKey lookup that I might advise if you were doing millions of lookups, but for one cell the difference would not be observable to the human eye. I think you have to look elsewhere. Is titleForHeaderInSection doing anything strange (i.e. something other that just looking up a value in an array)? Maybe you can share that with us. Maybe something in the UI. Maybe you should run this through the Profiler's "Time Profiler" and maybe something will stick out. But a cellForRowAtIndexPath this simple should result in a perfectly smooth user experience.

Answer 2

When you scroll the table, cells that dissappear are discarded and cells that appear must be created and configured using cellForRowAtIndexPath.
Or better said - cells are not discarded, they are moved to a queue of cells that can be reused and no new cells are created - the reusable cells are taken from the queue and reconfigured.

Answer 3

The method cellForRowAtIndexPath gets called for each and every row in your UITableView, when a row disappears from the visible view, its memory is cleared and a new cell that is coming into visibility, for that new memory is allocated (or a older one might be re used) and the new cell is configured using cellForRowAtIndexPath method.
It comes to know from this method only that what needs to be configured for this particular cell.
It is slow may be because of for each cell you are performing some heavy operation.

Answer 4

It's correct that cellForRowAtIndexPath is called when scrolling the table, that's exactly what it's for. Every time a new cell shows up during scrolling, a UITableViewCell instance should be created or re-used, and then configured.
Slowness is usually caused by performing an expensive operation in the configuration phase. In your case, the potentially slow operation would be the country lookup.