iOS Memory leak to fix

[boyplunder]

Hi All,
This is the only memory leak I seem to have left to deal with, but can't for the life of me see what's causing it. [Too many late nights maybe!]

// Load the terms image into a NSData object and then assign it to the UIImageView
UIImage *termImage = [[UIImage alloc] initWithContentsOfFile:[[NSBundle mainBundle] pathForResource:[term imageNAME] ofType"png"]];
self.termView.termImage.image = termImage;

This leak is reported in instruments running in Simulator. [Still waiting for my enrollment to come through, so can't test on iPhone yet.] The code draws the name of an image from a field in a SQlite db and uses the same named image stored in a folder in Resources. Instruments highlights the first line starting 'UIImage...'.

If anyone can chip in with a possible solution, thing to look for, or idea, I would be grateful.

 

[jnic]

Presumably that's a retaining setter, which means you now have two references to termImage. Autorelease the first line.

 

[danielpunt]

Do you release the image?

[termImage release];

 

[boyplunder]

Yes, it is a retain issue and I haven't released it. Well spotted.
Early to bed tonight!

Thanks for your help.

 

[BlackWolf]

Yes, it is a retain issue and I haven't released it. Well spotted.
Early to bed tonight!

Thanks for your help.

btw, instead of autoreleasing you can also use
termView.termImage.image = termImage;
(without the self.), which will be an assignment and nothing gets retained.

 

[PhoneyDeveloper]

Blackwolf, but of course that would be a memory leak unless you do that in an init method. In addition, since it seems he his groping the image property of another object, it probably won't work as you suggest.

 

[boyplunder]

Blackwolf, but of course that would be a memory leak unless you do that in an init method. In addition, since it seems he his groping the image property of another object, it probably won't work as you suggest.

PhoneyDeveloper,
I love your use of the word 'groping'. Makes me think I'm using a less than elegant way of doing this. I did try using an imagenamed approach, but couldn't get it quite right.

I would appreciate any guidance or pointers you may have.

 

[admanimal]

btw, instead of autoreleasing you can also use
termView.termImage.image = termImage;
(without the self.), which will be an assignment and nothing gets retained.

You would be correct if there weren't nested properties there. So if it was self.myImage = termImage versus myImage = termImage then yes, the lack of self. would mean that the 2nd assignment doesn't retain termImage. However, image is not a property of self; it's a property of termView.termImage and presumably termView.termImage -is- going to retain its image property, and there would be a memory leak.

 

[BlackWolf]

Blackwolf, but of course that would be a memory leak unless you do that in an init method. In addition, since it seems he his groping the image property of another object, it probably won't work as you suggest.

yeah, well, I assumed he will release the image afterwards of course

You would be correct if there weren't nested properties there. So if it was self.myImage = termImage versus myImage = termImage then yes, the lack of self. would mean that the 2nd assignment doesn't retain termImage. However, image is not a property of self; it's a property of termView.termImage and presumably termView.termImage -is- going to retain its image property, and there would be a memory leak.

yeah, right, I didn't think of that.

 

[PhoneyDeveloper]

BoyPlunder,

Well-mannered objects don't touch the private parts of other objects.

This is part of good design. Encapsulation. Strictly speaking, the property syntax of Obj-C 2.0 is meant to make it easier to provide encapsulation. Your getter/setter protects the ivars from being, ahem, groped, by other objects. And that's a good thing. They also help developers to get the retain/copy/release memory management code correct.

However, in most cases properties are public and that may invite unwanted touching from other objects. And that's not usually a good thing.

In the example you showed your code was setting the image property of something that was, or could have been, a UIImageView. UIImageView is designed to allow setting of its image property in a public way. Setting the property obviously does other things besides just set an instance variable. It makes the image view redraw itself, for instance. So in your case the setting of the image property was public and was invited, which is ok.

My point is that you should design your classes in such a way that any uninvited setting of properties doesn't screw things up. In fact there's almost always a way to go around any protections that you put in to make things private. The design of Obj-C explicitly lets you send any message to any object and lets you set the ivars on any object so there's a limit to how much you can do to make things private.