Once you have your project set up (Flash Professional or Flash Builder) and all the required downloads from the earlier post we still need to do some setup before we can start running the emulator and releasing to your Android device.

This is where that ANT file will really help your development. What we need to be able to do is startup the Android SDK and AVD Manager, download some packages, and set up some virtual devices. Only once this is done can we create emulators of different types and start installing.

Before going down the next steps make sure to set up your build.properties. Once you have all your paths set correctly we’ll be ready to move forward. What you don’t realize is you already have a working development environment, now let’s see how to use our environment.

Information on how to use the command line for all your commands is in the Android Development Guide. I’ve just made it a bit easier by providing a preconfigured ANT file.

Starting up the Android SDK and AVD Manager
The next few steps all take place in the provided Android SDK and AVD Manager. To startup the manager is very simple, with ant execute the start_up_manager target.

With this command properly called the java app should start right up and you should see this.

On the first startup you won’t have any listed virtual devices. We’ll need to add those in.

Select and Download Packages
Before we can create a virtual device you need to go get some packages for your device to run on.

Go to Available Packages and select the packages you want to download. Depending on the amount of packages you select you may be here a long time – I just did them all because I am crazy like that. I’d recommend getting a drink right about now.

Once all the packages you’ve selected are downloaded the waiting is over, we can get moving now.

My Installed Packages.

You can go through your finder/browser and see the downloaded packages in your platforms folder.

Setup Your Android Virtual Devices
With your packages downloaded we can now create our virtual devices on the Virtual Devices window.

Now you can go to New… and create a new Virtual Device.

Select your target platform.

The final thing that you need to do is to add abilities to your new virtual device by adding hardware specifications.

Once you have your virtual device set up we can run it as an emulator. You can set up as many of these as you like so don’t hold back.

With your platforms downloaded you can also set up your AVDs through the ANT file by calling the following command.

1	$ ant -buildfile build.xml create_virtual_device

Startup the Emulator
Once you have some virtual devices set up you can just click on Start… and startup the emulator, ready for installing and testing.

You can also do this through the ANT file by calling the following command.

1	$ ant -buildfile build.xml start_emulator

Install the AIR Runtime on the Emulator or Android Device
These next parts require going either through the ANT file or command line. For the ANT file installing the AIR Runtime on the emulator is extremely simple. With your Emulator started up just call the following ant command.

And for an Android Device just call:

The provided scripts expects that there will only be one emulator and/or one device connected at a time.

Install your Application on the Emulator or Android Device
Installing an Application on the emulator or Android Device is extremely simple – just as simple as installing the Runtime. With your Emulator started up just call the following ant command.

And for an Android Device just call:

The provided scripts expects that there will only be one emulator and/or one device connected at a time. The ANT script currently recompiles and builds the application and then deploys it to the target device.

DONE!
Once you have done all of this you will have a working development environment up and going. Good luck in your Adventures with Android.

If you are starting with this post I recommend actually starting with a previous post introducing AIR for Android Development. There is a ANT file there that you will want to have.

FYI: All these steps are also available in Developing AIR Apps for Android PDF provided by Adobe.

Unlike Flash Professional we won’t be able to create an .apk file from our IDE. We can debug from the Flash Builder IDE, as shown by Renaun. That being said, that is where my ANT build file is even more helpful as it can package your application into a .apk file quickly for you.

Let’s set up this project.

Step 1: Startup
Create a new Flash Builder Project. File > New > Flex Project.

Step 2: Project Settings

Make sure the application type is Adobe AIR and that you are using the SDK that you created with the AIR 2.5 SDK.

Then click next twice or until you get to this screen.

Change your main application file to “[Your Application Name].as”. By default it will try to create an MXML file, but as we are trying to make an AS3 project we need to change the file extension to being “.as”.

It’s also good practice to change your application ID to be something a bit more unique – I always just add in reverse domain extension to it.

Click Finish

Step 3: Program
You should now have an application that looks like this:

