Question

Well till a couple of days back I use to code everything for UITableViewCell in

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

method. But recently I found out that the iPhone developers (or mac) use configureCell:atIndexPath: and even most of the apples provided source code have this as one of the class function. So my question is basically why do we like to create one more function to provide the cell contents then just write the whole code in cellForRowAtIndexPath: method instead.

PS. for people who are not familiar with this then you should see apples source code. and configureCell:atIndexPath: is not another method in UITableViewDatasource, its just a class function that we have in every class that has table view . And we use it like this.

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    static NSString *CellIdentifier = @"Cell";
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
    if (cell == nil)
    {
        cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault 
                                       reuseIdentifier:CellIdentifier] autorelease];
    }
    [self configureCell:cell atIndexPath:indexPath];
    return cell;
}

- (void)configureCell:(UITableViewCell *)cell atIndexPath:(NSIndexPath *)indexPath
{
     cell.titleLabel.text = [NSString stringWithFormat:@"%d",indexPath.row];
}

And more important, after just using this style for trial purpose I got in love this function and now I use it all the time.(When I am using a UITableView)

Edit: Ok I think people are getting a wrong idea about my question so let me make it more clear.

I meant why to create another function when you can place all your code in this function

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

I am not concern about the method name.

Answer 1

It’s done because you may want to update cells when they’re already on the screen. Rather than completely refreshing the cell, you can simply fetch the existing cell from the table view and run it through configureCell:atIndexPath:. If the method is correctly implemented, this will update all the data in the cell without having UITableView remove the old cell, dequeue or allocate the new cell, and put it on screen.

---

For historical interest:

As far as I know, I’m the guy who’s responsible for configureCell:atIndexPath:. I’m sure other people have come up with the same idea, but I believe the snippet of code that popularized it was originally written by me. It was then spread by Apple and became a convention.

The early versions of NSFetchedResultsControllerDelegate had a controllerDidChangeContent: method, but no controllerWillChangeContent: call, which meant there was no opportunity to call -[UITableView beginUpdates] before changing the contents of the table view.

I filed Radar #6708453 asking for them to add this delegate method, and included some example code to show them what I wanted to do. That code had the actual cell updating logic in a refreshCell:atIndexPath: call, so that it could be called from both tableView:cellForRowAtIndexPath: and controller:didChangeObject:atIndexPath:forChangeType:newIndexPath:.

When the next beta seed came out, I found that the iOS engineering team not only added the method I suggested, but copied the sample code from my bug report into the NSFetchedResultsControllerDelegate documentation, although they wisely changed the name to the less confusing configureCell:atIndexPath:.

I actually started a new project today with the Master/Detail iOS Core Data template, and noticed that my code—and the configureCell:atIndexPath: method with it—was in the template. I ran a quick Google search to see if it had become a common convention. It seems that it has. I’m rather proud of what that little chunk of code has made of itself!