Question

I use the “famous” boilerplate code that almost everybody uses for handling cellForRowAtIndexPath:

UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:@"someCustomCellID"];  
if (cell == nil)  // nothing to recycle from the queue: create a new cell

but this give me lots of problems ’cause my cells contains images that I load async and the two functionalities (dequeueing and async load) often conflict. So I try creating every time a new cell and it works pretty well and fast.
But I have a doubt: should I still call dequeueReusableCellWithIdentifier to free the memory even if I ignore the returned value and create the cells each time?
I suppose the cells not used anymore are automatically deallocated (as they should be), but I wonder if the caching queue may require the explicit “free” with the dequeue call…

Answer 1

dequeueReusableCellWithIdentifier is not designed to prevent memory leaks but it is designed for performance (one way is by reducing memory usage). When using the dequeue method, scrolling a table view will be much smoother when there are several rows of data. I would recommend you get your async loading to work with the dequeue method, especially if you see any lag while scrolling. If you would like an example of how to do this see Apple’s LaxyTableImages Example. If you do, however, determine that you do not want to reuse cells, then simply pass nil as the reuseIdentifier when creating you cells.