You are currently browsing the category archive for the ‘AIR’ category.

I recently discovered something interesting trying to implement a REST API call in an AIR application.

When you load a URL request in Flex, you usually listen for complete, I/O error and security error events on the loader. However, I’ve learned that it’s important to also listen for HTTP response status events when loading a URL request in AIR.

Otherwise you might not receive a response when the result is anything other than success (200). Instead, you’ll receive an I/O error: “Error #2032: Stream Error.”

Consider the following sample code:

var loader : URLLoader = new URLLoader ();

loader.addEventListener (Event.COMPLETE, onComplete);
loader.addEventListener (IOErrorEvent.IO_ERROR, onIOError);
loader.addEventListener (SecurityErrorEvent.SECURITY_ERROR,
    onSecurityError);

// AIR-only!
loader.addEventListener (HTTPStatusEvent.HTTP_RESPONSE_STATUS,
    onHTTPStatus);

loader.load (request);


No action is required in the onHTTPStatus() method above. As long as you are listening for the event, you will always receive a response.

When you’re developing an AIR application it’s useful to be able to quickly save information to a file. Especially when it comes to things like tracking the memory usage of an application over a period of time.

This doesn’t require anything fancy. Here’s an example of a simple log() method that either writes or appends to a file called “Output.log” on the desktop:

public function log (text : String, clear : Boolean = false) : void
{
    var file : File = File.desktopDirectory.resolvePath
        ("Output.log");
    var fileMode : String = (clear ? FileMode.WRITE :
        FileMode.APPEND);

    var fileStream : FileStream = new FileStream ();
    fileStream.open (file, fileMode);

    fileStream.writeMultiByte (text + "\n", File.systemCharset);
    fileStream.close ();
}


It’s easy to modify an example like this to allow for different file names and paths. It’s also easy to append timestamps or other identifying information.

In short, quick and simple. :-)

Something is definitely awry with system tray menu events on Windows.

All native menu objects in AIR dispatch a “displaying” event immediately before they are displayed. This gives you the ability to update the menu. It also prevents potential issues that could occur if you try to update a native menu that is currently displayed.

However, when I attempt to listen to this event on the native menu I’ve assigned to the system tray icon, the system tray icon no longer appears in my AIR application.

Take away the event listener and the system tray icon appears. Add it back and the system tray icon disappears. It’s unbelievably strange.

Alternatively, all of this functionality works as expected in dock menus on Mac OS X. It is only an issue with the system tray menus on Windows.

To take it a step further, I’ve discovered that listening to any event on the native menu assigned to the system tray icon causes this behavior. I can listen to events on the system tray icon itself, but not on its menu (or any submenus).

As a result, I’ve been forced to modify the native menu arbitrarily when one or more of the menu items needs to change. However this introduces an entirely new (and rather unfortunate) issue- repeatedly right-clicking on the system tray icon to activate the context menu will eventually cause a general protection fault (GPF). :-(

So I can either try to handle menu changes properly, and as a result lose access to the system tray icon entirely -OR- I can forgo the events and just modify the menu whenever the hell I feel like it, knowing that it will eventually cause the app to crash.

Balls.

I’ve noticed that when I create multiple Window top-level containers in an AIR application, the memory they consume never appears to be garbage-collected, even after the windows are closed and their references destroyed.

This may be an unusual problem, since most AIR applications simply make use of the WindowedApplication container for their initial (and only) window.

For now, the only workaround available is to simply reuse AIR windows instead of closing them – which means the memory leak is only as bad as the maximum number of windows I need to have visible at once.

Where’s free() when you really need it? :-)

Follow

Get every new post delivered to your Inbox.