While coding always the same questions concerning retain counts of IBOutlets came along: Retain count after unarchiving an object from NIB? When to use #property's for an IBOutlet? Retain or assign while setting? Differences between Mac and iPhone?
So I read The Nib Object Life Cycle from Apple's documentation. Some test apps on Mac and iPhone gave me some strange results. Nevertheless I wrote down a few rules how to handle this issue to stay happy while coding but now wanted to verify with the community and listen to your opinions and experiences:
Always create an IBOutlet for top-level objects. For non-top-level objects if necessary (access needed).
Always provide a property as follows for IBOutlets (and release them where necessary!):
Top-level objects on Mac:
#property (nonatomic, assign) IBOutlet SomeObject *someObject;
#synthesize someObject;
[self.someObject release];
Non-top-level objects on Mac (no release):
#property (nonatomic, assign) IBOutlet NSWindow *window;
#synthesize someObject;
Top-level objects on iPhone (must retain):
#property (nonatomic, retain) IBOutlet SomeObject *someObject;
#synthesize someObject;
[self.someObject release];
Non-top-level objects on iPhone (should retain):
#property (nonatomic, retain) IBOutlet UIWindow *window;
#synthesize window;
[self.window release];
Side notes:
On Mac and iPhone outlet connections are made with a setter if available.
Top-level objects: "have [...] no owning object"
Non-top-level objects: "any objects that have a parent or owning object, such as views nested inside view hierarchies."
So the question would be: is this correct and good practice?
I hope you can approve or correct it.
Always have your nibs' File's Owner be a subclass of NSWindowController or NSViewController (on Mac OS X) or UIViewController (on iPhone), and use #property (retain) IBOutlet for all of its outlets, doing appropriate releases in your controller subclass -dealloc method.
This pattern will work fine on both Mac OS X and iPhone OS, because NSWindowController and NSViewController on Mac OS X take implicit ownership of top-level objects for you (and relinquish that in their own -dealloc methods), and iPhone OS doesn't take any implicit ownership of top-level objects for you during nib loading.
Top-level objects: "have [...] no owning object"
Nix. Top-level objects are owned by the File's Owner, which is the File's Owner because it owns all the top-level objects in the file.
Windows have that option to release themselves as a convenience, but I find my design cleaner (even if it's a little more work) when I either turn it off and manage its lifetime myself, just like any other object I own, or use a window controller.
If you think this conflicts with the documentation you were quoting, let's go through the entire paragraph:
Objects in the nib file are initially created with a retain count of 1. As it rebuilds the object hierarchy, however, AppKit autoreleases any objects that have a parent or owning object, such as views nested inside view hierarchies.
Thus killing off its own ownerships. The nib loader doesn't want to own your objects.
By the time the nib-loading code is done, only the top-level objects in the nib file have a positive retain count and no owning object. Your code is responsible for releasing these top-level objects.
In other words, it's handing the ownership over to you.
The curious artifact of that is that you'll actually leak the object if your property to it has retain semantics. The documentation says you should retain it:
For both Mac OS X and UIKit, the recommended way to manage the top-level objects in a nib file is to create outlets for them in the File’s Owner object and then define setter methods to retain and release those objects as needed.
But if you do this, the object will remain alive even after you release your ownership of it.
I think I'll go file a bug about this. (Edit: Done. x-radar://problem/7559755) At the very least, the nib loader shouldn't be handing off two retentions, which it does in my test app (on 10.5.8 and 10.6.1).
From apple's doc mentioned above:
For both Mac OS X and UIKit, the recommended way to manage the top-level objects in a nib file is to create outlets for them in the File’s Owner object and then define setter methods to retain and release those objects as needed. Setter methods give you an appropriate place to include your memory-management code, even in situations where your application uses garbage collection. One easy way to implement your setter methods is to create a declared property (using the #property syntax) and let the compiler create them for you. For more information on how to define properties, see The Objective-C Programming Language.
Otherwise use #property(nonatomic, retain) IBOutlet * outletName;
I can write my opinion about iPhone NIB development:
If you use IB then use as many IBOutlets as possible (sometimes you don't know the views hierarchy when you build a NIB - it may be dynamic) or don't use them at all - otherwise there will be a mess
Use properties only if you want to access the views from outside the View Controller (if they should be public)
AFAIK there's no need to manage memory for IBOutlets
Hope it helps...
You should follow standard memory management guidelines. If your outlet is connected to a retained property, then you must release it in the -dealloc message.
And yes, you any top level objects not retained by any other objects usually need to be retained by yourself.
1) In general, why would you have a top-level object with no IBOutlet to point to it anyway? That requirement has never seemed very restrictive.
2) I think you got the settings about right for the iPhone. You can also use an assign property on the iPhone as well, which does what you would expect... but in general after a lot of use I prefer to use retain properties so I am 100% clear on when I consider the object released (especially with the viewDidUnload method to implement).
Also, just as a side note it's not good form to call [self.property release]. That leaves the reference intact but potentially invalid, if something else ever also releases the object... either say self.property = nil, or (better) set the underlying class variable to nil directly without using properties in dealloc statements (to avoid any possible side effects in dealloc).
As I mentioned in response to another poster, you can keep things clean by using IBOutlet properties declared in private class-local category extensions so they are not public properties. That looks like:
// in .m file
#interface MyClass ()
#property (nonatomic, retain) IBOutlet UIView *myPrivateView;
#end
#implementation MyClass
#synthesize myPrivateView;
.....
Related
I have dilemma about Memory releasing IBOutlet object.Do anyone please suggest what to do when we create IBOutlet object without property, need to release it?? if need to release... why we are releasing it
The answer is YES.
The runtime connects the objects to IBOutlet using [setValue:ForKey:]. This function will find the private instance variables, retain the target and set it to the instance variable. Please visit here iOS Developer Library to know more.
I highly recommend you to read the article because many iOS framework accesses properties by Key-Value compliance ([setValue:ForKey:] or [valueForKey:]), instead of directly calling getters/setters/instance variables.
IBOutlet does not change the ownership semantics of properties. If you do not use ARC you have to release retained objects as with any other property.
Just Set it to default, which is "Weak". Then you are fine with ARC.
Why not just have a private IBOutlet property, to make things clearer and more explicit. I always do this personally:
MyClassName.m
#interface MyClassName ()
#property (nonatomic, weak) IBOutlet NSObject *myPropertyNameForAnOutlet;
#end
#implementation MyClassName
...
#end
You are not the owner of that object. so no need to release IBOutlet object.If you are using #property (nonatomic, retain) on IBoutlet object then you must release that object in dealloc.
Take a look at Advanced Memory Management Programming Guide
You must not relinquish ownership of an object you do not own
Answer is YES...
i was confused about that too, but try this:
open a xib file
onen assistant editor window and get the .h file code near your XIB IB file
chose an object in IB file (an object with no reference to any var)
ctrl click on it and chose: "new reference outlet" button
drag the line to your .h code file in the #interface{ } section
give a name to your new var ("aaa")
(note that no property "aaa" is created)
now Xcode has done all the magic for you, and...
in .m file you can find, in dealloc method:
- (void) dealloc {
[aaa release];
[super dealloc];
}
so... if apple release it, it seems that the default IBOutlet vars loaded via XIB file are retained...
EDIT:
here's the point in apple doc:
You are not the owner of the object, therefore you do not release it.
You become the owner by retaining, copying or creating (init/alloc) an object. Only then you are you (one of the) owner(s) of the object, and need to release it when you are done with the object. Fore more info check
Cocoa core competencies - Memory Management
I hope this explains why you do not have to release the object.
Even though you didn't set it as property, the property is refer to setter and getter methods. When you use an object you should always remember to release it. The property is unrelated with memory issue.
Weird discovery, when I used a drag and drop to make a new IBOutlet, as shown below, not with a #property at all:
#interface SkinChoosingView : UIViewController {
IBOutlet UIActivityIndicatorView * activityIndicator;
}
Xcode inserted a -release and set the outlet to nil in viewDidUnload. I looked in viewDidLoad though, and no -retain was there! This went against everything I know about memory management.
I figure apple must know a thing or two about this stuff though, so is there something behind the scenes happening here? I have never had leaks from these types of IBOutlets, and I've never released them.
Yes, it automatically retains the outlet for you when loading the NIB file unless you explicitly declare the property associated with the outlet as an assigned property.
And since it retains the outlet for you, you must release in viewDidUnload as the outlets will be reloaded by the time next viewDidLoad is called.
The answer is that it uses "Key-Value Coading", which means it calls -setValue:forKey:, which has a "Default Search Pattern". For ivars, it does something like [ivar autorelease]; ivar = [newvalue retain];.
The "current best practice" is to stick IBOutlet on properties instead of ivars (see here). This makes it obvious what memory management pattern is being used and is more resilient to typos (e.g. if you misspell the ivar).
I'm using Interface Builder to build my rootViewController, which is retained by my application delegate. I have a few controls in this XIB such as a couple UIButtons, a UISlider, etc. as IBOutlets, hooked up properly in Interface Builder.
On the code implementation side of the XIB, I've seen some people use:
#interface RootViewController : UIViewController {
IBOutlet UIButton *button1;
IBOutlet UIButton *button2;
...
}
#property(nonatomic, assign) UIButton *button1;
#property(nonatomic, assign) UIButton *button2;
#end
Why do they use assign instead of retain? I've seen some people not even use an assign property.
Is it pointless to use retain since the rootViewController's XIB will always contain a reference to them as long as it is loaded? Or are they just being lazy and not going through the steps to retain, synthesize & dealloc? Seems to me like it can't hurt to keep a reference around as long as the control is needed and the viewController hasn't been dealloc'ed, but just wondering if XIB's do something differently where this wouldn't be necessary.
I've read the memory management guide, btw.
Thanks!
It cant hurt to keep all subviews as assigned instead of retained as long as they stay a child from there superview.
When you remove it from its superview and want to add it as a subview later on in your code. Thats not possible. When you remove it from its super its retain count will probably turn to zero. Thats one of the reasons why you use retain. Your controller object will then always be a owner of the view object.
I cant think of other reasons you must use retain instead of assign.
I always use retain, i think its a best practice for outlets and it seems to be a convention.
if you have an IBOutlet on an ivar like
IBOutlet UIView *view;
#property (nonatomic, retain) UIView *view;
that object created by ib will be managed by ib,
but what if you have,
UIView *view;
#property (nonatomic, retain) IBOutlet UIView *view;
does ib now use your setter to set that object? that would mean the setter has added +1 and needs to be set to nil or the object would leak?
IBOutlet doesn't do anything in the resulting code — it's literally erased by the preprocessor. It's just there so Interface Builder can scan your header to see which things it should treat as outlets.
Have a read here, a posting by Aaron Hillegass about some of this.
On the desktop, when a nib file is loaded, outlets are set in a sensible way: to set an outlet called foo, the nib loader looks for an accessor called setFoo:. If it is unable to find the accessor, the nib loader sets the variable foo directly. This sounds like key-value coding, right? It isn’t. The important difference is that nib loading treats foo as a weak reference; the object it points to is not retained.
Thus, if you create a subclass of NSViewController that has a dozen outlets to subviews, only the top-level view is retained. So, when the view controller is deallocated, it releases the top-level view and all the subviews are automatically deallocated. Tidy!
On the phone, however, the nib loader uses key-value coding to set the outlets; By default, outlets are treated as strong references. If you don’t have an accessor for your outlet, the view it refers to is retained.
It both cases you must release the outlet. If you have a property IB will use it and let you manage the retain or not (if you use assign). If you do not have a property IB will assign the value but retain it automatically, which you need to then release.
If you mark the property as an IBOutlet you don't need to also mark the class variable as an IBOutlet.
AFAIK, it doesn't matter if you put the IBOutlet on the ivar or the property. Either way, in general, IBOutlet properties should be (nonatomic, assign), and not retained, as the NIB loader handles all of that.
In most examples I see the following setup of IBOutlets:
(Example A)
FooController.h:
#interface FooController : UIViewController {
UILabel *fooLabel;
}
#property (nonatomic, retain) IBOutlet UILabel *fooLabel;
#end
FooController.m:
#implementation FooController
#synthesize fooLabel;
#end
But this works also fine (notice: no property and no synthesize):
(Example B)
FooController.h:
#interface FooController : UIViewController {
IBOutlet UILabel *fooLabel;
}
#end
FooController.m:
#implementation FooController
#end
Are there any downsides of defining IBOutlets as in Example B? Like memory leaks? Seems to work fine and I prefer to not expose the IBOutlets as public properties as they are not used as such, they are only used in the controller implementation. Defining it in three places without a real need does not strike me as very DRY (Don't Repeat Yourself).
On Mac OS X, IBOutlets are connected like this:
Look for a method called set<OutletName>:. If it exists call it.
If no method exists, look for an instance variable named <OutletName>, set it without retaining.
On iPhone OS, IBOutlets are connected like this:
call [object setValue:outletValue forKey:#"<OutletName>"]
The behavior of set value for key is to do something like this:
Look for a method called set<OutletName>:. If it exists call it.
If no method exists, look for an instance variable named <OutletName>, set it and retain it.
If you use a property, you'll fall into the "Look for a method called set<OutletName>:..." case on both platforms. If you just use an instance variable, then you'll have different retain/release behavior on Mac OS X VS iPhone OS. There's nothing wrong with using an instance variable, you just need to deal with this difference in behavior as you switch between platforms.
Here's a link to full documentation on just this topic.
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/CocoaNibs.html#//apple_ref/doc/uid/10000051i-CH4-SW6
On Mac OS X, IBOutlets are not retained by defaults. This is the opposite of the behavior on iPhone OS: on iPhone OS, if you don't declare a property it is retained and you must release this property in the dealloc method. Additionally, the 64-bit runtime can synthesize instance variables using property declarations. That means that someday the instance variables (with the IBOutlet) may be omitted.
For these reasons it is more homogeneous and compatible to create always a property and use the IBOutlet only in the property. Unfortunately, it is also more verbose.
In your first example you always have to release the outlet in the dealloc method. In your second example you must release the outlet only with iPhone OS.
The end result is exactly the same, but you have to keep a few things in mind:
When using instance fields as outlets, you should NOT release them in dealloc.
When using properties that have the (retain) attribute, you have to release the property in dealloc (using self.property=nil or by releasing the backing variable). This makes it a lot more transparent as to what's going on.
Actually it all comes down to the same old rule: "thou shalt release what you alloc/retain". So in case you use an instance field as outlet, you didn't alloc/retain it, so you shouldn't release it.
Its possible that those examples use the retain because the sample code is programmatically allocating and initializing a UILabel and then adding it to the UIView. That's the case for many examples, since learning how to use Interface Builder is often not their point.
The second example (no property and no synthesize) with the IBOutlet is used when the developer 'assigns' the UILabel (Button, View, etc) within the Interface Builder -- by dragging the IBOulet to the Label or other View component. In my opinion, the preceding drag and drop action (Label onto View) also add the subview, the Label to a View -- and so on. Label is retained by a View; a View is retained by Window; Window is retained by File's Owner. File's Owner is usually your Document that is booted up in main.
You will note that when you step through your program (by adding an awakeFromNib
- (void)awakeFromNib
{
[fooLabel blahblah];
}
that fooLabel already has a memory address.
Thats because the Label was initialized from a file bundle (the nib file) using not init but initWithCoder. Which essentially deserializes the filestream to an object - and then sets the IBOutlet variable. (We're still talking about the IBOutlet method).
Also note that the aforementioned iOS method uses the Key Value method
call [object setValue:outletValue forKey:#"<OutletName>"]
which is the Observer/Observable pattern. That pattern require the Observable object reference each Observer in a Set/Array. A change in value will iterate the Set/Array and equally update all Observers. That Set WILL already retain each Observer thus the lack of retain in iOS.
Further and the rest is speculation.
It seems that cases when you do use Interface Builder then
#property (nonatomic, retain) IBOutlet UILabel *fooLabel;
should possibly be changed to
#property (nonatomic, weak) IBOutlet UILabel *fooLabel;
or
#property (nonatomic, assign) IBOutlet UILabel *fooLabel;
And then it needn't be released in a dealloc method. Plus it will satisfy the OSX and iOS requirements.
That's based on logic and I could be missing some pieces here.
Nevertheless, it may not matter if the view is persistent through the life of your program. Whereas a label in a modal dialog box (open, close, open, close) may in fact have over-retained and leak per cycle. And that's because (speculation again) each closed dialog box is serialized into a file system and thus persists x,y position and size, along with its subviews, etc. And subsequently deserialized ... on the next session open (Opposed to say minimiz or hidden.)