Custom UITableViewCell from Interface Builder with retain count 2

Question

Hi!
I am creating a customViewCell in my UITableViewController (which I was creating in IB) - the wired thing: it has a retain count of 2! Any hints why?
UIViewController *c = [[UIViewController alloc] initWithNibName:CellIdentifier bundle:nil];
GroupCell *cell;// = [[[GroupCell alloc] init] autorelease];
cell = (GroupCell *) c.view;
[c release];
NSDictionary *groupDict;
NSLog(@"retain count of groupCell: %d, ", [cell retainCount] );
retain count of groupCell = 2!!
my cell has no init method, no "retain" nor do I send anywhere a retain to it..

Answer 1

Hey Alex!
sommeralex wrote:
I am creating a customViewCell in my UITableViewController (which I was creating in IB) - the weird thing: it has a retain count of 2! Any hints why?
Your code is obtaining the retain count by sending the [retainCount|http://developer.apple.com/library/ios/documentation/Cocoa/Referen ce/Foundation/Protocols/NSObjectProtocol/Reference/NSObject.html#//appleref/doc/uid/20000052-BBCDAAJI] message, so this warning in the doc applies:
Important: This method is typically of no value in debugging memory management issues. Because any number of framework objects may have retained an object in order to hold references to it, while at the same time autorelease pools may be holding any number of deferred releases on an object, it is very unlikely that you can get useful information from this method.
I think the above is telling us that retainCount returns an accurate number, but that number is useless because we don't know how many releases are pending. E.g., suppose your code has released an object prematurely, so your logical count should be zero. However, if the runtime system has retained the object 5 times at that stage, retainCount will return 5. The point is that all 5 of those retains will be released at some future time not of our choosing.
You can override retain and release to keep your own count, but I don't know if that count is any more useful than what you get from retainCount.
I think the only retain count that's any of our business is the number of retains and releases we see in our code. In other words, I think the logical count is much more useful than the real count:
UIViewController *c = [[UIViewController alloc]
initWithNibName:CellIdentifier bundle:nil]; // Line A: +1
GroupCell *cell;
cell = (GroupCell *) c.view; // Line B
[c release]; // Line C: -1
NSLog(@"retain count of groupCell: %d, ", [cell retainCount] );
Based on the doc for the ['view' property of UIViewController|http://developer.apple.com/library/ios/documentation/UIKit/Ref erence/UIViewControllerClass/Reference/Reference.html#//appleref/doc/uid/TP40006926-CH3-SW2], the view object should be created and retained once when the nib is loaded in Line A (except if no view object is included in the nib, in which case the view would be created and retained once in Line B). The view would then be released once when the view controller is released in Line C.
So using my arithmetic, the view's retain count is zero after Line C. If that's correct, the only thing saving you from a crash might be one of those system retains we don't know about. You could test my analysis by not giving the view to a table view, then checking to see if it still exists at some point after the end of the current event cycle. You could implement dealloc with a NSLog statement in your custom view to see if and when the view is actually freed.
Absent any further analysis, I would advise retaining and autoreleasing the view before releasing the controller (or just autoreleasing the controller), to make sure the view lasts until retained by your table view.
- Ray