"tip-of-the-day" Posts

Tip of the Day – Populate Version Number from an AIR Descriptor File in ANT

So I’ve seen this question pop up a few times.

Can I grab a version number from the app-descriptor via ant and add that to the AIR filename? Anyone know?

This is a pretty straight forward thing to do using Ant-Contrib tasks, that are publicly available.

You can download the example files –> here.

Let’s take a quick look at the ANT script.

<project name="PopulateVersion" default="populateVersion" basedir=".">
 
  <taskdef resource="net/sf/antcontrib/antcontrib.properties">
      <classpath>
          <pathelement location="./ant-contrib.jar"/>
      </classpath>
  </taskdef>
 
  <property name="app.descriptor" value="air-app.xml" />
 
  <target name="populateVersion">
 
    <echo message="Parsing application.version from ${app.descriptor}"/>
    <xmlproperty file="${app.descriptor}" prefix="airApp.appdescriptor"/>
    <propertycopy property="versionNumber" 
                  from="airApp.appdescriptor.application.versionNumber" 
                  override="true" />
    <echo message="Parsed application version: ${versionNumber}"/>  
 
    <propertyregex property="fileVersionNumber"
                  input="${versionNumber}"
                  regexp="\."
                  replace="_"
                  casesensitive="false" />
 
    <echo>Version Number: ${versionNumber}</echo>                    
    <echo>File Version Number: ${fileVersionNumber}</echo>
  </target>
 
</project>

As you can see it’s very straight forward to parse the version number out of the Application Descriptor. The only other thing we do is us RegEx to change the periods in the version number to underscores to make for more friendly file names.

Using the same concept it is very easy to also populate a Version file that gets compiled into your application which can include build numbers, or other interesting things… but we’ll save that for another day.

Tip of the Day – Getting a SWF’s background color

Recently at ZaaLabs, I’ve been working on a really cool tooling platform called Eden. One of the features that Eden has is a Screen Capture plugin. Eden can send a request to a remote SWF to return a bitmap of the stage.

For example, here is Eden pulling a screen capture from HanClinto’s Platformer Starter Kit.

Really cool! However, I quickly ran into an issue when I tried to take a screen capture of a more basic game.

On the right is the game running in Flash, and on the left is the screen capture.

As you can see, my screen capture doesn’t include the green background. So what happened?

Well it turns out the background color of a SWF isn’t actually part of the stage. The background color that you set using the SWF Metadata tag, or set in Flash Professional is drawn directly by Flash Player.

package
{	
	import flash.display.Sprite;
 
	[SWF(backgroundColor="0x00FF00")] // <--- How can I get this programmatically?
	public class SwfBackgroundExample extends Sprite
	{
		public function SwfBackgroundExample()
		{
		}
	}
}

So I had a dilemma… how could I access the backgroundColor of the SWF? I scoured the API docs, I asked the Twitter-sphere, but no luck. All I learned was that the backgroundColor was hard coded into the bytes of the SWF. So I decided that’s where I needed to look for it.

SwfData to the rescue.

I read up on the Adobe SWF specification, and consulted with my good friend James Ward. He pointed me in the direction of loaderInfo.bytes, which gives us access to the bytes of the currently running SWF.

After a few hours, I had a fun little class I like to call SwfData, which parsed the background color out of the currently running SWF’s bytes… as well as some other fun things. Here’s how you use it:

package
{
	import com.zaalabs.utils.SwfData;
 
	import flash.display.Sprite;
 
	[SWF(backgroundColor="0x969696")]
	public class SwfDataExample extends Sprite
	{
		public function SwfDataExample()
		{
			var data:SwfData = new SwfData(loaderInfo.bytes);
 
			trace("version \t"+data.version);
			trace("frameRate \t"+data.frameRate);
			trace("frameCount \t"+data.frameCount);
			trace("fileLength \t"+data.fileLength);
			trace("bgColor \t0x"+data.backgroundColor.toString(16));
		}
	}
}

Using SwfData, I could now use the background color as the fill color of my BitmapData class.

Get It Here

SwfData is MIT licensed under ZaaUtils (do with it what you will). It is available on GitHub

Questions, comments, complaints are all welcome below.

== UPDATE ==

So I just found out that Claus Wahlers has an awesome, more feature complete version of an AS3 SWF parser. It’s also available on GitHub. I’m still going to keep SwfData up since it’s much more specific to getting the background color of the swf. If you need more features, use as3swf by Claus, it’s very well done.

