Hope to see some familiar faces there.

First off, the phone that was used as a prototype was an LG C900 which felt cheap and plasticky. However, the screen was remarkably responsive; I don’t know if it’s the phone or the software, but it made for a very agreeable experience.

When moving from menu to application or sub-menu, there were nifty little animations that made the transition very smooth and enjoyable. The UI is well thought out and made it easy to get to the content that you want. My only problem is that because it’s a landscape UI, it might take a while to get where you need since you’ll need to swipe several times to get there.  It’s slightly counter-productive, but how you get there is nice.

My colleague, Daniel Moore, asked the evangelist at the meet how they were going to deploy the updates to the phone.  This is something that most people find frustrating with most phones since it’s normally the carrier that decides when they push out the update which can take months after the initial release.  In this case though, the carrier has no involvement.  Microsoft will make the update available online as soon as it is release; the users can then download and install on their own free will.  This is great news because I don’t think Microsoft is going to stop developing this platform any time soon.

Of course, I had to inquire the evangelist about Flash/Air for WP7.  His answer was short and sweet: “We’ll put it in as soon as Adobe makes it available”.  You hear that Adobe?  Get to it!  Porting Flash/Flex apps to Android and WP7 is a beautiful thing.  Microsoft is not closing any walls on this platform, they believe that choice will always make for a better product;  I couldn’t agree more.

Another thing that impressed me was the Xbox live integration.  You get your profile loaded on your phone automatically and you can play some fairly impressive 3D rendered games or just some fun 2D arcade games.  Right now the library of games is fairly limited to in-house made demos but still, those demos were pretty darn good for harnessing the power of the hardware.

The one thing that I really didn’t like is something that in my opinion has been plaguing Microsoft for ages: Internet Explorer.  I believe that Microsoft should take a page from the marketing book and just create a new brand.  There’s a reason why large companies create sub-companies with a different name, because they want their brand to be renown for something in particular.  When you hear ‘Hoover’ you think vacuum, when you hear ‘Kleenex’ you think facial tissue;  right now, when I hear ‘Internet Explorer’, I think security issue.  This is something that needs to change for people to be more confident around it.  You’ll find most browsers have shorter names that are easy to remember (Firefox, Safari, Opera, Chrome, etc) and it doesn’t need to include ‘internet’ in it (stop patronizing us).  I know the brand’s been around forever, but this isn’t the 90′s anymore.  You’ll also find that most browsers have a different brand just for the mobile version of it (Firefox is Fennec, Safari Mobile, etc).  I believe this is a necessary step in the evolution of Internet Explorer.  I personally would never use it for my own purposes because of its tight integration with the file system which I think is a security risk, but still, a new brand could definitely sway people who aren’t tech oriented as long as they do a good job of it.

Overall, I’m rather pleased with the software, it was still a little buggy at times but nothing blatant which is normal for something that hasn’t been released yet.  The hardware itself felt cheap, however I can imagine the experience being better once a good mobile hardware company (like HTC) gets their device out.  I can pretty much guarantee that any Microsoft enthusiast is going to be thrilled with this device.  Being an Android fan myself, I think this brings a new edge to the market where competition is always welcome.

It integrates completely with Eclipse (and Flash Builder) and has this neat feature called CodeSync that makes sure your model and code is always persisted between each other.  In other words, everything works together in an integrated workflow to save you time.

I’ll have to dig deeper, try this out on projects and do a complete review.  In the meantime, please support this initiative by registering and posting on the forum.

First things first, everyone that wants to develop Air for Android needs to sign-up to the pre-release program @ Adobe.  This is a central location to get all the latest files (like the Air 2.5 SDK) and documentation on this platform.  It’s also a good way to communicate with other developers, see projects that people are doing and post any questions or feedback about your development with Air.

Setup

Say you have Flash Builder already installed (duh?!), you need to download the Android SDK and then download the Android plugin for Eclipse (Flash Builder).  SDK first, just go to the link and download (and extract) the SDK that fits your flavor of OS.  Then just run the setup which should update the SDK to the latest and greatest.

Next you need to install the plugin.  Go into Flash Builder and go under Help->Install New Software… and then type in “https://dl-ssl.google.com/android/eclipse/” for the location and click on ‘Add’.  You should see the plugin available; just choose it and install.  After you restart, you should see this icon:

