Understanding Windows and Screens

A window handles the overall presentation of your app’s user interface. Windows work with views (and their owning view controllers) to manage interactions with, and changes to, the visible view hierarchy.

Every app has one window that displays the app’s user interface on an iOS-based device display. If an external display is connected to the device, an app can create a second window to present content on that display as well.

      

The Role of the Window in an iOS App

In an iOS app, windows play a very different role than do windows in a Mac app. In iOS, windows don’t have title bars, close boxes, or any other visual adornments. Users don’t see, close, or move the window of an iOS app. And instead of opening another window to display new content—which is common behavior in Mac apps—an iOS app changes the views inside its window.

The window object—that is, an instance of UIWindow—has several important responsibilities:

• It contains your app’s visible content.

• It plays a key role in the delivery of touch events to your views and other app objects.

• It works with your app’s view controllers to handle orientation changes.

For the most part, you don’t have to do anything to ensure that your app’s window meets these responsibilities. If you use storyboards to create the user interface of your app, the only reason to explicitly create a window object is to support an external device display.

A Window’s Root View Contains Your Content

A window typically has a single root view object—managed by a corresponding view controller—that contains all of the other views representing your content. Using a single root view simplifies the process of changing your interface, because to display new content, all you have to do is replace the root view. The easiest way to install a root view into a window is to use storyboards to define your app’s user interface (to learn how storyboards helps you define your UI, see “Xcode and Storyboards Can Create, Configure, and Load Your Window”).

You can use any view you want for a window’s root view. Depending on your interface design, the root view can be a generic UIView object that acts as a container for one or more subviews, a standard UIKit view, or a custom view that you define. Some standard UIKit views commonly used as root views include scroll views, table views, and image views.

When configuring the root view of the window, you’re responsible for setting its initial size and position within the window. For apps that don’t include a status bar, or that display a translucent status bar, set the view size to match the size of the window. For apps that show an opaque status bar, position your view below the status bar and subtract the status bar height from the height of your view.

Note: If the root view of your window is provided by a container view controller (such as a tab bar controller, navigation controller, or split-view controller), you don’t need to set the initial size of the view yourself. The container view controller automatically sizes its view appropriately based on whether the status bar is visible.

Xcode and Storyboards Can Create, Configure, and Load Your Window

When you base a new iOS app project on one of the Xcode templates and use storyboards to design your user interface, you don’t have to explicitly create, configure, or load your app’s window.

When you create a main storyboard file for your app—and identify it as the main storyboard in yourinformation property list file—iOS performs several setup tasks for you. Specifically, at launch time iOS:

• Instantiates a window.

• Loads the main storyboard and instantiates its initial view controller.

• Assigns the new view controller to the window’s rootViewController property and then makes the window visible.

Before the initial view controller is displayed, your app delegate is called to give you a chance to configure the view controller.

As much as possible, you should use storyboards to specify your app’s user interface (storyboards are not supported on versions of iOS prior to 5.0). If you choose to use nib files instead of storyboards to create your app’s UI, you probably still don’t need to create a window object, because most of the Xcode templates create one for you. (If you do drag a window object into an Interface Builder file, be sure to set its Full Screen at Launch attribute to ensure that the window is sized properly for the target device.)

If you use nib files—instead of storyboards—to create your app’s UI, you need to ensure that the main nib file contents is installed into the window at launch time. To install the main nib file contents into the window you can add to yourapplication:willFinishLaunchingWithOptions: method some code such as the following:

window.rootViewController = myViewController;

In rare cases you might want to create your app’s window programmatically. You would use code something like this to programmatically create a window, install the root view controller, and make the window visible:

- (BOOL)application:(UIApplication *)application willFinishLaunchingWithOptions:(NSDictionary *)launchOptions {

   UIWindow *window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];

   myViewController = [[MyViewController alloc] init];

   window.rootViewController = myViewController;

   [window makeKeyAndVisible];

   return YES;

}

Important: When you create a window programmatically, always set the size of the window to the full bounds of the screen object. In particular, don’t reduce the size of the window to accommodate the status bar or any other items. Because the status bar floats on top of the window, the only thing you should shrink to accommodate the status bar is the view you put into the window. And if you are using view controllers, the view controller should handle the sizing of your views automatically.

NextPrevious