How to Use Application Delegates in iOS App Development
The primary job of the Application Delegate object is to initialize the iOS application and present its initial window. This delegate is also notified (by the UIApplication object) when specific application-level events occur, such as when the application needs to be interrupted (because of an incoming message) or moved to the background (because the user touched the Home button).
User-interface events are handled differently, however. Rather than going through an Application Delegate, the Application object takes each incoming UI event and routes it to the object (known as a Responder) containing the view on which the action occurred. To do so, the Application object monitors its window’s current status (such as whether it’s in the foreground or the background).
A window in iOS is an instance of a class named UIWindow. Because iOS applications are limited to a single window, a UIWindow object has a limited role in iOS. This window occupies the entire screen and doesn’t interact with the user, so it doesn’t have a title, controls, or other adornments — such as scroll bars.
A UIWindow contains a hierarchy of view objects (instances of UIView or its subclasses). At launch time, an application creates its window and adds its views, either by executing code written by the developer of the app or by interpreting its storyboard.
Although a Window object doesn’t interact with users, it plays an important role in drawing its views and distributing events to these views.
Think of the window as being at the root of a hierarchy of views, with views higher in the hierarchy enclosing other views. When a window becomes active (because an app comes into the foreground), the Window object displays the app’s content by going down the view hierarchy, asking each view in turn to draw itself inside the view in which it’s contained.
A window distributes incoming events to the most appropriate views in its hierarchy using action messages. For example, for touch and gesture events, the recipient of the action message (and its contained event) is the view touched by a user’s finger. For events like keyboard events that have no target, the recipient is whichever view is the first responder.
The first responder is the object that should be asked first to respond to the event. For example, when you click in a text box, focus is set on that view, and it becomes the first responder and starts responding to keyboard events. The single UIWindow is in charge of assigning and keeping track of the first responder.
The figure below shows the class hierarchy for windows, views, and responders. To find more about windows and views, check out Windows and Views.
A chain of responders is behind the designated first responder. If the first responder can’t handle an event, the event is forwarded to the next responder in the chain. The message travels up the chain, toward higher-level objects, until it reaches the UIWindow object. If it isn’t handled there, the app discards it.
In most cases, the responder chain consists of views. However, when a designated view controller is managing a view, the view controller becomes the next responder in the chain.