iPhone - dequeueReusableCellWithIdentifier usage

Question

I'm working on a iPhone app which has a pretty large UITableView with data taken from the web, so I'm trying to optimize its creation and usage.

I found out that dequeueReusableCellWithIdentifier is pretty useful, but after seeing many source codes using this, I'm wondering if the usage I make of this function is the good one.

Here is what people usually do:

UITableViewCell* cell = [tableView dequeueReusableCellWithIdentifier:@"Cell"];  if (cell == nil) {   cell = [[UITableViewCell alloc] initWithFrame:CGRectZero reuseIdentifier:@"Cell"];  // Add elements to the cell return cell; 

And here is the way I did it:

// The cell row NSString identifier = [NSString stringWithFormat:@"Cell %d", indexPath.row];   UITableViewCell* cell = [tableView dequeueReusableCellWithIdentifier:identifier];  if (cell != nil)   return cell;  cell = [[UITableViewCell alloc] initWithFrame:CGRectZero reuseIdentifier:identifier]; // Add elements to the cell return cell; 

The difference is that people use the same identifier for every cell, so dequeuing one only avoids to alloc a new one.

For me, the point of queuing was to give each cell a unique identifier, so when the app asks for a cell it already displayed, neither allocation nor element adding have to be done.

In fine I don't know which is best, the "common" method ceils the table's memory usage to the exact number of cells it display, whilst the method I use seems to favour speed as it keeps all calculated cells, but can cause large memory consumption (unless there's an inner limit to the queue).

Am I wrong to use it this way? Or is it just up to the developer, depending on his needs?

Answer 1

The purpose of dequeueReusableCellWithIdentifier is to use less memory. If the screen can fit 4 or 5 table cells, then with reuse you only need to have 4 or 5 table cells allocated in memory even if the table has 1000 entries.

In the second way there is no reuse. There is no advantage in the second way over just using an array of table cells. If your table has 1000 entries then you will have 1000 cells allocated in memory. If you are going to do that you would put them in an array and just index the array with the row number and return the cell. For small tables with fixed cells that may be an reasonable solution, for dynamic or large tables it is not a good idea.