You can keep programming your application to whatever you want. As I just want a quick application that shows Hello World so that we can continue, my application is going to be very simple.

My Application:

Step 4: Setup your descriptor file
First thing you should do is make sure that your application descriptor namespace includes “2.5″:

If you are using the right SDK, this shouldn’t be an issue.

We only need to change a few attributes in the application descriptor file to get things going. Any other changes that we need to make will be more specific for your application.

In the “initialWindow” tag find “visible”. Make sure it is set to true.

Now find “supportedProfiles”, set this to mobileDevice.

Now go to the “content” tag and change it to “[Your Application Name].swf”. Flash Builder typically switches this name out for us, and I could do it in my ANT file. But I can be lazy at times and would prefer just to set this value. Especially since this application descriptor belongs to the one specific application.

Step 5: Package your application
Your application is now ready to be changed to a .apk file for release. This is also when I will diverge from the Adobe PDF. See, I don’t like command line. So I created that nifty little ANT file to do everything I need. Now go get that ANT file and add it into your project and make any changes necessary to the build.properties as described previously in the last post.

With the settings changed to your specific computer we are good to go. You can either run an ANT file from command line or from your IDE.

From the IDE:

Here I right-clicked on the build folder and went to Run As.

Or from your command line you can run the ant file. Just “change directory” to your project holding the build.xml. Here you can type in one of two commands.

Both mean the same thing as the build target is the default target in ANT and the build.xml is the default file. If you wanted to run a different target you could.

To run get_devices

1	[Hello World Directory] $ ant -buildfile build.xml get_devices

To run start_up_manager

1	[Hello World Directory] $ ant -buildfile build.xml start_up_manager

After you run the build target you are good to go. The ANT file will spit out your .apk file in a release folder. That’s it, you are ready to get away from the Actionscript and into the Android release process.

If you are starting with this post I recommend actually starting with a previous post introducing AIR for Android Development. There is a ANT file there that you will want to have.

FYI: All these steps are also available in Developing AIR Apps for Android PDF provided by Adobe.

Step 1: Add Extension
Go to Help > Manage Extensions… and install the AIR for Android Extension for Flash CS5. (Yes, CS5 is required).

Step 2: Restart
Restart Flash CS5

Step 3: Create Project
Create a new AIR for Android project.

Step 4: Save
Save the the document.

Step 5: Write your App
Do whatever you want. Here I’m going to add text that says “Hello World”.

Step 6: AIR for Android Settings
Now we do the Android specific steps. Go to File > AIR for Android Settings.

With the settings:
Output File: Hello.apk
App name: Hello
App ID: Hello
Aspect ratio: Portrait

Step 7: Set up the Deployment…

On the Deployment tab, make the following settings:

• Certificate: Point to a valid AIR code-signing certificate. You can click the Create button to create a new certificate. (Android apps deployed via the Android Marketplace must have certificates that are valid for 25 years.) Enter the certificate password in the Password field.
• Android deployment type: Release
• After Publish: Select both options
• Enter the path to the ADB tool in the tools subdirectory of the Android SDK.
• Close the Android settings dialog by clicking OK.

Step 8: Update the AIR Descriptor file.

• Open the application descriptor (located in the directory where you saved the .fla file).
• Change the tag to and make sure that it contains a value of the form: number.number.number
  For example: 0.1.0
• Save the file.

Step 9: Publish
Now just go to File > Publish and you can export your .apk file. We’ll still need to install the runtime and the application on the emulator and/or device, but for now we have our .apk file ready to be installed.

The tricky part isn’t writing the application. That part is easy and we know that part. The tricky part is building the .apk package and testing the application on an emulator or other valid device.

So that is what I am going to write about, the tricky parts.

• - Managing the Android Development Environment
• - Building the Hello World Application in Flash Professional
• - Building the Hello World Application in Flash Builder

Once you read through these posts you’ll have an up and going Air for Android development environment and an initial application to kick you off.

