Why not subclass UIApplication? Why use a delegate?

Question

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?

Flowerless

Small FYI, you can subclass UIApplication and use that subclass in your app by passing it's name to the correct parameter in the main function. – Pew

Answer 1

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.

Vague

Answer 2

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

Nertie

why don't we subclass UIApplication and override the various methods to do those tasks? Is there advantages / disadvantages? – Flowerless

Au contraire, it is even recommended by apple that you subclass, though few do because like @borrrden said: there's no reason to. What could you possibly want to subclass it for? – Nertie

maybe i didn't make it clear... i was wondering why does the iOS architecture not create a template that just subclass UIApplication and override the various methods, but use a separate app delegate instead... – Flowerless

The app delegate used to be a subclass of UIApplication (pre Xcode 4.x), but now it's a subclass of UIResponder, which makes more sense as UIResponder is all about events. So it's more of a historical thing than an actual cover up. – Nertie

@Nertie Default AppDelegate used to be a subclass of NSObject, not UIApplication subclass. Also it had protocol of UIApplicationDelegate. – Tizzy

Answer 3

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.

Lotion

Answer 4

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.

Colotomy

Your answer is longer than many others on StackOverflow and contains valuable information, but I think it is wrong in some regards. For example, I don't believe that performance nowadays is a reason for separation between UI code and database access code. Like you said, separation and modularization is a much better and more rational reason. Also, I don't think overriding UIApplications sendEvent: method as you have done it was really necessary. Because it is a single control you are focusing on, you could just have subclassed that single class and overridden 'touchesBegan:withEvent:' etc. – Julietajulietta

Answer 5

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.

Prying

so I think you mean, if it is a fairly empty class, such as UIView, then subclassing it makes sense. But if it is a very fully implemented class like UIApplication, all we need is a delegate to do particular things at predefined times... that is, if it is a small unknown part, then using a delegate works well – Flowerless

I also just read in the Cocoa Design Patterns book that there might be better encapsulation within UIApplication if we use delegation, because if we subclass it, there is a higher chance that we can contaminate UIApplication – Flowerless

Answer 6

I'll add something no one else mentioned: Delegation removes the need to call super when overriding/augmenting/adding behavior via a delegate method implementation rather than a subclass with an overridden method. I've seen many developers answer their own Stackoverflow question with simply they forgot to call super (after some have even posted possible answers). The newer method decorator NS_REQUIRES_SUPER helps a bit with this by alerting the developer with a warning (hopefully they don't ignore it!) however it doesn't help when the order of the call to super matters. I think Apple decided it was less error-prone to have developers implement a delegate object instead, that has no calling super requirements, and they even did the hard work of forwarding the UIResponder methods from UIApplication on to the delegate object too.

Starlight