views:

58

answers:

2

I am curious if there is a good reason I should / should not be using @synthesize for the tabBarController below, or does it not matter?

@implementation ScramAppDelegate
@synthesize window;
@synthesize tabBarController;

-(BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {    
    [self setTabBarController:[[UITabBarController alloc] init]];
    [window addSubview:[tabBarController view]];
    [window makeKeyAndVisible];
    return YES;
}

-(void)dealloc {
    [tabBarController release];
    [self setTabBarController: nil];
    [window release];
    [super dealloc];
}

OR

@implementation ScramAppDelegate
@synthesize window;

-(BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {    
    tabBarController = [[UITabBarController alloc] init];
    [window addSubview:[tabBarController view]];
    [window makeKeyAndVisible];
    return YES;
}

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

cheers Gary

A: 

If tabBarController is a property(declared in your .h file with @property (nonatomic, retain) TabBarController *tabBarController), and you want to automatically create getter and setter methods for it, you should use @synthesize in your .m file. If you want to implement the getter and setter yourself, you must specify @dynamic tabBarController.

luvieere
It is only necessary to use the @dynamic directive if you are not using @synthesize _and_ you are not implementing your own getters and setters immediately—for example, if Core Data will be creating them for you for modeled properties. If your .m file contains getters and setters with the appropriate names and types, you need not use either @synthesize or @dynamic.
Seamus Campbell
+1  A: 

I personally don't bother with @propertys for my view controllers in my application delegate class. Mainly because the app delegate sits at the top of the view hierarchy, and it doesn't need to expose its member variables to anyone.

Another reason not to comes from the line:

tabBarController = [[UITabBarController alloc] init];

Since if tabBarController is a @property set to retain, you'll double-retain the object, which is a form of memory leak (although relatively benign since it happens at the app delegate level).

Shaggy Frog
I was thinking the same about the memory leak which is why I did [tabBarController release]; and [self setTabBarController:nil]; in dealloc. By my way of thinking that results in the correct management of memory, although it is slightly academic, dealloc never gets called as the applications frees all its memory on exit anyways.
fuzzygoat
The problem is you've `retain` ed it twice (`alloc` increments the retain count, and then your property is set to `retain`, so the generated setter will increment that count a second time), so if you're releasing it once and then setting it to nil, you will create a memory leak.
Shaggy Frog
so the retain count is 2, after the release its 1, after the set nil its released again (now its 0) and nil is retained?
fuzzygoat
Why bother using a @property if you're just going to work around its back to cover for your double-retain? It's definitely non-standard, hard for another Cocoa developer to read (since you're not using conventions) and prone to memory leaks unless you're very careful.
Shaggy Frog
Hi, that is very true, and I certainly see your point about it being a fix for something that seems to make little (or even no) difference. Thank you for your time, answer and comments. Its much appreciated.
fuzzygoat