Starting these posts off I will add a few disclosers:

1. 1. I am not a fan of command line.
2. 2. I am not a fan of messing with the paths in my computer.

I am not a fan of command line
I just don’t like memorizing a ton of commands or having to go back and reference a ton of commands and paths. One small path issue and BAM nothing works and you have to read through a ton of mixed code to see where your problem is. Not fun.

I am not a fan of messing with the paths in my computer
Seems like every programming language I get into requires a bunch of path changes and if I move computers now nothing works till I set it up. Not fun. I also fear screwing up my computer.

In case you like setting up paths or want to know how there is a guide provided by Adobe called Developing AIR Apps for Android in the prerelease site. That PDF includes a section Setting the path environment variable. Follow that guide.

Solution
I like using ANT. I can set up all my paths in ANT and ANT works directly into your continuous integration environment. So if I move computers I can just set up my properties I’ll be good to go. Finally the amount of commands to memorize goes WAY down or you can just look into the ANT build file and see the available possible commands.

Want to know what else is pretty slick? I’ve set up the ANT file for you. I’m thinking of making a nice GUI in AIR to help you out, but for now an ANT file will have to help.

Getting Started
The things you’ll need to get started with Air for Android.

1. - Download the Android SDK
2. - Sign up for the Air for Android Prerelease program
3. - Download Air 2.5 from the prerelease site (if you don’t already have access to the prerelease site, you’ll have to wait for your email after you sign up for it)
4. - Download the prerelease Runtimes (emulator and device)
5. - Download the Flex 4 SDK
6. - Combine the Flex 4 SDK with the Air 2.5 SDK

Creating a Project
AIR for Android currently works best with either a Pure AS3 project (no Flex) in either Flash Builder or Flash Professional. If you are building with Flash Professional, there is an extension that Adobe has provided for you to help speed up the .apk build process. If you go through Flash Builder you’ll have to make this file. Again, with the ANT file I am providing either is a very simple path, so choose the development environment that you prefer.

• - Creating a Flash Builder Project
• - Creating a Flash Professional Project

Setting Up Your ANT File
Once you have your projected set up you will be ready to add in the ANT build information. The ANT file that I will use for the rest of these posts is really easy to set up, just drop it (and base.properties) into your application in the root level.

This ANT file provides you the ability to install the device and emulator runtimes, install your application and test it on a device or runtime, set up a device, run the emulator and even run the Android Management device. Again, yes you can do all these things in the command line… but do you want to?

Then you need to create a build.properties text file. This is the file that you will put your own environment’s paths. So if you share this build file, everyone can have their own properties and the main build.xml is the same and unchanged.

build.properties

You’ll probably notice that I put my Android SDK in the same folder as my Flex SDK. This isn’t necessary, I just thought it’d be nice that all the information for my development environment would be in one location.

In upcoming posts we’ll go through how to use the ANT file and manage your development environment.

Good luck in your Adventures with Android.

Don’t miss this, this is the link for the ant files!

From here checkout how to manage your Android SDK environment, how to create a Flash Builder Android Project, or how to create a Flash Professional Android Project.

Let’s get into have to build and package an AIR application using ANT. Unlike building a web application you need more than just a SWF file to deploy your application. You will need to actually build the SWF file and then package that SWF file into an ANT file.

The Three (not so easy) Steps:
1. Build a SWF File
2. Make a Certificate
3. Package your SWF with your Certificate

Starting Out
I’ve created a simple AIR Project called “AIRCI”.

Right now the AIRCI.mxml file is super super simple.

And the app descriptor file that Flash Builder generated.

The build.xml file looks like…

And the build.properties file…

Build the SWF File
When building an AIR application we start by building the SWF file and then storing that build file to package with the certificate.

What I’ve done here is use the FlexTasks MXMLC task to build the SWF file. I’ve specified that this is an AIR build so that we use the air-config.xml provided by Adobe. This provides lots of settings for us such as manifest files and other settings. Then I specify the source folder, library folder, what file is the main application file, and finally where the built swf file will be output to.