Green dude in a box, that definitely means the Android Virtual Device Manager

That icon is there for you to create emulators.  Yes, that’s right, you can run Android on your computer and install apps on it.  However, one fairly major caveat is that it’s fairly slow.  It’s good for a quick sanity check and QA, but any major debugging/quality procedure should be done on a physical device.

After you’ve created your emulator, make sure you get the latest Flex SDK (4.1) and extract the AIR SDK 2.5 right over the Flex SDK directory.  You are now ready to start coding; just make sure your project is pointing to the proper Flex SDK directory.

Code

From here you can take an old project and make it for mobile, create a new project or better yet, use my pre-made example project that I made for this tutorial.  This project is very simple, but the project is not what I want to concentrate on.  I want to focus our attention on how to make it all compile and deploy on Android.  This is what my application looks like:

Yeah, Android likes to be touched…

But not there.  Sicko.

Now, when you first start your project, you just need to set it as an AIR project and make sure your SDK directory points to the right location.  After that there are a few changes that need to be done or else it won’t package into an APK (the native Android application package) properly.

First, we need to make a small change to the code.  In your main application file, we need to change the WindowedApplication tag to just Application.  That’s all you need to do code-wise.  If you adhere to good Flex standards, you should have a main component that holds all your application logic; it’s easier this way to just drop the component into any container for easy interchange between Desktop or Web project.  Using this technique is crucial to keep code re-used high, while keeping project settings different from one another.

On to the settings of the application.  Open up the xml file that was generated by Flash Builder (should be in the form of ‘YourProject-app.xml’) .  There are a few things that needs to change, and a few things that need to be added that are Android specific depending on what your application wants to have access to (permissions).  Here’s the xml settings for my application:

xml version="1.0" encoding="utf-8" standalone="no"?>
xmlns="http://ns.adobe.com/air/application/2.5">
	<!-- The application identifier string, unique to this application. Required. -->
	<id>HelloWorld</id>

	<!-- Used as the filename for the application. Required. -->
	<filename>HelloWorld</filename>
	<name>HelloWorld</name>

	<!-- The name that is displayed in the AIR application installer.
	     May have multiple values for each language. See samples or xsd schema file. Optional. -->

	<!-- An application version designator (such as "<span class="hiddenSpellError" pre="as ">v1</span>", "2.5", or "Alpha 1"). Required. -->
	<versionNumber>1.0</versionNumber>

	<supportedProfiles>mobileDevice</supportedProfiles>
	<initialWindow>
		<content>HelloWorld.swf</content>
		<visible>true</visible>
		<autoOrients>true
	</initialWindow>
</application>

A few things are going on here.  You’ll notice that the namespace for the document changed from “http://ns.adobe.com/air/application/2.0″ to “http://ns.adobe.com/air/application/2.5″.  This is needed to target the new Air SDK.  There has also been some schema updates.  In 2.0 we had the “version” tag, but it’s now replaced with the “versionNumber”.  Another important part is the “supportedProfiles” tag which is needed to specify what type of device you’re aiming for and also helps for when you’re testing the application because the Flash Player window resizes to mobile resolution.  And to finish, you need to set up the ‘window’. The ‘visible’ tag is important or else you have to make the application visible through code and the ‘autoOrients’ is a flag to let your application know if it’s in landscape or portrait.  More information about extra tags are all in the documentation PDF on the pre-release page. One section that’s very important to read is the ‘Permissions’ section which is needed in the xml config.  Android needs this information to know how to give certain access to the application, like the camera or internet.

Build

You’ll notice that there’s a ‘build’ folder in the example project, that contains an Ant script.  I made this so that I can easily compile and install the debug and release version of my application.  Only need to change the property file to point to the Android and Flex SDK then execute the ‘run_debug’ or ‘run_release’ target and it’ll do the rest for you.

Debug

Of course, after you’ve tested it locally on your own computer, a lot of people would like to debug their application on the actual device (emulator debugging isn’t available currently).  You can do this directly from Flash Builder using Remote Debugging.  For this to happen, you need to make sure that the phone and computer are on the same network (make sure your phone’s wi-fi is on and connected).  The phone then needs to have access to the internet.  You may have noticed that I create 2 tags in the main application config file, ‘debug’ and ‘release’.

