ios Responder chain - how does a View capture an event?

Question

according to https://developer.apple.com/library/ios/documentation/General/Conceptual/Devpedia-CocoaApp/Responder.html , "If a view is managed by a view controller and if the view cannot handle an event, the view controller becomes the next responder"

What is meant by this statement? It is possible for a View to internally define a handler for an event and capture it intrinsically? If this is not the case the ViewController for the view will be called if it has explicitly defined a handler for the event?

It seems contrary to the MVC pattern for the View to handle events - or is the documentation really saying a handler on a controller specific to the View is invoked?

Answer 1

There is a responder chain, formed by each UIResponder's nextResponder() :

1. The UIView that we start with.

2. If this UIView is a UIViewController's view , that UIViewController. (This is what the passage you quoted is saying.)

3. The UIView's superview.

4. Go back to step 2 and repeat! Keep repeating until we reach...

5. The UIWindow.

6. The UIApplication.

7. The UIApplication's delegate.

Certain messages are sent, not so much to a particular object, but up the responder chain. We start with a particular object, but if that object doesn't have an implementation for the method, we don't crash; instead, we walk the responder chain, looking for someone further up the chain who does have an implementation for the method. Moreover, if we never find such an implementation, we do not crash; the message falls off the end of the chain without penalty.

There are two chief messages of this sort:

• Touch events.

• Nil-targeted actions.

As to your question, what does this have to do with MVC...? Nothing. As Josh Gafni's answer rightly says, MVC is not the only pattern in the world. This is about responders, not about MVC.

Answer 2

UIView actually already has event handlers that you can overwrite. You can subclass UIView and handle touch events using the following methods:

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event;
- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event;
- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event;
- (void)touchesCancelled:(NSSet *)touches withEvent:(UIEvent *)event

There are two ways of communication between the View and View Controller. In general, the View Controller typically tells the View what to display, and the View tends to call delegate methods when events occur. I do understand though that you would typically expect these event handlers to be called by the View but handled in the View Controller. But...

1. You get these methods for free along with a UIView and they are specifically related to the View.
2. You can view these as lower level delegate methods that are closer to the View
3. Say you had 2 pieces of static content and any time the user touches the View the content flips. Yes, you could (and some people would say should) separate between View and View Controller, but this is such a simple bit of code and so directly related to the View that it might actually be less confusing and more concise to keep it together.
4. There are other design patterns than MVC, and Apple does not necessarily need to provide tools for just one design pattern solely.