And the properties’s file additions:

Make the Certificate
Next we need to build the certificate – especially if the certificate hasn’t been made yet. In the final file we’ll check if it exists and only create the certificate if it doesn’t, but for now we’ll just build the file. We’ll use the ADT executable to achieve the certificate creation.

And the build properties added in this step:

Package and Release the AIR Application
Finally we’ll create the releasable application using the ADT executable with the application descriptor file, the swf file that was previously created, and the certificate.

No additions were added to the build.properties file.

Final build.xml File

Final build.properties File

One error you may see when trying to package your application is:
[java] /Users/jonbcampos/Documents/work/dflex/AIRCI/src/AIRCI-app.xml(43): error 105: application.initialWindow.content contains an invalid value

This is because the content in your application descriptor file isn’t set. When Flash Builder builds an AIR file it replaces the content tag in the application descriptor file.

1 2	<!-- Note: In Flash Builder, the SWF reference is set automatically. --> <content>[This value will be overwritten by Flash Builder in the output app.xml]</content>

You may want to just switch it out for the name of your swf file:

1	<content>AIRCI.swf</content>

Honestly I thought I already created a blog post with this code so that other people could also use it.

Play with the Konami Code by clicking on the example below and typing in the Konami Code on your keyboard – I’m not going to tell you what the code is…

You can view the source to the CodeManager here.

Some other fun things I added into the manager. You can control how quickly the code was entered, enter in new codes with just the string, and just listen to the result that the code was successful.

As time goes on I’ve changed my methods but the theory has stayed the same: Get the URL, go to a specific state of the application.

The question is again how do we get this information, how do we determine where to go, and how do we mark updates in our application to the URL. We’re going to also want to have our application’s URL be shareable between applications.

More concisely, I’m going to talk about a very simple framework I’ve set up to speed up the programming behind deep linking. In no way is this framework complete, however it has served it’s purpose for some applications I’ve put together and can definitely help you. If you have feedback please let me know.

Example (View Source Enabled) | View Source

Thinking of SEO and Search Engines we still don’t need to worry about search engines finding our content because we are going to use SWFObject and Alternative Content to show the data and text that belongs to the specified link. We can even still use HTML links within our alternative content so that search engines crawl and scrap our content… while the user will see your beautiful Flex application.

In this blog post I’m not going to talk about writing your alternative content, that was previously discussed.

As discussed earlier, it is very beneficial to have this alternative content for your Flex Applications – especially if you are creating a Flex Application to be delivered to the open web. If a device that doesn’t support Flash runs into your site the alternative content will be shown and the user can keep getting your fabulous content.

My framework that will handle the Deep Linking is going to be built around a Singleton Class. Why? Well there is only one browser and I want to be able to update the single browser from anywhere in my application. When this class starts up we’ll get the initial URL and set the application’s initial state.

Get the URL
In my previous post I used server side code to set the initial vars and url for our application. I still believe that if you need to do some augmentation on your URL prior to reaching the Flex Application this is a perfectly legitimate method, but I also want to show a simpler route to getting your application’s url.

Determine the application state
Once you have the URL the next step is easy. Parse the URL string for your application specific variables and move your application to that location.

As simple as this step is – this step is infinitely difficult to explain for your specific application. If you’re wondering when I will get to get to my framework, that time is now. Here is precisely where my framework helps your development. What you need to do is register components, in my example I will register a Spark List component.

What I have done is register a List (the id is list), say that the name in the url will be “list” and that the property that we will be watching is “selectedIndex”. Finally I say that the default value is 0. So if the value is 0, we don’t worry about putting it into the url – keeps the URL pretty .

Mark Application State updates to the URL
When the application state changes the first thing you need to do is parse the current state of the application and turn that into a URL. Then, if the URL changes you need to reverse this process and set the application state based on the parsed URL.

To update the URL is really simple with the application, just call the updateUrl function.

