A window object presents graphical content in a rectangular area of the screen and plays a role in the distribution of events. This object, which inherits from UIWindow
on Cocoa Touch and NSWindow
on Cocoa (Mac OS X), represents a window appearing in an application. Window objects (or, simply, windows) are essentially containers of views, and have major responsibilities related to the drawing and event handling performed by those views.
A window is at the root of a hierarchy of views, with uppermost views in the hierarchy enclosing other views. When a window displays its content, it proceeds down this hierarchy, asking each view in turn to draw itself in the context of its superview. The view at the top of the hierarchy is the content view. The content view occupies the entire drawing area of the window, serving as the backdrop for all other views in the window. (For UIWindow
objects this content view is the window itself.)
The coordinate system of windows, called the base coordinate system, is related to its role in presenting content. All drawing performed by views in a window ultimately makes reference to the base coordinate system. However, a window itself is positioned and sized on the screen using the screen’s own coordinate system. The window classes define methods for converting between a view’s local coordinate system and the base coordinate system.
A window distributes incoming events to the views in its hierarchy that are the most appropriate recipients of those events. For mouse events, touch events, and similar events, that recipient is the view that is under the mouse pointer or under the finger touching the view. For key events and action messages that have no target, the recipient is the first responder—that is, the object first given a chance to respond to the event or message. A window is in charge of tracking the first responder.
Although windows in Cocoa Touch and Cocoa share these general responsibilities, they have different characteristics and behaviors. The differences derive from the different user environments—that is, a desktop system versus a handheld device with limited screen area. The different user environments lead to different usage patterns and requirements.
A UIWindow
object is a special view with a limited role (as compared to a NSWindow
object). Although iOS applications can technically have more than one window, with one layered on top of another, by convention they are limited to a single window. The window occupies the entire screen and, because it has no title, controls, or other adornments as do windows on Mac OS X, it cannot be manipulated by the user. At launch time an application either creates this window and adds its views, or it loads window and views from a nib file. After you display the window, you rarely need to refer to it again.
A window represented by an NSWindow
object has two major parts: a frame area and a content view. The frame area, which is composed of private views, surrounds the entire window area and draws the window's border, title bar, and items in the title bar, such as the close button, the miniaturize button, and the title. It also includes a resizing triangle in the lower-right corner. The content view occupies the area enclosed by the frame area and is the root of the hierarchy of views for the window.
A window object on Mac OS X can have several different statuses:
Main or key window: A main window is the primary focus of user actions for the application. A key window is the current focus for keyboard events (for example, it contains a text field the user is typing in). Different windows in an application can have main and window status. A window can have both main and key status at the same time.
Active or inactive window: Active windows are the current focus of user attention. If a window is inactive, it draws itself differently to indicate this status. Users must click it to make it active again. If the application itself is inactive, its windows are inactive.
Applications in Mac OS X can have multiple windows. With a document-based application, each document has its own window. In addition to an application’s main window (or windows), all applications may have secondary windows or panels for actions such as selecting colors or setting application preferences. NSPanel
objects (or, simply, panels) represent secondary windows that support an application or document in some way. They can become the key window, but never the main window and are usually removed from the screen when the application becomes inactive. An application may also run a window modally, restricting input to that window until the user completes a task.
A window also has a level and a Z-order, which are maintained by the operating system. A level is a subset of windows of a particular functional type. The levels themselves are hierarchically arranged so that, for example, modal windows are displayed above floating windows. All windows currently onscreen or offscreen are in a specific front-to-back order that is affected by each window’s level. A window’s position in this list is its Z-order.
Last updated: 2010-07-07