Adobe AIR Programming: Working with Windows - Advanced / Page 2 | WebReference

Adobe AIR Programming: Working with Windows - Advanced / Page 2


Adobe AIR Programming: Working with Windows - Advanced [con't]

Understanding Window Events

An event-based programming model is used to interact with NativeWindows, so let's take a look at what happens when an event takes place before we get into any specific operations.

For some NativeWindow operations, there are two associated events. The first dispatched event notifies you that something is about to happen, allowing you the opportunity to interject with a callback function. The second event tells you that something has already happened.

You'll have to register a listener with that particular window instance to handle these events. The listener catches any of the events and allows you to execute logic using a callback function. In other words, "when object xyz dispatches a certain event, execute this particular function I've defined."

Suppose a user clicks the Close button of a window. An event is dispatched to notify listeners that a window is about to close, giving our application a chance to react. We might want to prompt the users to save their work if they haven't done so already. If the users choose to save, we'd first invoke the necessary functionality to save, and after that's done, trigger the window to close. If our users don't want to save their work, our callback function logic simply does nothing, and the window closes. Now, a second event is dispatched signaling that the window has finished closing.

Listing 5.5 shows an example in which we add event listeners for both Event.CLOSING and Event.CLOSE on an instance of mx.core.Window.

LISTING 5.5 Exploring Window CLOSE and CLOSING Events

Event.CLOSE will not fire from mx.core.Window. You must listen to its parent NativeWindow to be notified of the event. This is because the Adobe Flex context is destroyed after the CLOSING event fires and is unavailable to dispatch the final CLOSE event.

Canceling a Window Event

Often you'll need to intercept an event and invoke conditional logic to determine whether you want that event to continue, such as in the example cited earlier in Listing 5.5. In that example we're simply tracing a message to the output console, but in the real world, you may want to prompt users that their work isn't currently saved and ask if they want to do so.

Listing 5.6 outlines how to interrupt the closing sequence by catching the CLOSING event and calling preventDefault() on the event object. This stops the event in its tracks. In this example we're only doing this if isWorkSaved is false, indicating the user has attempted to close the application without saving his or her work.

Our Alert dialog makes a callback to onAlertClose, upon which time we act on the users' decision to save their work. When that has been done, we can simply call the close() method on our Window. We're also calling exit() because this is our main application Window we're closing. If we didn't call exit(), the Window would close but the application process would still be running, so it's important to keep that in mind!

Here's how we could add to our example in code Listing 5.5:

LISTING 5.6 Cancelling a Window CLOSING event

If you are using a custom window chrome, then it will be up to you to programmatically dispatch the CLOSING and CLOSE events.

Creating Custom Window Chrome

Adobe AIR projects generated from the New Flex Project Wizard in Adobe Flex Builder output a default MXML file with a root tag called WindowedApplication. As outlined earlier in this chapter, this gives your application a standard native window as expected.

What if a project calls for a truly customized window chrome, such as a fully branded look and feel that includes custom icons for window controls and a nonrectangular shape?

No sweat—this can be accomplished by the following steps:

  1. Set the window chrome to none and the transparency to true in the application's descriptor file (see Listing 5.6).
  2. On WindowedApplication set the showFlexChrome to false.
  3. Create a Canvas with an embedded background image (optional).

In Listing 5.6 we've changed the chrome and transparency properties in the application descriptor, which prevents Adobe AIR from opening a visible default Window when the application is launched. This, in combination with setting the showFlexChrome to false in our application code (see Listing 5.7) delivers the desired effect.

LISTING 5.7 Modifying Window Properties in the Application Descriptor File

Embedding an image as your application's background is completely optional. At this point you literally have a blank slate to work with inside your Adobe Flex application. You can use a circular or square background image or perhaps draw your application background yourself via the ActionScript drawing APIs, it's up to you. See Figure 5.10.

In Listing 5.8 we've opted to simply embed a bitmap image and used that as the background. In addition we've included a drop shadow filter on the Canvas that gives a floating perspective to the application.

LISTING 5.8 Creating a Window with Custom Chrome in Adobe Flex

There is a little added work going this route because you have to create your own mechanisms for standard window controls such as minimize, maximize, and so on. In Listing 5.7 we've added listeners on our window control images and explicitly, via the event handlers, initiatied the desired window behavior.


We've explored how to create windows onscreen using both the flash.desktop.NativeWindow and mx.core.Window classes. In essence mx.core.Window is just a wrapper for the NativeWindow class, making it ready to host elements of an Adobe Flex application.

As for the look and feel of your application windows, the sky is the limit. If the standard operating system chrome won't do the trick, then you can build your own customized chrome from scratch.

Adobe AIR Programming Unleashed

This chapter is an excerpt from the book, Adobe AIR Programming Unleashed by Stacy Young, Michael Givens and Dimitrios Gianninas, published by SAMS, ISBN 0672329719, copyright 2009 by Pearson Education, Inc. All rights reserved.

Original: March 9, 2009