Those familiar with the Mac OS dock will know that clicking the dock icon of a minimized application will restore that application to it’s pre-minimized state. This is a nice little feature as the minimize/tray area of the dock can quickly become a disorganized mess if you keep a lot of apps open. Those familiar with developing AIR apps will also know that AIR apps don’t do this out of the box. This kinda sucks.

Fortunately there is a fairly easy way to implement this feature for yourself. All you need to do is setup two event listeners and two properties.

The two properties you need are “isMinimized” and “isMaximized”. Both are booleans, the first indicating the application is … drumroll … minimized and the section maximized. While you could get away with just one of these having both offers more flexibility in the future should you need it. For example: it is possible for an app to be neither maximized nor minimized.

The two events you need to listen for are NativeWindowDisplayStateEvent.DISPLAY_STATE_CHANGING and InvokeEvent.INVOKE. The first event is dispatched when the application’s display state changes (i.e., when maximized or minimized). The second is dispatched when the dock icon is clicked.

With those few things all you need to do now is a few start up things:

/**
 * Event handler for the application's creationComplete event
 */
private function init():void
{
         // Check to see if we have a dock available for clicking
         if (NativeApplication.supportsDockIcon)
         {
               // Wire up a listener for the dock icon's invoke event
               NativeApplication.nativeApplication.addEventListener(InvokeEvent.INVOKE, onDockIconClick);
         }

         // Effectively, listen for minimize and maximize event.
         this.addEventListener(NativeWindowDisplayStateEvent.DISPLAY_STATE_CHANGING, onChanging);
}

/**
 * Event handler for display state change events
 */
private function onChanging(event:NativeWindowDisplayStateEvent):void
{
      switch (event.afterDisplayState) // <-- our new state
      {
	case "minimized":
		isMaximized = false;
		isMinimized = true;
		break;

	case "maximized":
		isMaximized = true;
		isMinimized = false;
		break;
	}
}

/**
  * Called when the dock icon is clicked.
  */
private function onDockIconClick(event:InvokeEvent):void
{
	if (isMinimized)
	{
		// If the app is minimized call this
		stage.nativeWindow.restore();
		isMaximized = true;
		isMinimized = false;
	}
}

In the above code it’s assumed that init will be called by the app’s creationComplete event. init then checks to see if the platform on which the app is running supports dock icons (that is, is Mac OS). If it is we add an event listener for the InvokeEvent which is dispatched when the app’s dock icon is clicked. After that init wires up a second event listener, this time listening for the NativeWindowDisplayStateEvent.DISPLAY_STATE_CHANGING event. This event is dispatched when the app is minimized or maximized.

onChanging is our event handler for the display state change event. We use this method to keep track of whether our app is maximized or minimized. onDockIconClick is our event handler for the app’s InvokeEvent that will be dispatched when the dock icon is clicked. This method checks to see if the app is currently minimized, and if it is it calls the window’s restore method.

Adobe AIR is a great tool for quickly creating cross platform desktop applications.  For the most part you can code once and deploy on any OS that AIR supports and you app will look and feel like a native app.  There are a few caveats of course and one of them is working with menus.  In particular menus are handled somewhat differently in Mac OS than they are in Windows. This post won’t get into the nitty gritty of actually creating and modifying menu items as that is covered quite nicely in Adobe’s documentation on the subject, but I will tell you how to create native menus on Mac OS that are indistinguishable from those of native Mac apps.

First, the Differences

In Windows menus belong to each window. So File, Edit, View and such are items in each open window of an application. In AIR this corresponds to the menu property of a NativeWindow.

In Mac OS the corresponding menu is called an application menu and there is only one for all windows of the application. In AIR this corresponds to the NativeApplication’s menu property.

So what you say? AIR has features that let you handle Windows vs. Mac menu differences quite easily. This is true, a quick check of the docs will reveal how quickly this can be accomplished. However, you’ll notice in the above screen grab that application menus on Mac OS list the application name in bold. There is nothing in the AIR docs about how to accomplish this.

What To Do?

You can just ignore this and create a menu like the (quite nice) SQLite administration tool Lita. Note Lita has “Lita” in the menu but it’s not bolded.

Or you can not even bother with the application name like the (also extremely useful) MonsterDebugger.

Both of these approaches are completely valid. After all both Lita and MonsterDebugger are incredibly useful applications that make my life as a developer much easier and lacking a proper Mac OS application menu doesn’t detract from their utility in any way. However it’s also quite simple to create application menus that look identical to a true native application.

Creating Seamless Application Menus For Mac OS

It’s so simple to create seamless application menus on Mac OS that you don’t even have to do anything! That’s right, just create an application and AIR makes one for you:

Everything you see above you get for free (note: adl is the AIR debugger. If I were to publish a release build and install the application you’d see the name set in the application descriptor xml file). You might now be saying that this is all good and well but what if you want to customize the menu at all? The good news is you can, it just take a tad more work.

To start you’ll need to note that AIR gives us three menu items in addition to the “Application Name” item (the bold one). For this example I’ll assume you’re only interested in keeping the app name item so we’ll just get rid of everything but that one.

First you’ll need to get a reference to the application’s menu:


// Get a reference to the NativeApplication's menu, if this is Mac OS
// Note: you'll need to handle menus differently if you are on Mac OS or Windows.
// See the AIR docs related to creating native menus for details.
if (NativeApplication.nativeApplication.supportsMenu)
{
var appMenu:NativeMenu = NativeApplication.nativeApplication.menu;
}


If you were to loop over this you’d see all of the menu items from the above screen grab. You’ll also notice that each of the items is a NativeMenuItem (more on this later). Since we only want the first one we can now remove all the others:


// Get rid of our unwanted menu items
// The app name item is the first one
while (appMenu.items.length > 1)
{
menu.removeItemAt(menu.items.length - 1);
}


At this point our menu consists of one item: the application name menu item. This menu item is pre-populated with some standard elements like “About” and “Quit”. If you’re happy with this as-is, you can now freely add your own menu items. If you need to customize this application name menu item a bit simply take advantage of the fact that it’s a NativeMenuItem and go nuts.

Using this method you’ll now see your application’s name (that is, the name you set in the application descriptor xml file) up in bold when you publish a release build and install. Here at BKWLD we’ve recently used this technique and here are the results:

I recently learned that  the http spec suggests browsers only open two simultaneous connections to a given subdomain at a time.  I haven’t tested to see how widely adopted this is.  Though I have noticed in Safari, looking at the activity viewer, that if the page requests many large assets (like a flash audio player where the user has advanced through tracks quickly), file requests start to queue up.  In a recent blog by Campaign Monitor, they mention that they server images from multiple subdomains at a time so the web browser opens up more connections at time.  You don’t even need multiple servers.  You could wildcard the subdomains on your webserver and serve up a unique subdomain.  As pointed out on Stack Overflow, you don’t want to choose a completely random subdomain on every request or the browser can’t cache the image.  It’s a pretty extreme optimization technique , though something to keep in your toolbox.

From here.