How to Handle Events While Your iOS Application is Executing
Most events sent to an iOS app are encapsulated in an event object — an instance of the UIEvent class. In the case of touch-related events, the event object contains one or more touch objects (UITouch) representing the fingers that are touching the screen.
As the user places fingers on the screen, moves them around, and finally removes them from the screen, the system reports the changes for each finger in the corresponding touch object.
Distributing and handling events is the job of responder objects, which are instances of the UIResponder class. The UIApplication, UIViewController, UIWindow, and UIView classes (and your own AppDelegate) all inherit from UIResponder. After pulling an event off the event queue, the app dispatches that event to the UIWindow object where it occurred.
The window object, in turn, forwards the event to its first responder, designated to be the first recipient of events other than touch events. In the case of touch events, the first responder is typically the view object (UIView) in which the touch took place. For example, a touch event occurring in a button is delivered to the corresponding button object.
If the first responder is unable to handle an event, it forwards the event to its next responder, which is typically a Parent view or view controller. If that object is unable to handle the event, it forwards it to its next responder, and so on until the event is handled.
This series of linked responder objects is known as the responder chain. Messages continue traveling up the responder chain — toward higher-level responder objects, such as the window, the app, and the app’s delegate — until the event is either handled or discarded.
The responder object that handles an event often sets in motion a series of programmatic actions by the app. The following list provides the chronology of what actually happens when the user taps something:
A touch event object is created in response to the user’s tap.
The touch of a finger adds a touch event to the app’s event queue, where that event is encapsulated in — placed into, in other words — a UIEvent object. A UITouch object exists for each finger touching the screen, so that you can track individual touches. As the user manipulates the screen with her fingers, the system reports the changes for each finger in the corresponding UITouch object.
The run loop monitor dispatches the event.
When something occurs that needs to be processed, the event-handling code of the UIApplication processes touch events by dispatching them to the appropriate responder object — the object that has signed up to take responsibility for doing something when a specific type of event happens (when the user touches the screen, for example).
Responder objects can include instances of UIApplication, UIWindow, and UIView (and any of its subclasses), as well as UIViewConroller (and any of its subclasses). All these classes inherit from UIResponder.
A responder object decides how to handle the event.
For example, a touch event occurring with a button in a view is delivered to the button object. The button object handles the event by sending an action message to another object — in this case, the UIViewController object. This enables you to use standard button objects without having to muck about in their internals — you just tell the button what method you want to have invoked in your target.
Processing the message may result in changes to a view, a new view altogether, or some other kind of change in the user interface. When one of these results occurs, the view and graphics infrastructure takes over and processes the required drawing events.
Your app then returns to the run loop.
After an event is handled or discarded, app control passes back to the run loop. The run loop then processes the next event or puts the thread to sleep if it has nothing more to do.
But because your app isn’t alone on the device, it can be interrupted by an SMS message, or the user touching the Home button. When your app is interrupted, you’ll have to take care of some things before control is switched to another app.