What is the AppDelegate for and how do I know when to use it?

Question

I'm just beginning to work on iPhone apps. How do I know when I should be putting stuff in AppDelegate versus a custom class? Is there a rule or any type of analogy with another programming language like Python or PHP that uses an AppDelegate like pattern?

Ilion

Answer 1

I normally avoid the design approach implied by Andrew's use of the term "heart of your application". What I mean by this is that I think you should avoid lumping too many things in a central location -- good program design normally involves separating functionality by "area of concern".

A delegate object is an object that gets notified when the object to which it is connected reaches certain events or states. In this case, the Application Delegate is an object which receives notifications when the UIApplication object reaches certain states. In many respects, it is a specialized one-to-one Observer pattern.

This means that the "area of concern" for the AppDelegate is handling special UIApplication states. The most important of these are:

• applicationDidFinishLaunching: - good for handling on-startup configuration and construction
• applicationWillTerminate: - good for cleaning up at the end

You should avoid putting other functionality in the AppDelegate since they don't really belong there. Such other functionality includes:

• Document data -- you should have a document manager singleton (for multiple document applications) or a document singleton (for single document applications)
• Button/table/view controllers, view delegate methods or other view handling (except for construction of the top-level view in applicationDidFinishLaunching:) -- this work should be in respective view controller classes.

Many people lump these things into their AppDelegate because they are lazy or they think the AppDelegate controls the whole program. You should avoid centralizing in your AppDelegate since it muddies the areas of concern in the app and doesn't scale.

Subsolar

+1 This is an excellent answer. I was looking at some sample code that had subviews call the appDelegate do to instruct a view controller to switch to a different subview, and that felt like a code smell. Good to know my nose still works. – Toms

sometimes we see something like this in tutorials online: AppDelegate* del = [AppDelegate sharedAppDelegate]; (see developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/…) what does that mean? i can see examples of using it but i don't really understand the theory behind it (see this example:developer.apple.com/library/ios/#samplecode/…) – Gherardi

Answer 2

Your application delegate is the heart of your application. It's effectively your "Program Controller".

The Application Delegate is the class that receives application-level messages, including the applicationDidFinishLaunching message most commonly used to initiate the creation of other views.

While not exactly similar you could think of it as the "main()" routine of your Cocoa program.

Escorial

I'm giving +1 to you because having all your UI controllers in the AppDelegate is less of a hassle than creating all those custom classes for it. – Hambrick

@Hambrick be carefull, separating your concerns helps for cleaner code and it is less of a hassle to debug, you should take the time to create those custom class and not put all your observers in a single file. – Intort

Answer 3

@Shivam, thanks.

From what I understand of appDelegate, is close to what an Application is in Android. The viewDidLoad, viewDidDisappear is comparable to what Android's Lifecycle. Every application has a life cycle, from launching to interruptions from calls coming in, to notifications showing up. If you need your code to do something special when these system events occur then you need to write code the methods.

In Android we use onPause, onDestroy, onCreate kinda callback methods to handle such system events.

Eslinger

The onPause, onCreate and onDestroy methods of Android are more similar to the viewDidDisappear, viewDidLoad methods of an iOS View Controller's lifecycle. If you have to compare, I would say the Application class of Android would be closer to the AppDelegate of iOS. – Itch

Thanks, if you can better my answer please do. I'll delete my answer after reading yours. – Eslinger

Answer 4

Hope this will help a little more ...

Programmers new to this language always have the same question - does the program start from a main method? Yes, you are right in this case; IOS apps also start from a main method.
Your main class calls the below function:

 UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class])); 

UIApplicationMain kicks off the Cocoa Touch run loop and app infrastructure which creates a UIApplication object. Our application needs content so objective-c uses a delegate to handle this. That's why we call it AppDelegate (act as delegate of UIApplication). We implement some of the optional methods of that delegate and it behaves accordingly.

Pelasgian

please can someone make me understand whts wrong in above answer – Pelasgian

It seems confused because a) you don't use proper punctuation/spelling/grammar, b) it is off-topic as it doesn't really answer the question the original poster asked. – Lighter