View Controller Programming Guide to IOS---(eight)---Using View Controllers in the Responder Chain

Using View Controllers in the Responder Chain

Using the view controller in the response chain

View controllers is descendants of the UIResponder class and is therefore capable of handling all sorts of events. When a-view does not respond to a given event, it passes, it Superview, traveling up the view hierarchy all The to the root view. However, if any view in the chain are managed by a view controller, it passes the event to the View controller object befor E passing it up to the Superview. The this-to-the-view controller can respond to events is not a handled by it views. If The view controller does not handle the event, then the event moves on to the view's superview as usual.

The view controller inherits from the Uiresponder class, so it has the ability to handle all events. In general, when a view does not respond to an event, it passes the event up to its parent view until the root view. However, when the view in the response chain is managed by a view controller, it first passes the unresponsive event to the view controller object instead of its parent view. This allows the view controller to respond and handle various events whose views do not respond.

The Responder Chain defines how Events is propagated to the APP

The response chain defines how events are propagated to the application

Figure 7-1 demonstrates the flow of events within a view hierarchy. Suppose you had a custom view that was embedded inside a screen-sized generic View object, which in turn was managed by R View Controller. Touch events Arriving in your custom view ' s frame is delivered to that view for processing. If your view does not handle a event, it is passed along to the parent view. Because The generic view does not handle events, it passes those events along to its view controller first. If The view controller does not handle the event, the event was further passed along UIView to the superview of the generic Object, which in the the Window object.

Figure 7-1 illustrates the flow of events in a view hierarchy. Suppose you have another custom view that is embedded in a screen-sized normal view object that is managed by the view controller. Touch events passed to your custom view are passed to normal view for processing. If your view does not handle an event, the event is passed to its parent view. Because the normal view does not handle events, it passes those events first to its view controller. If the view controller does not handle the event, then the event is further passed to the parent view of the normal UIView object, in this case the parent view is the Window object.

Figure 7-1 Responder Chain for view controllers

Note: The message-passing relationship between a view controller and its view are managed privately by the view controller and CA Nnot is programmatically modified by your app.

Note: The message passing relationship between a view controller and its views is privately managed by the view controller and cannot be changed manually by the application.

Although you might don't want to handle touch events specifically in your view controller, you could use it to handle motion -based events. You might also use it to coordinate the setting and changing of the first responder. For more information on how events is distributed and handled in iOS apps, see Event HandlingGuide for iOS.

Although you may not want to handle touch events in your view controller, you can use it to handle motion-based events. You might also use it to reconcile (coordinate) settings and change the first responder. For more information on how events are published (distrubuted) and processed in iOS apps, see Event Handling Guide for iOS.

View Controller Programming Guide to IOS---(eight)---Using View Controllers in the Responder Chain