What You’ll Need

To get the beer glass image I used 7 pieces of equipment:

1. A beer
2. A beer glass
3. A coaster (this is optional)
4. Some (cheapie shop) lighting equipment
5. A large piece of white paper and something to prop it up
6. A camera
7. A siphon

Photographing

The setup was to fill the glass with beer and place it and the coaster on the sheet of paper.  The paper was then propped up (I used a wine bottle), turning it into a backdrop.  The lights were setup so I could get some highlights.  The paper being white is important here because I wanted the glass to be transparent and white lends itself to becoming transparent better than say, black.

Once had the scene setup I placed my camera on a tripod and framed the shot I wanted.  It really helps here to have a camera with a manual focus option and to triple check your focus unless you want to drink a few beers through a siphon.  It wasn’t very enjoyable.  Additionally, you’ll want to do this on a stable surface as the goal is to never move the cup at all.

With the stage set I snapped a pic of the full beer glass and then put the siphon in the beer and sucked out a little bit of beer and removed the siphon from the frame.  Rinse and repeat until the glass is empty.  After you have all your images it’s time to get them into Photoshop.

Masking

With your images in Photoshop it’s time to create some masks so we can knockout the beer glass and coaster. One of the nice things about this is that, for the shape we are masking (the beer glass), all of these images are essentially the same thanks to the tripod. So take your time with your masking technique of choice and make a really good mask on one of the images and then copy and paste it into all the other images. You’ll end up with something like this:

Once I had all my images masked I collected them into a single layered file, one image per frame, and cropped the image down to just the glass. This is a good point to save your work.

The next thing to do is add some transparency the to progressively more empty images of the glass. To do this I merged each of my layers with an empty layer. This has the effect of eliminating the mask used to knockout the glass producing a flat image with transparency where the mask was. I then created a new layer mask for each layer and used a brush set to about 25% opacity and 25% hardness to slowly paint over the areas where one would expect to be able to see through the beer glass. I found it helpful to make a screen cap of my desktop and throw it in under all the layers so I could see if the transparency looked good against it.

Creating all these transparencies for the glass is quite time consuming but in the end it creates a very nice effect. Be sure to save the layered file as a PSD so you can come back to it later if need be. At this point you have all your assets and now it’s time to make a decision about how to use them. In my case one of my goals with Beer Near Here Desktop was to create a completely Flex-based solution. Specifically, I wanted the animation I created with the beer glass to be done with Flex so I exported all of the layers out as individual 24-bit PNGs (preserving the nice transparency I worked so hard at creating) and imported them into my Flex project.

These PNGs look great but they also now account for the bulk of BNHD’s file size. An alternative approach is to import the layered PSD into Flash, create the animation there and then import the resultant SWF into your Flex project. This will almost certainly result in a smaller size for the app, which is ideal unless you have other goals like I did.

Before we get started diving into custom chrome you should ask yourself if you really need to use it.  There is a performance cost associated with creating your own custom chrome.  It also takes longer to create custom chrome, so not only will your app be slower, it will take longer to develop.  Additionally (man, I’m really making custom chrome sound like a bad idea, huh?) making a custom skin for your app may decrease usability as you’ll be forcing your users to become accustomed to an interfaces that differs from the standard one their OSes present.

So custom chrome may not be a good idea.  Then again, it can really set your app apart and to I’ve yet to see an AIR app resource-intense enough that the performance penalty for using custom chrome would really matter.  Since you’re reading this you’ve probably already decided to go ahead and use a custom skin for you application so let’s get to it.

The first thing to do is open up your application’s XML descriptor file.  In this file there are two items of interest so far as chrome is concerned:

1. systemChrome and
2. transparent

SystemChrome is a flag that tells your application to either use the “standard” chrome (i.e., the OS’s chrome) or “none”.  Since we want to use custom chrome set this to “none”.

Transparent is a flag that sets your application window to be transparent.  It takes a value of “true” or “false”.  You can only use this when systemChrome is set to none.  If you are going to use an unusual shape for you application, like a beer glass, set this to “true” so you won’t have a square application window floating around.

