is dequeueReusableCellWithIdentifier mandatory to avoid memory leaks? - ios

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.

Answer 2

dequeueReusableCellWithIdentifier helps keep down the number of times you load an reload things from files or XIB. If you have a custom cell or cells with non-standard contents, it can be a lot faster to re-use a cell that already has it all setup.
I recall working on something similar, but in our case, we loaded images into Core Data objects asynchronously and had the cell observe the image in that object. When the image was loaded, the cell was notified and it updated its image view.
When the cell came back out to us via dequeueReusableCellWithIdentifier, we stopped it from observing and set it to observe the next object's image.

Answer 3

Just use prepareForReuse: in your UITableViewCell's class, to stop the async load, before the cell is used again.

Answer 4

Yes, you need to use dequeueReusableCellWithIdentifier to avoid leaks, if you are dynamically allocating cells.
Presumably your asynchronous image loading works something like this:
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:#"Cell"];
if (!cell) {
...
}
NSURLRequest *request = [self URLRequestForIndexPath:indexPath];
[NSURLConnection sendAsynchronousRequest:request queue:[NSOperationQueue mainQueue]
completionHandler:^(NSURLResponse *response, NSData *data, NSError *error) {
cell.imageView.image = [UIImage imageWithData:data];
}];
return cell;
}
That code has a problem. By the time the completion handler runs, the table view may have reused the cell for a different row!
We need to change the completion block so it looks up the cell for the row when it's ready to set the image:
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:#"Cell"];
if (!cell) {
...
}
NSURLRequest *request = [self URLRequestForIndexPath:indexPath];
[NSURLConnection sendAsynchronousRequest:request queue:[NSOperationQueue mainQueue]
completionHandler:^(NSURLResponse *response, NSData *data, NSError *error) {
UITableViewCell *cell = [tableView cellForRowAtIndexPath:indexPath];
if (cell)
cell.imageView.image = [UIImage imageWithData:data];
}];
return cell;
}

Answer 5

You should use the method, always. If it returns a cell, use that cell. If it returns nil, then and only then should you create a cell.
If the method is demanding a cell for an image which you have not yet loaded, then you should provide an alternative. Perhaps a UIImageView with a customized, animated progress spinner? Then, when your image arrives, you can use the proper image when necessary.
Do not worry about deallocating cells. Once you give them to the table view, they are the table view's responsibility (at least as far as memory management is concerned).