-1

I have small doubt about in checking retain count of the object:

Please find the below code, it is displaying retainCount is 1 after releasing the object memory.

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {

    static NSString *CellIdentifier = @"Cell";

    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
    if (cell == nil) {
        cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease];
        CGRect contentRect = [cell.contentView bounds];     
        UIImageView *thumbView = [[UIImageView alloc] initWithImage:[UIImage imageNamed:IMAGE_CELL_BACKGROUND]];
        thumbView.frame = contentRect;      
        cell.backgroundView=thumbView;
        [thumbView release];
    }
    UIImageView *image=[[UIImageView alloc]initWithImage:[UIImage imageNamed:@"left_arrow.png"]];
    **NSLog(@"Image retain count %d",[image retainCount]);**
    image.frame=CGRectMake(290, 12.5, [UIImage imageNamed:@"left_arrow.png"].size.width,  [UIImage imageNamed:@"left_arrow.png"].size.height);
    image.backgroundColor=[UIColor clearColor];
    [cell.contentView addSubview:image];
    [image release];
    **NSLog(@"Image retain count-- after %d",[image retainCount]);**


        // Configure the cell...

    return cell;
}
Justin Boo
  • 10,132
  • 8
  • 50
  • 71
VsN
  • 83
  • 2
  • 6
  • 5
    You really shouldn't be relying on the `retainCount` values. See [this question](http://stackoverflow.com/q/5784084/3009) for more explanation. – highlycaffeinated Aug 22 '11 at 19:08
  • 1
    I'll put it more strongly: `retainCount` **is worse than useless.** You cannot trust it to help you in anything, because **it is very likely to lead you down a wrong path and/or confuse you**. Think in terms of ownerships, as prescribed by the Memory Management Programming Guide, and if you *must* look at retains and releases (for debugging purposes only!), use Instruments's Leaks template instead. – Peter Hosey Aug 22 '11 at 22:39

2 Answers2

6

This is perfectly normal. cell.contentView still holds a reference to the image. When you call [cell.contenetView addSubview:image], cell.contentView stores the image reference somewhere (probably in an array or something similar), and it increases the reference counter by 1 to ensure that the image is not deallocated while cell.contentView is still using it. Whenever cell.contentView is deallocated for whatever reason, it will ensure that the retain count of the image is decreased by 1.

Tamás
  • 47,239
  • 12
  • 105
  • 124
  • Hi Tamas can you please help me how can i mange memory in this scenario. – VsN Aug 22 '11 at 19:08
  • if i say image=nil instead of [image release], will it be good practice, sorry for my poor question. I HAVE TO LEARN MEMORY MANAGEMENT. – VsN Aug 22 '11 at 20:41
  • No, because you will be leaking a reference by doing that. (You own a reference to ``image`` because you initialized it with an ``init...`` method, hence you *must* release that reference somewhere where you do not need ``image`` any more). – Tamás Aug 22 '11 at 20:56
  • 1
    @VsN: More specifically, assigning a new value to the `image` variable is not the same as sending a `release` message to the `image` object (more precisely, the object whose pointer is in the `image` variable). Only sending a `release` message releases the object. Sending an `autorelease` message causes the pool to send the object a `release` message later. Assigning to a variable causes a `release` message not at all. – Peter Hosey Aug 22 '11 at 22:41
1

The addSubview: call in the line before [image release] causes the cell's contentView to retain the image view, so it's completely expected that the retain count is 1 after that – it would be pretty bad if it was zero because you (or rather the cell's contentView) still need the image view to be in memory.

By releasing it, you've essentially given the contentView the sole responsibility of releasing the image view when it is released itself or doesn't need it anymore (e.g. if removeFromSuperview is called).

omz
  • 53,243
  • 5
  • 129
  • 141