If you were to run your app at this point you’d see you still have a title bar with maximize, minimize and close buttons.  If you’re going custom you probably want to go all out and make your own title bar, or not as you may not even want a traditional title bar.  The chrome you are seeing now is called “FlexChrome” and to get rid of it you need to make an edit to your application’s MXML file.  In the WindowedApplication tag add an attribute, “showFlexChrome” and set it to “false”:

<WindowedApplication
showFlexChrome="false"/>

When you run your app now you’ll no longer have a title bar or any maximize, minimize or close buttons.  You also can no longer drag your application.  Using system or Flex chrome offers a lot of functionality for free so we’ve got some work to do to get it back.  Beer Near Here Desktop does not support maximizing or minimizing so I’ll only be adding a close button and some drag functionality.  Adding maximize and minimize should work in a similar manner to closing.  But first, we’ll throw in a background so we have something to look at.

The Beer Near Here Desktop application window is exactly 550 pixels wide and 830 pixels tall.  The background beer glass you see when the app loads is 532 pixels wide and 800 pixels tall.  Why the difference?  When you do a search another image is laid on top of the application, dimming it and effectively disabling most of the buttons.  This overlay image is 550×830 pixels.

So the first thing I did was set the width and height for the entire application in the WindowedApplication tag:

<WindowedApplication
showFlexChrome="false"
width="550" height="830"/>

I then added an mx:Image control inside WindowedApplication:

<mx:Image
top="0" left="0"
id="background"
width="532" height="800"
source="images/loading-anim/00.png"/>

Running the app now shows a nice glass of beer.  In fact, get a beer now, it’ll make this more fun.

Okay, I’m back with my beer

So we now have our app running with a custom background image but we can’t move it or close it.  Well, we can close it, but we have to rely on the OS for that rather than the application itself.  For now you can close the app by either right-clicking the application in the Windows start bar or the Mac OS dock and choosing the close command.  Since the background is in place and it’s easy to do we’ll implement some dragging next.

// This drags your application
NativeApplication.nativeApplication.activeWindow.stage.nativeWindow.stage.nativeWindow.startMove();

The above is a nice, long line of Actionscript that will drag your application.  To make use of it you’ll have to import the flash.desktop.NativeApplication package into your application.  To drag the application we are going to listen for the mouse down event on the background image we added earlier.  To handle this we’ll need an event listener:

private function _dragStart(event:MouseEvent):void
{
NativeApplication.nativeApplication.activeWindow.stage.nativeWindow.stage.nativeWindow.startMove();
}

Now that we have our event listener we can wire it up to the background image:

// Add the drag event listener
background.addEventListeners(MouseEvent.MOUSE_DOWN, _dragStart);

This wires the mouse down event to call the _dragStart method thus our app will be dragged so long as the mouse button is held down over the app.  Easy enough, right?  There is one slight catch: this only works if the background image is clicked.  This means that if you place another image on top of the background image like I did with the Beer Near Here logo, clicking in the logo area will not initiate a drag — you’ll have to add a mouse down event listener to this other image (or whatever you added) as well.  There is a nice part to this as well as transparent areas of the background image do not register clicks.  So, while the application window and background image for BNHD are actually rectangular if you click in the transparent part of the application you’ll actually click through to whatever is beneath the application.

Taking stock of the situation we have an application with a custom background image that can be dragged by clicking the background and dragging the mouse.  In the final part of this post we’ll add a close button so we can close the app without relying on the user’s operating system.  To accomplish this with BNHD I created an ImageButton component which can be found in my Flex Library (there is some documentation on this component, hopefully I’ll have a demo soon-ish).

The ImageButton component is very straightforward: you give it an image for the button, an image for the button’s hover state and a function to call when it is clicked.  If you don’t want to use ImageButton you can use any clickable control.  So code for the ImageButton looks like this:

<smorg:ImageButton
id="closeBtn"
image="@Embed('images/close-btn.png')"
hoverImage="@Embed('images/close-hover-btn.png')"
click="_closeApp();"
right="85" top="19"
width="42" height="42"/>

Of interest here is the _closeApp function.  Here’s the function:

private function _closeApp()
{
var exitingEvent:Event = new Event(Event.EXITING, false, true);
NativeApplication.nativeApplication.dispatchEvent(exitingEvent);
if (!exitingEvent.isDefaultPrevented())
{
NativeApplication.nativeApplication.exit();
}
}

