I have seen the code below written 3 different ways (with regards to IBOutlet) Does it matter, I would say adding IBOutlet to both the declaration and the @property was more con
Should not matter. With the 10.6 64-bit SDK you can also write the property without the ivar:
@class SwitchViewController;
@interface iPhone_switcherAppDelegate : NSObject <UIApplicationDelegate> {
}
@property(nonatomic, retain) IBOutlet UIWindow *window;
@property(nonatomic, retain) IBOutlet SwitchViewController *switchViewController;
@end
I also found this way (without any property declaration):
@class SwitchViewController;
@interface iPhone_switcherAppDelegate : NSObject <UIApplicationDelegate> {
IBOutlet UIWindow *window;
IBOutlet SwitchViewController *switchViewController;
}
@end
What about this?
The current style in Apple's example code puts the IBOutlet in the property declaration. For consistency, that's probably the best place to throw it.
IBOutlet
does only matter to InterfaceBuilder. For the compiler, UINibDeclarations.h #define
s it to nothing.
InterfaceBuilder takes IBOutlet
as a hint from the header file to list the available outlets for the class. If you wire up an object to an IBOutlet
, no matter whether it is defined as a property or instance variable, this information is written into the nib.
When loading the nib, the loader tries to find the best possible way to setup the connection: First it tries to find a setter method with an appropriate name. If no such setter is found, it falls back to setting the instance variable directly, which is poor style, because memory management is not clear this way.
All your proposed examples have a property (and, of course, a setter method) of the right name. So in each case, the loader would use the setter method, no matter where the IBOutlet
tag stands: There’s no difference between your examples, neither in the nib, nor in the way code is executed.
The best style would be to put the IBOutlet
tag into the property definition.