<!-- DEBUG SPECIFIC CONFIGURATION -->
<debug>
	<android>
		<manifestAdditions>
			<manifest>
				<data>
					<!--[<span class="hiddenSpellError" pre="">CDATA</span>[-->
						<uses-permission android:name="android.permission.INTERNET" />
					]]>
				</data>
			</manifest>
		</manifestAdditions>
	</android>
</debug>

<!-- RELEASE SPECIFIC CONFIGURATION -->
<release>

</release>

These tags get commented out when compiled.  This is where I added my internet permission request for Android.  Lastly, you need to make sure that you specify the IP of your computer within the build properties so that the swf knows where the debugger is.  Everything else is handled by the build script.

Then you just need to create a new debug profile under ‘Web Application’ and set URL to ‘about:blank’.  Set the project to the Air project that you want to debug.  An error will show saying that the “Project must be an Actionscript or Flex project”; you can just ignore that.

After that, it’s as simple as running the debug and opening the application on your phone.  When the application starts, it’ll try to connect to Flash Builder and start-up the remote debugging session.

Conclusion

I have to say, I was impressed with how simple the whole process is after you get to know how things work.  Being the efficiency Nazi that I am, having the Ant script build and deploy the whole project helps the whole process become a lot more streamlined.  Playing around with Air, I haven’t seen any weird behavior from the transition to mobile; you just need to make sure that your code is fast and appropriate for the screen size.  I was thoroughly impressed with the whole process.  It’s incredibly easy to make an application for Android and I hope that it will stay just as easy for other mobile OS’ in the future.

What I’ve done is extend TraceTarget and include some code so that any output goes to Firebug.  Simple enough, but very useful when you don’t have to have your debugger always running to see the output.

package com.codemonkeycreative.utils
{
	import flash.external.ExternalInterface;

	import mx.formatters.DateFormatter;
	import mx.logging.ILogger;
	import mx.logging.LogEvent;
	import mx.logging.LogEventLevel;
	import mx.logging.targets.TraceTarget;

	public class FirebugLoggerTarget extends TraceTarget
	{
		private var _dateFormatter:DateFormatter = new DateFormatter();

		public function FirebugLoggerTarget()
		{
			super();
		}

		/**
		 * Overrides the main function of TraceTarget that gets triggered
		 * every time someone tries to log anything using a Logger
		 **/
		override public function logEvent(event:LogEvent):void
		{
			// send the event to be traced normally
			super.logEvent(event);
			// Find the level
			var levelType:String = getLevelString(event.level);
			var level:String = includeLevel?levelType.toUpperCase():'';

			// Date variables
			var date:String = "";
			var d:Date = new Date();

			// Format date
			if(includeDate)
			{
				this._dateFormatter.formatString = "MM/DD/YYYY";
				date = this._dateFormatter.format(d) + fieldSeparator;
			}

			// Format time
			if(includeTime)
			{
				this._dateFormatter.formatString = "J:N:SS.QQQ";
				date += '[' + this._dateFormatter.format(d) + ']' + fieldSeparator;
			}

			// Find the category
			var category:String = includeCategory ? ILogger(event.target).category + fieldSeparator : "";

            // Then output it in firebug
            if(ExternalInterface.available)
            {
				ExternalInterface.call("console."+levelType, date + level + category + event.message);
            }
		}

		/**
		 * Returns the string equivalend of the level enum.
		 * This is needed for firebug to understand the console output.
		 **/
		private function getLevelString(level:int):String
		{
     		switch(level)
			{
				case LogEventLevel.DEBUG:
					return 'debug';
					break;
				case LogEventLevel.INFO:
					return 'info';
					break;
				case LogEventLevel.WARN:
					return 'warn';
					break;
				case LogEventLevel.FATAL:
				case LogEventLevel.ERROR:
					return 'error';
					break;
				case LogEventLevel.ALL:
				default:
					return 'log';
					break;
			}
		}
	}
}

Simply create this class and include it in your project. Then in your config file, just add the following line.

<utils:FirebugLoggerTarget level="{LogEventLevel.ALL}" includeTime="true" includeDate="true" />

You just need to change the properties like you normally on TraceTarget and the class does the rest.