How to upgrade your AIR SDK in FlashBuilder 4.6

This post walks through the steps for upgrading your AIR SDK.  There are just a few tricks and I spell them out here since this isn’t a one-click, plug-in-play operation. As of this writing, AIR 3.3 is the latest version, whereas FlashBuilder 4.6 came with v3.1 installed.

Why upgrade? In my case I had two reasons. First, I’d heard from a co-worker that AIR v3.3 compiled significantly faster. And, second I ran into a few flaky bugs and I wanted to test my builds using the latest SDK version.

1. Make a copy of the Flex SDK directory and place it in the same default sdk directory. On windows this is C:\Program Files (x86)\Adobe\Adobe Flash Builder 4.6\sdks. Rename the new directory you just created to something like “4.6A3.3”.

2. Download latest AIR SDK (zip) file from Adobe. Yep, even though Adobe open sourced Flex, they still produce AIR and the FlashPlayer runtime: http://www.adobe.com/devnet/air/air-sdk-download.html.

3. Merge the contents from the AIR SDK zip file into the new copy of the Flex SDK directory. There will be some files that you have to overwrite in order to get the latest version.

4. Instruct FlashBuilder to use the new SDK by going to Window > Preferences > Flash Builder > Installed Flex SDKs, and then click “Add”. If you want to keep track of the different AIR versions related to Flex then make up a new naming convention for the SDK such as “Flex 4.6 – AIR 3.3”.

5. For existing projects which are using the older versions of AIR, such as Flex mobile projects, you’ll need to manually update the app.xml file to use the correct SDK version number in the namespace (xmlns). This file can be found in your FlashBuilder Project using the Package Explorer. If you don’t make this change you’ll get a compiler error. Your app.xml namespace should look like this. Note that when you create a new mobile project it should automatically be created with the correct xmlns settings.

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<application xmlns="http://ns.adobe.com/air/application/3.3">

<!-- Adobe AIR Application Descriptor File Template.

	Specifies parameters for identifying, installing, and launching AIR applications.

	xmlns - The Adobe AIR namespace: http://ns.adobe.com/air/application/3.3
			The last segment of the namespace specifies the version
			of the AIR runtime required for this application to run.

	minimumPatchLevel - The minimum patch level of the AIR runtime required to run
			the application. Optional.
-->

Here’s an example of the error you’ll get if you don’t do this. You’ll see something like “Namespace 3.1 in the application descriptor file should be equal or higher than the minimum version 3.3 required by the Flex SDK.”

References:

Adobe Doc – Overlay the AIR SDK with the Flex SDK

Debugging Flex-AIR apps on iPhone and iPad

Debugging iPad or iPhone apps that you built with FlashBuilder has a number of extra steps that you don’t need when developing with Android. This is especially true if you use Windows as your primary operating system. The good news is that once you’ve done it once or twice it should be fairly straight forward. So here are a few hints to get you going.

Step 0. If you are building on Windows make sure to install the latest version of iTunes. Then check that your iPad or iPhone can be synched with iTunes. If you use a mac you’ve most likely already done this step (in your sleep a hundred times).

Step 1. Make sure you have a certificate and provisioning file. This must be configured under FlashBuilder Project > Properties > Flex Build Packaging. IMPORTANT: If the certificate and provisioning file are not set up or are not valid you will not be able to compile your project. If you don’t know what this is or how to do it, additional info can be found here in a great blog post by Holly Schinsky (@devgirlFL).

Step 2. Set up a Debug Configuration. If you don’t know where that is, select the pulldown next to the bug icon on the FlashBuilder toolbar and then choose Debug Configuration, or go to Run > Debug Configurations. Choose Apple iOS as your Target Platform. Be sure to select the On Device Packaging Method > Fast! If you don’t do this and you choose the Standard option it will take five or more minutes to compile the build each time you hit debug, and that can become a huge time waster really fast. One advantage of using the Standard option is it will perform more like the final release build. In comparison, the Fast version won’t be as performant. So, for the vast majority of your debugging you should probably use Fast, and when you want to test a final build then you might want to choose Standard. When you are ready select the Debug button.

Step 3.  You will then see a popup window with six important instructions. Once you have completed Steps one and two, select the Show package in Explorer link.

Step 4. Drag the .ipa file from your file browser window into the iTunes Library > Apps area.

Step 5. Select the Sync button on the bottom right hand corner of iTunes. You should see Sync In Progress screen on your device. Let the operation complete. When it’s finished you should see a message in the message box at the top of iTunes that says the sync was successful. If there was an error it will also show up in the message box at the top of the iTumes application window.

Step 6. Launch the application on your iPad or iPhone. You should get a popup window titled Flash Debugger that asks for the IP address or hostname.  Important:  your iPad or iPhone and your development machine need to be on the same wireless LAN, if they aren’t then this step won’t work. If you don’t have a wireless LAN handy you can always log both machines into a MiFi or some other type of mobile hotspot. Then enter the IP address of your development machine. On a windows machine you can easily get that in a DOS prompt using the command ipconfig. Hit OK.

