title: iPhone - dequeueReusableCellWithIdentifier usage
body: <p>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.</p>
  
  <p>I found out that <code>dequeueReusableCellWithIdentifier</code> 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.</p>
  
  <p>Here is what people usually do:</p>
  
  <pre><code>UITableViewCell* cell = [tableView dequeueReusableCellWithIdentifier:@"Cell"];
  
  if (cell == nil) {
    cell = [[UITableViewCell alloc] initWithFrame:CGRectZero reuseIdentifier:@"Cell"];
  
  // Add elements to the cell
  return cell;
  </code></pre>
  
  <p>And here is the way I did it:</p>
  
  <pre><code>// 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;
  </code></pre>
  
  <p>The difference is that people use the same identifier for every cell, so dequeuing one only avoids to alloc a new one.</p>
  
  <p>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.</p>
  
  <p><i>In fine</i> 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).</p>
  
  <p>Am I wrong to use it this way? Or is it just up to the developer, depending on his needs?</p>