Why use a property for an application delegate?

Question

I test code that has the appDelegate property in many view controllers.

 @property (nonatomic, unsafe_unretained) TheAppDelegate *appDelegate; 

Leaving aside the design implications of such a connection, is there any benefit, other than convenience, of the appDelegate property compared to retrieving the application delegate:

 TheAppDelegate *appDelegate = (TheAppDelegate *)[[UIApplication sharedApplication] delegate]; [appDelegate someMethod]; 

Answer 1

I also do this sometimes, i.e. declare a property for dependencies that can be obtained using the single-threaded access method:

 @class Foo : NSObject @property(strong) NSNotificationCenter *notificationCenter; @end @implementation Foo - (id) init { self = [super init]; [self setNotificationCenter:[NSNotificationCenter defaultCenter]]; return self; } @end 

The advantage is that you get a weaker connection with addiction. For example, you can easily provide your own mock instance. In some cases, it also makes the code shorter by spelling _notificationCenter instead of [NSNotificationCenter defaultCenter] .

And the third reason that I can think of is that declaring a property makes the dependency explicit: you know, looking at the public API, that the state or behavior of an object depends on the application delegate. Using singleton in a class implementation completely hides this fact.

But if there are many controllers in the application that depend on the application delegate, this is probably just a design flaw.

Answer 2

To answer the question in the frame.

Specific Benefits: -

Pure code - the property is set once (and can be read-only). If you use it more than once

self.appDelegate is easier than extracting appDelegate from a shared application each time. (and easier)

There may be a slight performance advantage (although this is definitely a premature optimization and may not exist depending on the compiler).

I have to agree with CodaFi that it is a little smelly, so there is an intermediate basis for creating syntactic sugar to hide some complexity.

 @class MyAppDelegate; @interface MySharedAppDelegate : NSObject + (MyAppDelegate*) appDelegate; @end #include "MyAppDelegate.h" @implementation MySharedAppDelegate + ( MyAppDelegate*) appDelegate { return (MyAppDelegate*)[UIApplication sharedApplication].appDelegate; } @end 

Answer 3

I prefer to use a macro rather than defining a property in each viewcontrollers as

 #define appDelegate ((MYAppDelegate *)[[UIApplication sharedApplication] delegate]) 

Define this in constants.h and by including the header in the .pch file, I can have this appDelegate in any class in my code.

Answer 4

I like to do this:

 //in .pch file #import "Includes.h" //in Includes.h #import "AppDelegate.h" #define APPDELEGATE() (AppDelegate *)[[UIApplication sharedApplication]delegate] 

Then somewhere I need to ask appDelegate, something that I just say

 [APPDELEGATE() someMethod]; 

Having the AppDelegate property somewhere else seems like a bad idea. I can’t say why, except for already having a simple way to get this link (sharedApplication).

In this case, this is probably just for the convenience of the developer. However, I have to say that the “need” for AppDelegate references everywhere is probably more an indication of spaghetti code and bad encapsulation.

* By the way, I store references to some "global" variables inside appDelegate, which can also be an indicator of poor encapsulation ... that's why I use the APPDELEGATE () expression first ;-)

** Things like NSDateFormatter, which you will need quite often, but not necessarily “live” inside the class (you do not need one for each instance, but can be applied to several instances) or a link to some specific state, for example, “global font size applications "

Answer 5

I do not think this is subjective. The question arises:

are there any advantages besides convenience, the appDelegate property compared to retrieving the application delegate

And I think the answer is no. There is no benefit other than convenience.

Ideally, you do not have (or minimal) communication between your application delegate and the controllers of your kind, so the method you use should not matter much. In the project I'm working on now, I just get a delegate when I need it (this is only 2 places in the entire code base). If you did it in dozens of places, it might make sense to have it as a property, but again, this is purely for convenience.