views:

666

answers:

2

I'm about to wrap up my first iPhone app and figured I'd run it through the Leaks Performance Tool. After fixing one obvious one, the only one I have left is one with a Nib acting as a table header view loaded through loadNibNamed (I was following the Recipes demo here).


- (void)viewDidLoad {
    [super viewDidLoad];

    if (self.tableHeaderView == nil) {
        [[NSBundle mainBundle] loadNibNamed:@"TableHeaderView" owner:self options:nil];
        self.tableView.tableHeaderView = self.tableHeaderView;
    }
}

Then in dealloc:


- (void)dealloc {
    [tableHeaderView release];
    [super dealloc];
}

Instruments tells me that I'm leaking 256 bytes with 2 leaks coming from the line with loadNibNamed. tableHeaderView is the only top level object in the Nib (I've verified that in the debugger). Is there something I'm forgetting to release? Am I misinterpreting what Instruments is telling me? Is it wrong? Is it something that the OS will clean up later?

A: 

Is Instruments telling you this solely on the Simulator, or is it reporting the same thing on an actual device? If you don't get it on the device, then it's the Simulator - and that's known to happen (it isn't an exact match).

Also, down in dealloc, wouldn't it be [self.tableHeaderView release]? You have to be consistent with your usage.

To avoid confusion, in your .h, you'd declare this:

NS/UI/??xxxxxx *_MyObjectName;   //notice the underscore

Then the Property like this:

@property .... NS/UI/??xxxxxx *MyObjectName;   //no underscore

Then synthesize the getters/setters like this:

@synthesize MyObjectName=_MyObjectName;

Finally, refer to the object throughout the program with [self.MyObjectName ...];

inked
Good question about the device: I'm in the process of setting up my device to actually test it there—I'll update when I have that working.I tried changing the release call in dealloc to use self and there was no change. I thought I'd read somewhere that one was supposed to avoid property sugar in dealloc (although I'm guessing calling it without self wouldn't be any better)? Or was that just setters?
AndrewO
I tend to leave the local version of a property untouched unless I have to (like it is readonly). Otherwise, I always access it with self. I'd suggest looking at Apple's samples, but even the very first learner-app exhibits the same weaknesses. At the very least: if you maintain this discipline, you can, later on, do a Find/Replace to switch it to something else. Be right or be wrong, just do it consistently!Have fun with the device profile. Code signing for release is fun too! Best bet is to use Apple's guide - really.
inked
+1  A: 

When you load a nib, you're responsible for releasing all of the top-level objects in the nib file. Is there anything in that file besides the TableHeaderView?

NSResponder
Nope—I've verified that it's the only top-level object in the nib file.
AndrewO