Creating windows in Adobe® AIR applications is a significant departure from traditional webcentric Adobe® Flex development. For starters, Adobe AIR applications run on the user's desktop. So the "windows" we're referring to originate from the underlying native operating system, as with any other desktop software. Web developers no longer need to rely on Adobe Flex
Implementing any kind of windowlike container in Adobe Flex today serves as a reminder of the limitations imposed on the user experience by the browser environment. At first glance, a
TitleWindow resembles the idiom of a "windowed interface," but users soon discover their artificial nature. They cannot be minimized to the taskbar or dragged to a secondary screen as with native windows.
For Adobe Flex Beginners
TitleWindowis a layout container in the Adobe Flex framework (
mx.containers.TitleWindow). It's most often used as a pop-up container. Although it can be moved independent of the underlying Adobe Flex application, its movement is limited to the confines of the browser window.
Windows in Adobe AIR
Coding my first
Window examples in Adobe AIR gave me a warm and fuzzy feeling. Sure, they look and behave like native windows, but the real benefit resides in the application framework itself. All windows of an Adobe AIR application exist in the same context.
For example, picture a main application window designed as a drawing canvas with a second, smaller window off to the side as a floating tool palette. For the drawing canvas to "hear" and react to button click events in the tool palette, such as the user selecting a new drawing tool, an event listener can be added on the tool palette directly from the main canvas.
This is made possible in Adobe AIR by having all windows tied to our application available as an Array in an application scope.
In this chapter, we look at different methods of window creation and where they're applicable in an Adobe AIR application. In addition, we look at moving beyond the default system chrome and investigate what's involved in creating custom window chrome.
Let's start with three window classes available to us in Adobe AIR:
flash.display.NativeWindow—The lowest common denominator in terms of windows in Adobe AIR. Content such as SWFs, images, and HTML can be added to them, whereas other window types wrap this base functionality and offer extended behavior.
mx.core.WindowedApplication—An application container used to house Adobe Flex applications and deliver desktop functionality. This type can only serve as the root window of an application and is configured via the
mx.core.Window—Also a container for housing Adobe Flex content but can be instantiated any number of times. Adobe Flex developers will rely on this type most of the time.
Creating Windows Using
NativeWindow can be used to host an array of content such as HTML, Adobe® Flash® SWF files, or images. It is not, however, intended for use with Adobe Flex components directly. Instead, please refer to "Creating Windows Using
mx.core.Window" later in this chapter.
A special type of
HTMLLoader.createRootContent(), exists specifically for hosting HTML content. It includes the necessary machinery for loading HTML as well as support for scrolling content.
For now let's start with the basics. Here's how to go about creating and configuring a
- Create and configure NativeWindowInitOptions.
- Create an instance of
NativeWindow, passing in NativeWindowInitOptions.
- Open the
Listing 5.1 outlines these steps in ActionScript code. If you have downloaded the source code for this book, then you will find the correlating project in your FlexBuilder called "Chapter05-01".
LISTING 5.1 Creating a
NativeWindow initialization options,
NativeWindowInitOptions, describe the look and behavior of your window. Once set, these parameters are passed into the constructor when instantiating the
NativeWindow instance. These options are not mandatory because they all have default values. For instance, not passing in
NativeWindowInitOptions gives you a standard-looking window for your operating system with standard window controls. As we progress through this chapter, we explore how we can change this default behavior—but keep in mind that after the window is created, these options cannot be changed! Table 5.1 outlines the configurable options.
Let's explore what each of these
NativeWindowInitOptions are and how they affect the characteristics of a new native window. First up is the
systemChrome. The chrome is what frames the content of a native window.
TABLE 5.1 Properties of
||Specifies the type of system chrome used by the window|
||Specifies the type of the window to be created|
||Specifies whether the window can be maximized|
||Specifies whether the window can be minimized|
||Specifies whether the window can be resized|
||Specifies whether the window supports transparency and alpha blending against the desktop|
The frame that encompasses a window is referred to as the chrome. The chrome typically offers controls to manipulate the window, such as minimize, drag, resize, and close.
There are three options for
systemChrome, as shown in the following sections.
This option creates a standard-looking native window as per the operating system the Adobe AIR application is running on (see Figure 5.1). Also, the transparent property of the window must be set to
false (which is the default value). The following snippet demonstrates how to set the
systemChrome to standard, which is also the default value if none is specified.
The standard chrome is managed by the operating system, and your application has no direct access to the controls themselves. You can, however, react to the events that are dispatched as a result of the user interacting with these controls. (See "Understanding Window Events" later in this chapter.)