Having been following FDT‘s milestones I was really pleased to see that M4 has been announced and decided that I would update and start to use it on my ventures in to Android. Since the creation of WeLoveFDT I’ve been impressed with the output of FDT based posts by the community in particular Marvin Blase‘s Air 2 / FDT 4 walkthrough and looking over what I needed to learn to start to build a multi-screen air application I stumbled on a couple articles by Jonathan Campos
about Android Air Development. So I must admit that a lot of the ground work was allready done by both Jonathan and Marvin but after dissecting both posts I felt a montage, was a must!

So what we’ll achieve by the end of this post should be:

- An FDT 4 workspace with Android’s ADT plugin installed
- A project exporting Android .apk files
- An Ant script to install the Air 2.5 runtime and your .apk file to emulator
- An Android 2.2 emulator displaying your Air application
- Showing trace() statements through Logcat and filtering LogCat logs

Downloads, Setup and Installations

So we’ll need a couple things downloaded before we can start

- FDT 4
- Flex 4.1 SDK
- Air 2.5 SDK
- Android SDK

Also, your going to need to be able to have admin writes on your machine, so I wouldn’t even try it without them. Also Im on a mac so for pc users you’ll have to use your initiative for the difference in paths and what not, but throughout Il try and make sure this post is platform agnostic.

Preparing your FDT 4 workspace

So once you’ve downloaded the latest beta of FDT and installed it on your machine you should have in front of you a blank FDT workspace

The first thing I like to do with a fresh install of FDT is to change the workspace from the default to something a little more memorable and in a better location. So I generally create myself a “Development” folder with an “FDT” folder in it containing two subfolders called “Workspace” and “Toolbox” feel free to change this but Il be working towards using this throughout the post.

So once we’ve created the folder structure, first things first is to change the workspace ( File > Switch Workspace > Other… ) to your new development folder

Now we’ll go through, create a new Flex 4 Air project called “Hello Air” using FDT’s new project panel ( File > New > New Flash Project ) and then we’ll be ready to start to digging in.

Now that, we’ve set up our project and workspace its time to swap out the Flex 4.0 SDK with the latest Flex 4.1 SDK which we will merge with the Air 2.5 SDK to allow for Android development.

Preparing the Flex 4.1 and Air 2.5 SDK’s

So two of the downloads at the top of the post were the Adobe Pre-Release Air 2.5 SDK and Flex’s 4.1 SDK, Currently these are in beta so to be able to create an Air Android application we will need to merge these two SDK’s in to one. Which might sound tough, but it’s relatively easy as long as you know which folders to copy and which to not if your on a mac ( if your on a pc its just a drag and drop supposedly… )

By far the simplest way to do this task is explained by Jonathan in his post How to overlay the Adobe Air SDK for use with the Flex SDK which is to use terminal. I highly advocate that you do this if your comfitable with terminal and if not maybe give it a go? Else heres how to do it with copy and paste, Which starts with getting both the the Air 2.5 SDK .tbz2 and Flex 4.1 SDK .zip and putting them in to the toolbox.

If you then unzip both of them you’ll be left with the __"AIR25_mac_sdk_20100802″ and __"flex_sdk_4.1.0.16076″ in the toolbox, here its quite a dull task of going in to each folder on the root of __"AIR25_mac_sdk_20100802″ and copying the directories inside them to there counterparts in the __"flex_sdk_4.1.0.16076″.

You’ll notice I bolded part of the last sentence, this is because if your on a mac there isn’t a simple way to merge using finder so you’ll need to be aware that if you pasted the whole of ( AIR25_mac_sdk_20100802 frameworks > projects ) folder you’ll have deleted the Flex SDK. So what you need to do is run through the folders copying the stuff inside the folders being aware of ( AIR25_mac_sdk_20100802 > frameworks > libs > air & AIR25_mac_sdk_20100802 frameworks > project ) which needs you to go inside that folder and copy the files not the folder over the __"flex_sdk_4.1.0.16076″ ‘s counterpart. For example the 2 files below not being inside ( AIR25_mac_sdk_20100802 > frameworks > libs > air )

After merging the two SDK’s the test to see if you’ve done it successfully is to swap the Flex 4.0 SDK on your “Hello Air” project with your new Flex 4.1 + Air 2.5 SDK ( Right click the Flex 4.0 SDK item in your project > Flash Project > Change SDK ) then click on Configure and you’ll be brought through to the Installed SDK Panel