Whenever and whatever you want to trigger an update to the Url just mark the event with this code.

That’s it. The browser’s URL is set based on the application and the application’s state is set based on the URL. The roundtrip is complete and the application is deep linking compatible. I hope the framework helps you as much as it’s helped me. Again, I’m looking for feedback if you run into any troubles using it.

Example (View Source Enabled) | View Source

You can get the code in my public library on github.
Here is the source to the DeepLinkingManager.

Update:
Geez, I am a constant perfectionist when it comes to my code – blog post typos are a different story. I felt that if you are listening for a change on the instance then why am I forcing you to make ANOTHER handler function to just update the url. If you want this handled for you based on an event from the instance there is a new parameter on the register function that will allow you to enter that event type. Now you don’t even need to call the updateUrl if you don’t want to. Just do:
DeepLinkingManager.getInstance().registerNavigationControl(“list”, list, “selectedIndex”, 0, IndexChangeEvent.CHANGE);

You’ll notice I already have made my ScalableSkin, but right now it’s empty. This is just a stripped out version of the ButtonSkin created when using the “New > MXML Skin” Command.

The file current looks like this:

Just a blank skin with the label.

My Problem with Early Beta Builds
When I first got into 9 Slice Scaling I thought that all you had to do is make a s:Group – which has scale9 build into it. However at the time if you didn’t include a background element that engulfed the entirety of the scaled item, then the skin came out horribly wrong.

Current Solution
The Flex team has since listened to our pain and updated the 9 Slice Scaling process. Now my current solution looks as such:

And we get the result that we see from the above image. The Group defines the Left/Right/Bottom/Top scale slices and the s:Path defines the shape to scale within the Group.

Again, this is a huge improvement to skinning with 9 Slice Scaling in Flex 3.

If you want more information on Spark Skinning check out some of my other posts:
Flex 4 Spark Skinning
New Spark Skinning Workflow
Spark Skinning with Flash Catalyst

The recording of this presentation:
Connect Recording

And the slides:

I have other blog posts made to help with some of the common migration pitfalls:

Migrating From Flex 3 to Flash Builder 4: Nonvisual Classes in MXML
Migrating From Flex 3 to Flash Builder 4: mx.core.Application

A few years ago I was struggling with getting the Mac Wheel and the PC Wheel to work with a Flex App I had made. So rather than getting both of those inputs to work, I just had the Flex app dynamically change the size of the browser and used the browser’s internal scrollbars to have the user go up and down the application.

This may sound difficult but it isn’t, just mix and match ExternalInterface with a few nice javascript calls and you’re good to go.

If you want to see the final product just follow this link. You’ll need to just enter in the size you want to resize your app to and hit the button.

So let’s look at what we’ve put together.

First I wanted this class to be a Singleton. I did that because I wanted to be able to access editing the size of the application from anywhere – and as there is only one browser instance – a Singleton made sense.

Now there are at minimum two javascript functions that I will need to create for this example to work. The first function will need to pull the application’s id so that we can reference that id in javascript. The second javascript function will need to resize the flash application.

To get these javascript functions to work though we need to inject them into the dom. This is actually easier than you would think.

What I did was use the ExternalInterface to call a function to check if the javascript function existed. If it doesn’t, add it into the dom. Then from that point on you just need to call the function directly. This strategy is very helpful because you don’t have to change the template and make sure the functions already exist, instead you add them into your HTML page at runtime.

Once the functions exist you just call them and you’re done.

Here is the source for the Singleton class I’ve created. I will let you know now that some of the javascript functionality was stolen from the iFrame Google Code class. They did a great job!

Further Development:

To continue making the class just perfect you could also have the class return the current size of the browser so that the flex app isn’t set to lower than the visible browser. Also you could have a listener so when the browser resizes, the app resizes (because once you set the height, it’s fixed – unless you set back to 100%). You could also set up a queue system so that functions aren’t called multiple times on within a frame, just wait for the next Enter Frame.