This function creates and dispatches an Event.EXITING event.  This announces our intent to close the application.  The function then checks if the event’s default behavior is being prevent, that is, is there something else going on with the app that is preventing us from exiting?  BNHD is simple and this case never comes up, but it’s good to be prepared.  Assuming the default event behavior is not prevented, and it never is, we exit the application.

That’s the basic rundown of how I setup Beer Near Here Desktop.  Now it is a bit more involved but most of the details are rather specific to BNHD so I don’t really think they deserve much attention here with two exceptions.  The first is the loading/searching animation that drains the beer glass.  This was a lot of work and I think it turned out awesome.  This will probably be the topic of the next AIR post.

The second is the loading overlay image I mentioned above.  This overlay ended up serving a purpose beyond my initial intent quite nicely.  Originally I planned simply to use it to dim the background while the app was doing any “thinking” type operations (loading, searching, et cetera) to draw attention to any pop ups.  It does this well enough but by placing well within the app’s MXML file I was also able to use it to effectively disable all the controls in the main app window during any thinking operations.

If you load up BNHD and do a search you’ll see that all of the controls in the main app window become unclickable except for the close button (and, of course, any controls in the popup).  Rather than write a method that enables and disables all these controls I just ordered them within the MXML document such that all of them would be beneath the overlay image except the close button (and popups).  This allows users to exit at any time but not to click buttons they shouldn’t and cause havoc.  Perhaps a useful trick if you plan to do any custom loading overlays or animations with your application.

Until next time.

Read Part 5.

Beer Near Here Desktop makes use of three libraries, all of which are freely available:

1. as3corelib for hashing methods
2. Alex Uhlmann’s Distortion Effects for distortion effects
3. My own Flex Library, available here.

Now there are a number of ways to link these libraries into the BNHD project, but it all pretty much boils down to two methods.  Either I link the project into BNHD’s build path or I copy the SWC that the library produces into BNHD’s build path.  My experience has been that neither of these methods is really better than the other and using one over the other largely depends on the nature of the library itself.

Often when people distribute their Flex code it is in the form of a SWC, so there will be plenty of cases where you’ll simply have to use this method.  In the case of as3corelib, I downloaded the source so that I could disable the packages I didn’t need, but once I compiled a SWC for the project I included that into BNHD’s build path rather than the as3corelib project itself.  As3corelib isn’t going to change beyond my initial modifications and once the SWC is exported I just copy and pasted into into BNHD’s libs folder.  This allows the BNHD project to be more self-contained as it now no longer relies on the separate as3corelib project.  I then repeated all of this for the distortion effects library.

My own personal Flex library is another matter.  It’s very immature with few components and effects so as I work on projects like Beer Near Here Desktop I typically pull out a few of the more useful components and put them into my library.  All this is to say, my library changes fairly frequently.  In this case I’ve found simply adding the project rather than the SWC it produces to be a faster solution.  The downside is that the BNHD project now relies on an external project, so both will have to be present and accounted for in Flex Builder in order to work with BNHD.  Doing this also alleviates the need to continually rebuild my library project during development.

To summarize so far, external libraries, like those listed above should be placed into their own Flex Library Projects.  Any library project that will remain static throughout development should be compiled into a SWC and copied into the main project’s lib folder.  Any library project that will change frequently should be linked into the main project’s build path.  Doing all this will prevent you from spending many minutes (or hours) watching your Flex projects compile all while keeping things nicely organized.  I believe this is called a “win-win”.

The actual Beer Near Here Desktop project organization is very simple.  In the project’s source folder I have three files: main.mxml, main-app.xml and style.css.  The first two are the files that define any AIR app and style.css is the master stylesheet for the entire application.  In the source folder I also have an images folder that contains all of the apps images and net.beernearhere folder that contains all the classes and components and whatnots specific to Beer Near Here Desktop.

I really cannot stress enough how much more efficient Flex Builder became once I started shunting things off into libraries and strongly recommend you do the same if you’re not already.  As for how those projects should be organized, I leave that up to you.  I showed how the BNHD project is setup because I’ll reference it later, but it’s pretty standard and really to each his (or her) own.

Read Part 4.

