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

Question

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.

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.

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

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.