Is calling cellForRowAtIndexPath: ever practical?

Question

I\'ve seen many many developers when implementing a UITableViewDelegate and UITableViewDataSource directly call cellForRowAtIndexPat

Answer 1

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.

Answer 2

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.

Answer 3

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: