Event processing

What actually happens when the user taps something to cause an event? The event is processed. The functionality provided in the UIKit framework manages most of the application's infrastructure. Part of the initialization process mentioned in the previous section involves setting up the main run loop and event handling code, which is the responsibility of the UIApplication object. Here's a rundown of how such events drive a process inside the app:

1. You have an event - the user taps a button, for example.
   The touch of a finger (or lifting it from the screen) adds a touch event to the application's event queue, where it's encapsulated in - placed into, in other words - a UIEvent object. There's a UITouch object 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.
   My advice to you: Don't let your eyes glaze over here. This UIEvent and UITouch stuff is important.
2. The run loop monitor dispatches the event.
   When there's something to process, 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 an event happens (when the user touches the screen, for example). Responder objects can include instances of UIApplication, UIWindow, UIView, and its subclasses (all which 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. Setting it up this way enables you to use standard button objects without having to muck about in their innards - just tell the button what method you want invoked in your view controller, and you're basically set.
   Processing the message may result in changes to a view, or a new view altogether, or some other kind of change in the user interface. When this happens, the view and graphics infrastructure takes over and processes the required drawing events.
4. You're sent back to the event loop.
   After an event is handled or discarded, control passes back to the run loop. The run loop then processes the next event or puts the thread to sleep if there's nothing more for it to do.