Instead of using an application delegate so that the UIApplication singleton can call the delegate methods at predefined time, what are the advantages and disadvantages of just subclassing UIApplication? (update: why does the iOS architecture use the application delegate instead of letting people write an application by subclassing UIApplication and overriding its various methods?)
That's because when we create a new UIView control, we subclass UIView (update: or we subclass UIViewController too). So why for the case of application, we don't subclass UIApplication but use delegation instead?
Again, from the documentation:
Subclassing Notes
You might decide to subclass UIApplication to override sendEvent: or
sendAction:to:from:forEvent: to implement custom event and action
dispatching. However, there is rarely a valid need to extend this
class; the application delegate (UIApplicationDelegate is sufficient
for most occasions. If you do subclass UIApplication, be very sure of
what you are trying to accomplish with the subclass.
From the UIApplication Class Reference:
The UIApplication class provides a centralized point of control and coordination for applications running on iOS.
Every application must have exactly one instance of UIApplication (or a subclass of UIApplication). When an application is launched, the UIApplicationMain function is called; among its other tasks, this function creates a singleton UIApplication object. Thereafter you can access this object by invoking the sharedApplication class method.
So what do you mean by "why don't we subclass UIApplication? Apple even provides notes on what to implement in subclasses.
As for your question about delegation and singleton use over just standard classes, the answer is simple: An application must provide one common way to recieve and dispatch events (both external and system related), handle multitasking, and interface loosely with the system (that's why main.m includes a reference to your app delegate).
The reason developers usually don't is because there is no need to. UIApplication works as it needs to for the majority of cases. It just needs some hints on what to do in certain predefined cases (which is why it has a delegate). UIView, on the other hand, is very generic and I don't think it is ever used as-is. It is probably the most customized class in all of the iOS world.
Delegation is a core design pattern. It allows for the seperation of responsibilities between parts of your program. The idea is that the part of your program that, for example, draws to the screen probably shouldn't be talking to your database. There are several reasons for this:
Performance: if the same object that draws to the screen access your data store, you're going to run into performance problems. Period. Full stop.
Code maintanence: it's easier to conceptualize code that is properly modularized. (For me, anyway)
Flexibility: If you subclass in your code, that's great - until you start running into monolithic classes that have all sorts of undesired behavior. You'll reach the point where you have to overload behaviors to turn things off, and your property namespace can become polluted. Try categories, delegatation, and blocks for alternatives.
That said, I did indeed run into a situation where subclassing was appropriate. I have a kiosk app in which I wanted to automatically dismiss a certain settings menu if it wasn't interacted with for a period of time. To do so, I had to have access to touch events throughout the entire app. I subclassed UIApplication and overrode sendEvent:. That was appropriate then, although it's an edge case. As king Solomon says in Ecclesiastes, paraphrased: There's a time and place for everything under the sun.
To make it easier to write, read, iterate upon, and maintain your program, it is strongly advised that you follow certain practices. You're welcome to subclass many classes, and Apple won't reject your app for poor code, provided that it runs as advertised. That said, if you don't abide by specific tried and true practices, you're digging your own grave. Subclassing isn't inherently bad, but categories, protocols, and blocks are so fascinating, that I'd prefer them anyway.
There are many specialized things that a UIView subclass might need to do. Think of UIScrollView, UIImageView, UIWebView, etc., and how drastically different their internal workings must be. But still, they must participate in the view hierarchy and so subclassing makes sense.
UIApplication, on the other hand, is a central hub for application-wide events, notifications, opening URLs, accessing windows, and other generic things. Under normal circumstances, an app should really just need to know things that UIApplicationDelegate Protocol will provide.
A note from the UIApplication Overview explains one reason that you might subclass UIApplication:
You might decide to subclass UIApplication to override sendEvent: or sendAction:to:from:forEvent: to implement custom event and action dispatching. However, there is rarely a valid need to extend this class; the application delegate (UIApplicationDelegate is sufficient for most occasions. If you do subclass UIApplication, be very sure of what you are trying to accomplish with the subclass.
But this should only be necessary in very special cases.