If you then go and add an SDK, pointing the path to __"flex_sdk_4.1.0.16076″ in the Toolbox then you should see it appear underneath your previous Flex 4.0 SDK

Clicking ok will return us back to the Configure section where if you select the Flex 4.1 SDK from the drop down menu we will see that you’ve successfully installed the Flex 4.1 , Air 2.5 SDK for Flash Player 10 in FDT 4

However if you see a warning message saying “Some classpath libraries are missing or SDK version is not compatible.” then part of the merge process has gone wrong and my advice would be to try again making sure your that your only copying over files and not removing any in the process.

Installing the Android SDK and ADT eclipse plugin

Previous to the last section we’re going to grab the SDK ( this time the Android SDK previously downloaded ) and put this in our toolbox, unzip it which will mean that the toolbox should look something like below

Once we’ve done this then we’re going to now install Google’s Android Development Tools (ADT) plugin in to FDT so that we have the rich tooling that Google offers for Android development inside FDT for features such as Logcat ( a logging tool for Android, very similar to the Output panel that Flash provides ).

To install ADT in to FDT we’re first going to go to the Install Available Software panel ( Help > Install New Software… ) which will then ask you to input the location of a site which is “http://developer.android.com/sdk/eclipse-adt.html” “https://dl-ssl.google.com/android/eclipse/” for Android’s ADT plugin. Once you’ve entered this in to the input box, you will see an option below for “Developer Tools”, tick the box and then click Next.

This now should ask you to agree to the terms and conditions of installing the plugin, accept these and then the install process should happen. Afterwards, you’ll be strongly recommended to restart FDT and I agree, Restart FDT so that we can start using the ADT plugin.

When your FDT boots back up you should notice a few new options such as options to create Android Projects in the Create New Project panel, new icons on your top nav and also a new perspective called “DDMS” in your perspectives panel ( Window > Open Perspective > Other… )

But firstly what you need to do is set up the Android SDK using the new Android preferences ( FDT 4 > Preferences > Android ) Here you will be asked for your Android SDK location which is in the toolbox, after you’ve browsed to the directory hit Apply then OK.

Now before we can dive in and create an emulator we need to firstly update the Android SDK using the Android Manager which can be opened in many ways, the easiest being the Android icon in the top nav, previously mentioned. Now that you’ve got the Android Manager open, we need to head to the “Available Packages” section and then drop down the only available option to refresh the packages to download. Here we need to select only the latest 2.2 SDK Platform with the Android API 8 Google API’s and Samples.

Hit accept all and then wait for these to download, Perhaps grab a coffee? ( This part takes some time… ) Once these updates have downloaded and installed, in Android Manager go to the Virtual Devices section and click New to create a new Emulator. Go ahead and name this “Android_Emulator”, target Android 2.2 and then Create AVD.

Hopefully you have something like the above, if so select the AVD and then hit Start to boot up your Android 2.2 emulator ( don’t worry about the two Launch Options and also booting up the emulator takes a while, no matter what computer you have ) If all has gone well for this section, You should see the Android emulator working which will mean your ready to integrate Ant in to your project, install the Air 2.5 runtime and push your Air application on to your new emulator

Configuring the Ant build file

So if your unaware of what Apache Ant is, the Apache Ant website has the ‘official’ explanation but my explanation is simply that its an xml-esq build file that allows you to write functions mainly ( in this case of android and air development ) to command line to do stuff. A kind of special sauce to projects which makes developing them easier. Marvin Blase‘s blog post on Air 2 / FDT 4 walkthrough has a Fantastic Ant build file that spurred me on to extend it for Air 2.5 Android. So big credit to Marvin for the base of my Ant build file and from what I can tell Stephan Partzsch for Marvins original basing of his Ant build file.

So, with that all in mind the next download your going to need is my Example Android Air Project If we unzip that, copy the contents of the example Android Air project in to your “Hello Air” project and then Il run through with you what everything is.

So starting with the folders, “assets” is where your icons are kept and also the certificate that you sign your Air project with. “build”, “debug” and “publish” are hopefully obvious but in essence these are the “bin’s” for the different export settings that the Ant build file provides. “src” is of course where all your code goes and “libs” is where to put any external swc’s that you want compiled in to the project. With lastly “runtimes” being a directory that later on you will put the emulator and device Air runtimes to install using the Ant build file.