The Final Result. If all goes well the app will launch and you will start to see debugging output in FlashBuilder.

Using FlashBuilder and Ant to Build SWCs with ASDoc Comments (on Windows 7)

It’s always an adventure when you try to use Ant to include your ASDoc comments into an Adobe Flex SWC library. I am completely baffled that Adobe can’t make this an automated step in Flash Builder, because it typically takes a alot of time to make things work correctly the “manual” way. So, I’m adding this blog post to the many already out there in hopes that my work can also help someone else.

I started off with a script that used to work on my old 32-bit laptop, but my new laptop is 64-bit. I kept getting Java Heap errors and I tried everything under the sun including changing FlashBuilder.ini and jvm.config to bump up the max heap size (-Xmx1024m). Nothing would work. What finally fixed this was adding the following line in my compc and asdoc sections of my build.xml file. If I made my settings any larger Flash Builder would throw an error. At some point I want to know why that is:

<jvmarg value="-Xmx1024m"/>

Here’s a few other tips-n-tricks:

  1. A lot of the blog posts I read were written for Mac’s…which I don’t have, so all the directory slashes were going the wrong direction.
  2. You need to install the Ant tools into FlashBuilder first. To do that go to Help > Install New Software and use this link: http://download.eclipse.org/releases/galileo
  3. When that loads its packages, look under Programming Languages for the option called Eclipse Development Tools and install that.
  4. Create a new Flex Library Project and drop in the actionscript class you want to convert.
  5. Create a file called build.xml and place it in the root directory of your project.
  6. Right click on the build.xml file and choose Run As > Ant Build.
  7. If you have errors, use echo statements to try and find out what’s going on.
  8. You absolutely must have a <taskdef> reference that points to flexTasks.jar.
  9. I also needed to include another class library into the build. You can see how I did that under the asdoc section using this pattern:
<compiler.source-path path-element="${basedir}\src"/>
<arg value="-external-library-path=${basedir}\bin\agslib-2.2-2010-12-08.swc"/>

References:

Adobe – Use the ASDoc Tool
Gaurev’s Blog – Creating Swc Files with ASDoc Comments


<?xml version="1.0"?>
<project name="mapsaverlib-1.0" default="main" basedir=".">

	<property name="FLEX_HOME" value="C:\Program Files (x86)\Adobe\Adobe Flash Builder 4\sdks\4.0.0"/>
	<taskdef resource="flexTasks.tasks"
		classpath="C:\Program Files (x86)\Adobe\Adobe Flash Builder 4\sdks\4.0.0\ant\lib\flexTasks.jar" />

	<echo message="Flex Home ${FLEX_HOME} "/>

	<!--<target name="main" depends="clean, compile, doc" description="Clean build of <filename>.swc">-->
	<target name="main" depends="compile, doc" description="Clean build of mapserverlib-1.0.swc" />

	<echo message="clean"/>

	<target name="clean" depends="clean-temp-docs">
		<delete failonerror="false">
			<fileset dir="${basedir}\bin">
				<include name="${ant.project.name}.swc"/>
			</fileset>
		</delete>
	</target>

	<target name="compile" depends="" description="Compile SWC">

		<echo message="Compiling ${ant.project.name}.swc"/>

		<compc fork="true" output="${basedir}\bin\${ant.project.name}.swc">
		    <source-path path-element="${basedir}\src"/>
		    <include-sources dir="${basedir}\src" includes="**\*.as **\*.mxml"/>
			<compiler.include-libraries dir="${basedir}\bin\" append="true">
				<include name="agslib-2.2-2010-12-08.swc" />
			</compiler.include-libraries>
			<jvmarg value="-Xmx1024m"/>
		</compc>

	</target>

	<target name="doc" depends="clean-temp-docs, compile"
		description="Updates SWC with ASDoc XML">
		<echo message="Compiling ASDoc for ${ant.project.name}.swc"/>

		<!-- Call asdoc to generate dita xml files -->
		<asdoc output="${basedir}\tempDoc" lenient="true"
			failonerror="true" keep-xml="true" skip-xsl="true" fork="true">
		    <compiler.source-path path-element="${basedir}\src"/>
			<arg value="-external-library-path=${basedir}\bin\agslib-2.2-2010-12-08.swc"/>
			<doc-sources path-element="${basedir}\src"/>
			<jvmarg value="-Xmx1024m"/>
		</asdoc>

		<!-- updates swc with asdoc xml -->
		<zip destfile="${basedir}\bin\${ant.project.name}.swc" update="true">
		    <zipfileset dir="${basedir}\tempDoc\tempdita" prefix="docs">
			    <include name="*.*"/>
				<exclude name="ASDoc_Config.xml"/>
				<exclude name="overviews.xml"/>
		    </zipfileset>
		</zip>
	</target>

	<target name="clean-temp-docs">
		<delete dir="${basedir}\tempDoc" failonerror="false" includeEmptyDirs="true"/>
	</target>

</project>

Debugging with Flash Builder 4 – Flash Player Debugger Req’d

