Why UIViewController is a subclass of UIResponder?

Question

What's the purpose for making UIViewController a subclass of UIResponder? Was it done solely to pass the rotation events?

I could not find any definitive info on that in the docs.

Update

I understand that if something is made a UIResponder, this something is suppose to be included in the responder chain and process events. But I have two gnawing doubts.

1. As far as I know, UIViewController is put into the responder chain right after its view. Why do we need a view controller in the responder chain at all? Its view is already there, so why don't we let the view process the events that were not handled by its subviews?
2. OK, I'm ready to agree that we might need this. But I would like to see some real life examples, when processing events in a view controller is really needed and is the best/easiest/most appropriate way to do something.

Answer 1

I think your problem may simply be a failure of object oriented thinking.

Per the docs:

The responder chain is a linked series of responder objects to which an event or action message is applied.

In UIKit the view controller sits in the responder chain between its view and the view to which the controller was pushed. So it is offered any event or action that its views don't handle.

The topmost view controller's next responder is the window, the window's next responder is the application, the application's next responder is the application delegate and the application delegate is where the buck stops.

Your question "Was it done solely to pass the rotation events?" applies the incorrect test; it implies that at some point the responder chain had otherwise been fully engineered and somebody thought 'oh, wait, what about rotation? Better chuck the view controllers into the chain'.

The original question will have been: is it helpful if events or actions can be handled by the view controller if none of the views handle them? The answer should obviously be 'yes' as — even on a touch-screen device — there will be events or actions that aren't inherently related to a view.

The most obvious examples are those related to physical inputs other than the screen. So device rotation is one. Key presses on a bluetooth keyboard are another. Remote controls are a third. The accelerometer is a fourth.

The next most obvious example is any system-generated events or actions that should go to the single most local actor rather than to everyone. In iOS that's generally requests for a more specific actor, like the most local undo manager or the identity of the input view to show if focus comes to you.

A slightly less obvious example is that exemplified by UIMenuController — a pop-up view that posts a user-input event that may need to traverse several view controllers to get to the one that should act on it. iOS 5's child view controllers increase the number of possibilities here enormously; quite often you're going to have one parent view controller with the logic to do a bunch of things and children that want to pass messages up to whomever knows how to handle them, without hard coding the hierarchy.

So, no, view controllers weren't added to to the responder chain just to handle rotation events. They were added because logically they belong to be there based on the initial definition of the responder chain.

Answer 2

This is going to sound like a glib answer, but it really isn't. UIViewController is a subclass of UIResponder so that is can respond to user actions (e.g. touches, motion, etc.).

If a view does not respond to an event it is passed up the responder chain giving higher level objects a chance to handle it. Hence, view controllers and the application class are all subclasses of UIResponder

You can find more detailed information about the responder chain in Cocoa Application Competencies for iOS: Responder Object on Apple's developer site.