The first xml file we’re going to talk about is the “Main-app.xml” which is the application descriptor file that Air uses to set certain properties about your Air application. There are lots of options for your application which Adobe does a better job explaining, but the main ones are the 7 nodes ( id, name, filename, versionNumber, copyright, installFolder and programMenuFolder ) and the top 2 nodes of the initialWindow node ( title, content )

The second xml file is the Ant build file which is the “special sauce” to this project and is in charge of compiling, building, installing and deploying your project to both .air and to .apk. However dauntingly long this xml file is, the only section your going to need to change for now is line 37 and 40 which you will be the path location of both the Flex 4.1 SDK ( __"flex_sdk_4.1.0.16076″ ) and the Android SDK ( __"android-sdk-mac_86″ ) which should hopefully be roughly like mine.

Installing the Adobe Air 2.5 runtime on Android

Now that we have the SDK locations in the build file we’re going to need to go back to the Adobe Pre-Release website and download the Adobe Air 2.5 runtime for the emulator ( Adobe Pre-Release website > Download Software > Download AIR for Android Builds [08/02/10] )

Once that’s downloaded, you’ll notice in your project that there is a “runtimes” folder, if you drop the “Runtime_Emulator_Froyo_20100802.apk.zip” in there and then drag the “Android_air_build.xml” onto the Ant panel usually located beneath the Flash Explorer tab ( Windows > Show View > Ant )

Afterwards you’ll see a large list of Ant build functions with the first one we’re going to try out being the “Util – 1. Install Air on Emulator” Now as long as the emulator is running still and the zip is in the “runtimes” folder when you double click the Ant build function the magic of Ant will happen. Then once its finished building you’ll see the below message meaning you’ve succesfully installed the Adobe Air 2.5 runtime on the emulator through an Ant build script ( Pretty neat huh? )

Installing Air files on the Android emulator

Now that we’ve setup the Ant build file within your project and got the three SDK’s configured and working the actual process of installing the air application is relatively easy. We spoke previously about configuring the Ant build file based on your project and now we’re going to have to dip back in to it again just so I can let you know what sections to change when your not using the example base project. So within the “Android_air_build.xml” on lines 30 – 34 there are a couple settings that will need to be changed based on the project.

The main one being the app_name and app_type, if for instance you rename your “Main.as” file to be “Base.mxml” you would need to change the app_name property to “Base” and app_type to “.mxml”. Also of course remembering to change the name of your Application Descriptor file to be “Base-app.xml” and applying these changes throughout the Application Descriptor file ( specifically the content node inside the initialWindow )

Anyway, the process of installing your Air application on to the emulator is as simple as making sure that the emulator is running and double clicking “Android – 6. Install Application on Emulator ( Debug )” in Ant build file and hopefully you’ll see the following message in your console

Following this you’ll then be able to go on to the Android emulator and browse to your new “Hello Air” application

Opening this will then show the standard Adobe Air terms and conditions, accepting these will then bring you to your Android application in all its entirety!

Tracing your Air application through LogCat

The final part to this post is using ADT’s LogCat to see trace(); messages from your Air application, luckily this is already working ( due to using the Ant build files ( Debug ) functions ) so all you need to do is customise your FDT perspective by adding a couple new views to it. If you open up the Views window ( Window > Show View > Other… ) and then open the Android folder selecting the Devices and LogCat view’s, you’ll see that they have been added to your perspective.

Now the benefit to having the Devices view in your FDT environment is that its a great way to see if the Android SDK is playing nice. So if the device isn’t showing in the Device’s view then something is wrong. Also sometimes LogCat doesn’t quite select the device your debugging on, so therefore doesn’t show trace()’s. To fix that you need to select the Device in the list to force LogCat to show trace()’s.

LogCat is a great tool, showing all the in’s and outs of the Android OS but when developing your application, guaranteed your going to be tired of clearing LogCat’s Log screen. So after stumbling on Scott Janousek’s comment on Renaun Erickson‘s blog I can see just how helpful his tip is. Essentially all you do when tracing out your messages is to prefix a “~” to the trace(“~ " + “Hello”); ( or any unique symbol that doesn’t get used much by Androids OS ) then at the bottom of LogCat’s Log screen use the filter input to include your prefix, and system Log’s be gone!