Tip of the Day – Updating to Flash Builder 4.0.1

I recently posted about Building AIR 2 applications with Flash Builder 4.

There is now an update for Flash Builder 4 which downloads and installs the Adobe Flex 4.1 SDK. According to Renaun Erickson’s post, Flex 4.1 includes Flash Player 10.1 and AIR 2.0.

Now, if you’re like me and loathe the Adobe Updater… then you probably turned off the Adobe Updater notifications.

So here’s how to update Flash Builder to version 4.0.1 which includes the 4.1 SDK.

Go to Help > Search for Flash Builder Updates…

Help - Search for Flash Builder Updates...

This will launch the Adobe Application Manager and then proceed to update your software, including Flash Builder 4.

== UPDATE ==

If you don’t see a Flash Builder update available in Adobe Application Manager, you can download the standalone updater from Adobe.

Update Progress

Update Complete

Once the update is completed you can see Flash Builder is now at version 4.0.1.

Flash Builder 4.0.1 about screen

And you now have the option for Flex 4.1 as an installed Flex SDK. You can use Flex 4.1 to develop against Flash Player 10.1 and Adobe AIR 2.0.

4.1 is now avaliable

Tip of the Day – Building AIR 2 applications with Flash Builder 4

:: Update ::

This process has gotten much easier, you can now use software update to get AIR 2 as well as Flash Player 10.1 in Flash Builder… check out this post.


Adobe AIR 2 and Flash Player 10.1 were released on June 10th, 2010. It’s an exciting time. This weekend I decided to do some development on AIR 2 to try out some of the new features.

On the Adobe AIR Team blog’s post they mention that the free standalone download of the AIR 2 SDK will be available on Tuesday, June 15th… but I wanted to play with the SDK today.

So I went over to the Adobe AIR labs page and downloaded the AIR 2 Release Candidate SDK which is –> here.

You can download the released SDK from –> here

After downloading the Adobe AIR 2 SDK, I followed the directions on the release notes which explained how to overlay the AIR 2 SDK with my current version of Flex 4.

I’m on a mac, here are the commands I used in Terminal:

cd /Applications/Adobe\ Flash\ Builder\ 4/sdks/
ls
cp -r 4.0.0 4.0.0AIR2
ls
cp ~/Downloads/air2_rc1_sdk_mac_051110.tbz2 4.0.0AIR2
cd 4.0.0AIR2
tar jxvf air2_rc1_sdk_mac_051110.tbz2

I then added a new SDK to the installed SDK’s inside of Flash Builder:
Installed SDK's in Flash Builder 4

Now, I already had an Adobe AIR application project set up, and I switched over to the new SDK the I installed:
Switched over to Flex 4.0 (AIR 2)

However, when I tried to run my AIR application, I ran into this error:

VerifyError: Error #1014: Class IIMEClient could not be found.
 
	at flash.display::MovieClip/nextFrame()
	at mx.managers::SystemManager/deferredNextFrame()[E:\dev\4.0.0\frameworks\projects\framework\src\mx\managers\SystemManager.as:267]
	at mx.managers::SystemManager/preloader_preloaderDocFrameReadyHandler()[E:\dev\4.0.0\frameworks\projects\framework\src\mx\managers\SystemManager.as:2460]
	at flash.events::EventDispatcher/dispatchEventFunction()
	at flash.events::EventDispatcher/dispatchEvent()
	at mx.preloaders::Preloader/timerHandler()[E:\dev\4.0.0\frameworks\projects\framework\src\mx\preloaders\Preloader.as:488]
	at flash.utils::Timer/_timerDispatch()
	at flash.utils::Timer/tick()

After doing a bit of research I found out that my Adobe AIR project’s application descriptor file wasn’t using the correct namespace for the AIR 2.0 SDK. According to the Adobe AIR 2 Release Notes:

You must update your application descriptor file to the 2.0 namespace in order to access the new AIR 2 APIs and behavior. If your application does not require the new AIR 2 APIs and behavior, you are not required to update the namespace from 1.x based namespace. To update the namespace, change the xmlns attribute in your application descriptor to: http://ns.adobe.com/air/application/2.0

Sure enough, I hadn’t changed my namespace from AIR 1.5.3 to AIR 2.

I made the change in the descriptor file, and now everything works perfectly.