iOS What on earth is an AppDelegate?

[glossywhite]

Okay folks - I think it better to be ignorant and ask questions, than to not ask them, so here goes:

What on earth is an AppDelegate, why do you need one, what does it do, why does it do it, and how... etc?.

I am struggling getting to grips with the abstract concepts of Objective C, and this is one MAJOR sticking point - could someone draw me a diagram, and please, for goodness sake, explain it in a 'real world' analogy, which has NOTHING to do with code, as giving me an explanation *relative* to other code, will just blow my mind.

Thanks people.

 

[robbieduncan]

It's an application delegate. That is a delegate (a helper object that takes reponsibility for, or aids in, some of the tasks an object is responsible for) to the UIApplication object. It is normally used to perform tasks on application startup and shutdown, handling URL open requests and similar application-wide tasks as described in the documentation.

Delegation is a key Cocoa design pattern and is covered in the Cocoa Fundamentals guide (I have linked directly to the delegate section) which you should read and understand all of before even thinking about writing anything.

 

[admanimal]

Sorry, I'm going to use code-speak, but that's the simplest way to explain an AppDelegate.

Basically it works like this: there are important events in the life of your application that happen out of its direct control. These include things like launching and terminating. Your application needs to know when these things happen or are about to happen, so the iPhone OS will automatically notify your AppDelegate by calling the appropriate method (e.g. applicationDidFinishLaunching, applicationWillTerminate). That's the main purpose of the AppDelegate. This lets you do initialization/cleanup of your app at the right time. There are also other things that it can be notified of, which you can find in the documentation.

 

[glossywhite]

So basically the delegate is responsible for monitoring when it is safe to open/close things, terminate the app etc, and it talks to the application, and gives it accurate & critical information, with regards to how & when to do these tasks?.

The only way I can imagine it, is a security guard who is called by the staff inside a building, and asked if it is safe to open the security door; he can answer YES or NO.

 

[jacksongan]

Sorry, I'm going to use code-speak, but that's the simplest way to explain an AppDelegate.

Basically it works like this: there are important events in the life of your application that happen out of its direct control. These include things like launching and terminating. Your application needs to know when these things happen or are about to happen, so the iPhone OS will automatically notify your AppDelegate by calling the appropriate method (e.g. applicationDidFinishLaunching, applicationWillTerminate). That's the main purpose of the AppDelegate. This lets you do initialization/cleanup of your app at the right time. There are also other things that it can be notified of, which you can find in the documentation.

halo, can u please take a look at this hello world app, http://www.youtube.com/watch?v=gxDDvwbHT2M, there is no delegate in the code, i wonder y?

Y some app need delegate and some dun need? Please advise.

Thanks.

 

[admanimal]

So basically the delegate is responsible for monitoring when it is safe to open/close things, terminate the app etc, and it talks to the application, and gives it accurate & critical information, with regards to how & when to do these tasks?.

I think you sort of have it, but your communication is backwards. The AppDelegate just sits there doing nothing, waiting to be told that something potentially important has or will happen. The application/iPhone OS is the one doing the work and calling the AppDelegate when it has or will do something that the AppDelegate (and by extension, you) might want to respond to in your code. Here is a complete scenario:

(Starting at the iPhone's home screen)
1. A user taps on your app's icon.
2. The iPhone OS loads your app into memory and whatever else it needs to run your app. At this point, the OS has control.
3. The iPhone OS finishes its launch procedure with your app, and is ready to hand over control to it.
4. The OS calls your AppDelegate's applicationDidFinishLaunching method.
5. Your code is now in control, starting with whatever is in the applicationDidFinishLaunching method of your AppDelegate.
.
. (User uses the app for a while)
.
6. User taps on the Home button to quit your app.
7. Since your app has no direct way of knowing when the Home button is tapped, the iPhone OS sends an applicationWillTerminate message to your AppDelegate, so you can clean up any open files, etc. before the app quits.

There are also other notifications that your AppDelegate can receive between launching and quitting, such as if your app is about to run out of memory.

 

[admanimal]

halo, can u please take a look at this hello world app, http://www.youtube.com/watch?v=gxDDvwbHT2M, there is no delegate in the code, i wonder y?

Y some app need delegate and some dun need? Please advise.

Thanks.

You can clearly see in the XCode window right after he creates the project that it does have an app delegate (Hello_WorldAppDelegate). He just never modifies it because his simple app doesn't need any special initialization or cleanup code. Most nontrivial apps will need to modify it.

 

[jacksongan]

I think you sort of have it, but your communication is backwards. The AppDelegate just sits there doing nothing, waiting to be told that something potentially important has or will happen. The application/iPhone OS is the one doing the work and calling the AppDelegate when it has or will do something that the AppDelegate (and by extension, you) might want to respond to in your code. Here is a complete scenario:

(Starting at the iPhone's home screen)
1. A user taps on your app's icon.
2. The iPhone OS loads your app into memory and whatever else it needs to run your app. At this point, the OS has control.
3. The iPhone OS finishes its launch procedure with your app, and is ready to hand over control to it.
4. The OS calls your AppDelegate's applicationDidFinishLaunching method.
5. Your code is now in control, starting with whatever is in the applicationDidFinishLaunching method of your AppDelegate.
.
. (User uses the app for a while)
.
6. User taps on the Home button to quit your app.
7. Since your app has no direct way of knowing when the Home button is tapped, the iPhone OS sends an applicationWillTerminate message to your AppDelegate, so you can clean up any open files, etc. before the app quits.

There are also other notifications that your AppDelegate can receive between launching and quitting, such as if your app is about to run out of memory.

this is such a good explanation, those books have way too much abstract ideas and i found jargons on every single page, it's tough but it's satisfying when my knowledge keep increasing every now n then.

Thanks.

 

[glossywhite]

I think you sort of have it, but your communication is backwards. The AppDelegate just sits there doing nothing, waiting to be told that something potentially important has or will happen. The application/iPhone OS is the one doing the work and calling the AppDelegate when it has or will do something that the AppDelegate (and by extension, you) might want to respond to in your code. Here is a complete scenario:

(Starting at the iPhone's home screen)
1. A user taps on your app's icon.
2. The iPhone OS loads your app into memory and whatever else it needs to run your app. At this point, the OS has control.
3. The iPhone OS finishes its launch procedure with your app, and is ready to hand over control to it.
4. The OS calls your AppDelegate's applicationDidFinishLaunching method.
5. Your code is now in control, starting with whatever is in the applicationDidFinishLaunching method of your AppDelegate.
.
. (User uses the app for a while)
.
6. User taps on the Home button to quit your app.
7. Since your app has no direct way of knowing when the Home button is tapped, the iPhone OS sends an applicationWillTerminate message to your AppDelegate, so you can clean up any open files, etc. before the app quits.

There are also other notifications that your AppDelegate can receive between launching and quitting, such as if your app is about to run out of memory.

So, basically, the delegate is a little bit like a babysitter - sits there 99% of the time, dormant and redundant, but if the child says "I need food", babysitter (delegate) responds with either:

1/ Yes you can have some food (if the child has had no food).

or

2/ No, you have had enough to eat.

From my understanding, the delegate only provides information and acts upon situations, if polled to do so?...

this is such a good explanation, those books have way too much abstract ideas and i found jargons on every single page, it's tough but it's satisfying when my knowledge keep increasing every now n then.

Thanks.

I concur - a fantastic explanation - sticky material!.

 

[admanimal]

So, basically, the delegate is a little bit like a babysitter - sits there 99% of the time, dormant and redundant, but if the child says "I need food", babysitter (delegate) responds with either:

1/ Yes you can have some food (if the child has had no food).

or

2/ No, you have had enough to eat.

From my understanding, the delegate only provides information and acts upon situations, if polled to do so?...

Sort of, but the AppDelegate is more passive than this. For example, the AppDelegate is told that the application will terminate; it has no choice or control over the situation, it is just being given a chance to clean up before the app inevitably quits.

So in your babysitter analogy, it's more like the child says to the babysitter "I just ate" and then the babysitter can go clean up the mess if they want, or not.

 

[firewood]

Cocoa does a few things backwards from the old common way of programming.

Instead of your program telling the OS what to do, the OS tells your program what to do.

The delegates are known function names which the OS calls to tell your program when it's time to do something.

For instance: Your program doesn't draw graphics when it wants. It only tells the OS that it wants to draw. Then the OS calls your drawRect methods when it is good and ready, and then you can draw. Those are view delegates.

Your program doesn't tell the OS when it wants to quit. Instead the OS calls an application terminate delegate telling your app that it better clean up because it is going to quit ASAP.

That's an well known (to the OS) application level method, so it's an app delegate.

etc.

 

[dejo]

Cocoa does a few things backwards from the old common way of programming.

True. It uses a paradigm called "event-driven programming" vs. the older way, which was called "batch programming". More here...

 

[glossywhite]

Sort of, but the AppDelegate is more passive than this. For example, the AppDelegate is told that the application will terminate; it has no choice or control over the situation, it is just being given a chance to clean up before the app inevitably quits.

So in your babysitter analogy, it's more like the child says to the babysitter "I just ate" and then the babysitter can go clean up the mess if they want, or not.

Cocoa does a few things backwards from the old common way of programming.

Instead of your program telling the OS what to do, the OS tells your program what to do.

The delegates are known function names which the OS calls to tell your program when it's time to do something.

For instance: Your program doesn't draw graphics when it wants. It only tells the OS that it wants to draw. Then the OS calls your drawRect methods when it is good and ready, and then you can draw. Those are view delegates.

Your program doesn't tell the OS when it wants to quit. Instead the OS calls an application terminate delegate telling your app that it better clean up because it is going to quit ASAP.

That's an well known (to the OS) application level method, so it's an app delegate.

etc.

BRILLIANT analogies!. I can feel the mental fog lifting with every post; clarity is enhanced as I absorb more, so please do carry on. I think I'm going to draw us a diagram of how I interpret this, so you can tell me if I am correct or not.

Thanks for the time folks - appreciated a LOT.



[EDIT] This is how I perceive what you have taught me - please correct me: