CODEWITHSUNDEEP
iosuitableview
Erik Kerber
Erik Kerber

Reputation: 5656

Is calling cellForRowAtIndexPath: ever practical?

I've seen many many developers when implementing a UITableViewDelegate and UITableViewDataSource directly call cellForRowAtIndexPath: to either:

1) Retrieve the cell to grab a model element that they stored within the cell:

-(void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath{
    MyCell *cell = (MyCell *)[tableView cellForRowAtIndexPath:indexPath];
    int secretCode = cell.secretCode;
    LaunchMissileViewController *vc = [[LaunchMissileViewController alloc] initWithSecretCode:secretCode];
    [self.navigationController pushViewController:vc];
}

2) Attempt to style the cell (this has clear problems, but seems very common):

MyCell *cell = (MyCell *)[self cellForRowAtIndexPath:indexPath];
// or [tableView cellForRowAtIndexPat:indexPath];
cell.backgroundColor = [UIColor greenColor];

Is it safe to make the blanket statement that "only the framework should ever call cellForRowAtIndexPath:"? Or is there a practical reason one might ever call it themselves?

Upvotes: 7

Views: 3408

Answers (3)

Erik Kerber
Erik Kerber

Reputation: 5656

I will say rmaddy is correct, though I have one case where it is arguably practical to use:

If you ever require a copy of a UITableViewCell to apply to another view.

(derived from https://github.com/Ice3SteveFortune/i3-dragndrop)

UIView* cellCopy;

UITableViewCell* cell = [self.tableView cellForRowAtIndexPath:indexPath];
NSData* viewCopyData = [NSKeyedArchiver archivedDataWithRootObject:cell];
cellCopy = [NSKeyedUnarchiver unarchiveObjectWithData:viewCopyData];

// Maybe to drag-and-drop outside of the UITableViewCell.
[self.otherView addSubview:cellCopy];

I want to leave this here as an example of one of the few cases where it is remotely practical to call cellForRowAtIndexPath:

Upvotes: 3

Akshat Singhal
Akshat Singhal

Reputation: 1801

Retrieving data from the cell makes no sense as the data being inserted into the cell would be known to the developer. The developer can straight away get the data. Another problem, (big one) with this approach is that if that cell is not visible, it would be first generated and then the data retrieved.

Upvotes: 1

rmaddy
rmaddy

Reputation: 318884

Personally I don't think there are ever good cases to directly call tableView:cellForRowAtIndexPath: directly on the data source.

For case #1 it is simply bad coding. The cell should never contain the data. The data source should have the data so get the data from the actual data source, not the cell.

For case #2 you would only ever need to update a visible cell. And for this you can use the UITableView cellForRowAtIndexPath: method. No need to call the data source for the cell.

I try never to say "never" but it should be an extremely rare case where you have a real need to get the cell by calling the data source method.

Upvotes: 8

Related Questions