Home / iPhone Tips and Tutorials

---

Handling events while your application is executing

Most events sent to an application 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 RTAppDelegate) all inherit from UIResponder. After pulling an event off the event queue, the application 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 application, and the application's delegate - until the event is either handled or discarded if it is not handled.

The following list provides the chronology of what actually happens when the user taps something.

1. You have an event - the user taps a button, for example.
   The touch of a finger (or the lifting of a finger from the screen) adds a touch event to the application'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 you can track individual touches. As the user manipulates the screen with his or her fingers, the system reports the changes for each finger in the corresponding UITouch object.
2. The run loop monitor dispatches the event.
   When something occurs that needs to be processed, the eventhandling 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 an event happens (when the user touches the screen, for example). As mentioned previously, responder objects can include instances of UIApplication, UIWindow, UIView (and any of the subclasses) and UIViewController (and any of its subclasses). All these classes inherit from UIResponder.
3. 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 view controller, and you're basically set.
   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.
4. Your application then returns to the run loop.
   After an event is handled or discarded, application 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 application it not alone on the device, it can be interrupted by a phone call, SMS message, or the user touching the Home button. When your application is interrupted, there are some things you'll have to take care of before control is switched to another application.