Does an IBOutlet needs to be a property & synthesized?

Question

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).

Answer 1

On Mac OS X, IBOutlets are connected like this:

1. Look for a method called set<OutletName>:. If it exists call it.
2. If no method exists, look for an instance variable named <OutletName>, set it without retaining.

On iPhone OS, IBOutlets are connected like this:

1. call [object setValue:outletValue forKey:@"<OutletName>"]

The behavior of set value for key is to do something like this:

1. Look for a method called set<OutletName>:. If it exists call it.
2. 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

Answer 2

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.

Answer 3

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.

Answer 4

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.)