Beer Near Here Desktop (BNHD) is a very simple app.  All it needs to do is take a location as input and display the results.  As such my feature list is very short:

• Search for beer near a given location
• Display results
• Display app info

This list makes up the core of what BNHD does; nothing more, nothing less.  I told you it was simple.

Additionally I plan to add:

• Printing
• Maps
• Directions

These three features will add some serious utility to BNHD and take the app from being a neat little experiment to a truly useful desktop tool.  These three features are also the most labor-instense and add little toward my personal goals for developing the app so they’re getting put off til a later date.

The real purpose of BNHD is give AIR a spin.  Specifically, I wanted to see how dynamic I could make an AIR application using only Flex — no Flash for animations or anything like that.  I already know I can use Flash to handle animations quite nicely and I’m interested in seeing Flex … errr … flex (sorry) it’s muscle.

So I hinted at animation being one of my “personal” features, to clarify I wanted to have a loading animation that centered around beer.  I also wanted to have a custom skin that really said, “beer”.  These two things definitely needed to come together and, if you’ve used the app you know how.

I also wanted to steal an effect from Apple’s dashboard widgets.  Most dashboard widgets have an info button that flips the widget over like a card to display settings or other information about the widget.  BNHD is really more of a widget than a full-fledged application so I think this effect fits nicely.  Also it’s just cool and a bit of a challenge.

This gives me a list of “personal” features that looks something like this:

• Custom skin
• Loading animation tied into the custom skin
• Flip effect to display app info

I now have my list of features for BNHD, but there is still one more thing to consider.  One of the features for BNHD is “Search for beer near a given location” which cannot be handled entirely within the app.  The reason this cannot be handled locally is because the database BNHD searches is stored on a remote web server so as part of the search I’ll be making a request to a web server which means that, as part of the search feature, I’ll need to consider how this request will be made and handled.

The web server in question is running Drupal so the quick and easy answer is to write a module that handles remote search requests.  I took this a step further by setting up a sub domain of beernearhere.net that exclusively handles remote requests.  Doing this allows me to segregate and better track the traffic on beernearhere.net.  Having a remote client also increases the likelihood of some kind of hack or exploit since I’m relinquishing some control by creating a remote client that is installed on a user’s machine so this allows me to quickly shut off all remote requests if something bad happens.

So my revised list of features to implement for a version 1.0 release are:

• Create a custom skin for the app
• Search for beer near a given location by making a request to a remote server
• Display a loading animation that integrates with the custom skin while waiting for the response to the search request
• Display app info using a flip effect

Pretty straightforward stuff.  Next time we’ll start by setting up our project and creating the custom skin.

Read Part 3.

I could do much of what BNH Desktop does on the web, but I’d have to rely on users having Flash and for the users that don’t, well, I have to handle them as well, usually by gracefully degrading the experience.  All of this is a lot of work and testing and, again, in my humble opinion, not usually worth it.  From a design standpoint I think a website should be embraced for what it is and not shoehorned into some Flash app that just happens to run in a web browser.

I’ll now step down off my soapbox and get back to the point of this post: Beer Near Here Desktop is a cool example of an AIR application and I want to cut it open and share all it’s secrets.  When I decided to write this app the first thing I did was check out what else is out there for AIR and something that kept showing up was Kuler for AIR.

Kuler, is an Adobe application for creating color swatches and, from everything I read, the AIR version is something that was written to show off some of the cool things you can do with AIR.  And sure enough it does show these things off.  It has custom skin and some neat effects.  The trouble is that there is no explanation of how to accomplish any of this.  It’s almost a tease, “See, you can do all this cool stuff…but we’re not going to tell you how.”

Undeterred, I went on to do some more Googling and reading with the end result being Beer Near Here Desktop.  You should check it out.  FYI, I’m not paying $300 to sign my code with Verisign so you’ll have to just trust me on the install.

Some of the neat features of BNH Desktop include:

• A custom skin.  In Flex/AIR parlance this is “custom chrome”.
• A loading/waiting animation that integrates with the skin.
• A flip effect.
• Custom roll-over buttons.

So now you know you can do these things and I aim to explain them as well.  But for that you’ll have to stay tuned until next time as I want to give each feature it’s due.

Read Part 2.