If you are just starting out with Adobe’s Flash Builder 4, or you installed it on a new machine, you’ll need to install the debug version of Flash Player for everything to work correctly. If you have the regular, non-debug version of the Player installed, the debugger in Flash Builder won’t be able to connect to Flash Player, it will either throw a warning or it will hang and then eventually time-out.

To find out what version of Flash Player you have installed, go here to Adobe’s Flash Player Version Checker. If your results look like this screenshot, you’ll need to upgrade.

To get the latest version of the Flash Player debugger version go here. Be sure to scroll down the page and look for the section that’s appropriate for your operating system. If you are using Firefox on Windows for example, then choose the Netscape-compatible option: http://www.adobe.com/support/flashplayer/downloads.html

If you are looking to uninstall Flash Player for troubleshooting, then you’ll want to read this Adobe Knowledge Base article.

Flash Builder Burrito makes Android mobile development easy

I had a brief encounter with Adobe’s Flash Builder Burrito during AdobeMAX. But this weekend was my chance to test drive it more fully and build an Android app from scratch. To be fair in this evaluation, I haven’t deployed a production-grade Android app…yet! I’ve really only touched the surface, and I’m sure there’s plenty of gotchas to come. But, first impressions are important and here are a few things I really liked about Flash Builder Burrito.

Likes

Very simple to get started. Check out the list of requirements:

  • Windows or Mac machine
  • FlashBuilder Burrito Preview Version

Take note that having an Android phone isn’t a requirement to get started, more on that in just a moment. If you do have an Android phone, then there are additional requirements:

  • Android with Froyo 2.2, AIR 2.5.x and/or Flash Player 10.1
  • USB driver for your model Android
  • Cable to attach your Android to your development machine
  • Network (for debugging)

At the time I’m writing this your deployment options include Flex, which will run in the Android’s Flash Player 10.1, or AIR 2.5.x, which runs locally on the device.

Makes use of existing Flex/ActionScript skills. I’m still very impressed with being able to use my existing Flex and ActionScript skills to essentially build a prototype mobile app in less than an hour and then deploy it to a phone for testing. When I first saw this at MAX it simply blew me away.

Built-in Emulator, no droid required. A very nice feature that Adobe added to Flash Builder Burrito is you don’t have to have an Android phone to get started building apps. It has a built-in emulator that currently lets you choose from 11 different Android platforms, such as Droid 2 and EVO. You can also easily switch from portrait view to landscape view to simulate turning your phone sideways. That was a simple thing, but a mandatory requirement for testing.

Sure, you’ll need a device to do field testing. For example, I wasn’t able to effectively use my emulator because my app required access to a device’s GPS. Once I deployed my test app to a device, then I was able to test the GPS functionality.

Dislikes

Granted this is a Preview release, there are still a few things I had problems with that would like to see added/changed in the final release.

Needs built-in advanced device debugging. The device debugging interface between Flash Builder Burrito and the Android phone is completely bare bones, absolutely no-frills…nada, zip. If you have any problem connecting to your phone it’s anyone’s guess as to what the actual problem is. You won’t get any useable feedback other than things won’t work. I spent four hours trying to troubleshoot why I couldn’t publish to my Droid 2, the launcher would simply hang.

I followed all the instructions carefully and rechecked them multiple times. I tried almost everything under the sun including multiple versions of the USB driver with reboot after reboot. I even installed the Android SDK and was able to successfully publish to my phone using the adb command-line interface. What finally fixed the problem was I upgraded the phone to AIR 2.5.1 on a whim. And presto, everything worked immediately!

It should be a requirement for Flash Builder to provide feedback about the device and provide hints on what might not be working and suggestions on how to solve the problem. Include something similar to adb devices, which would let me know that Flash Builder even recognizes the Android via USB. I’d also like to see something built-in similar to adb logcat that can provide real-time device feedback for every action that happens on the phone.  

Simplify the Android configurations. In Flash Builder Burrito, you have three specific configuration windows underneath the “Run” option. You have Profile, Run and Debug configurations that all have to be set up properly to make things work. This is really more of an annoyance than a showstopper. But streamlining workflows can save a boatload of time when you’re under the gun to deploy apps to a deadline. I’d like to see these combined into a single window, much like the Project > Properties window.

Improve access to the latest ActionScript mobile documentation. I haven’t yet found Flex/ActionScript 4.5 documentation, and I’m still looking. What I mean is if I type “ActionScript 4.5” into a search engine I expected to find the documentation. I also would like to see all classes and packages that work with AIR 2.5.x mobile in one single location. You can’t even easily find officially labeled Flex 4 documentation on the web, and I did relay this information to Adobe on several occasions. At one point I came across this page listed as documentation. What I did find was typically for ActionScript 3, AIR 2 (old!) and Flash Lite 4. And since that was old documentation, it wasn’t clear what had changed.  I also looked on the Flash Builder Burrito labs site here and the Mobile and Devices Developer Center here which is the first place I would expect a link to be.  

All-in-all it looks like a Adobe did a great job so far. So, that’s it for now since I need to get back to playing with my prototype app. If you have any other likes or dislikes please let me know.