The reason is simple. Consider the following code:

var loader:Loader = new Loader();
loader.contentLoaderInfo.addEventListener(Event.COMPLETE, onLoadComplete);
loader.load("myimage.jpg");

protected function onLoadComplete(__e:Event) {
	trace("Image loaded!");
}

The code will attempt to load an image and, when that is complete, display a message stating it did so.

The important thing to notice about this code is that it is non-blocking; when the call to load() is made, Flash just continues execution of your next line of code as if nothing happened. This is one of the many moments where Flash executes your requests asynchronously, letting you know later (via an event) when that request has been completed (or reporting on its progress, or any other event conditions necessary).

One big hurdle I had when I started working with Java is realizing that the language is, indeed, blocking everything you’re doing. Consider a similar code to load an image on Android:

URL fileURL = null;
try {
	fileURL = new URL("http://domain.com/myimage.jpg");
} catch (MalformedURLException e) {
	Log.e("", "Error: URL is malformed");
}
try {
	HttpURLConnection connection = (HttpURLConnection)fileURL.openConnection();
	connection.setDoInput(true);
	connection.connect();
	InputStream inputStream = connection.getInputStream();

	Bitmap bitmap = BitmapFactory.decodeStream(inputStream);
	myImageView.setImageBitmap(bitmap);
} catch (IOException e) {
	Log.e("", "Error: I/O Exception");
}

Apart from syntactical differences, the big distinction about this code is that when the Android system reaches the lines that make the connection and download the file, the whole execution thread hangs and waits for the file to download, continuing after it’s done. That’s why a completion event is not necessary; no code will be executed until the task is complete anyway.

This creates a situation where it’s very easy for a developer to write code that will technically work, but also hijack the main (UI) thread while running complex pieces of code, freezing the application. In an environment like this, it’s easy to see why threading is extremely relevant. It’s not just sugar; it’s something absolutely needed for a responsive user experience.

The solution in Android is creating a separate process for that kind of problem – a thread that executes a task, then, implements event or message dispatching as needed. The code is a bit more involved and there are different ways to do it; you have to decide between Threads or AsyncTasks, for starters. That’s why one of the first things I’ve done when working with the Android platform was build classes that allow me to work on the main UI thread without having to worry about blocking user execution all the time. With names like TextLoader, Loader, and XMLLoader, they essentially emulate what the Flash platform already does by default.

Maybe because they’re not as necessary in Flash, I used to think that working with threads was this untouchable apogee of low-level programming techniques that would only be necessary in crazily computationally expensive tasks. The reality, however, is quite different: on a platform like Android, if you don’t use separate threads for things that take more than a few milliseconds, you are doing something wrong.

In ActionScript 3, you attach an event to an object like so:

myObject.addEventListener(MouseEvent.MOUSE_DOWN, onMouseDown);

protected function onMouseDown(e:Event): void {
    trace("The object " + e.target + " was clicked.");
}

Considering that the second parameter to the addEventListener method is a function reference – a closure – you can reuse the same function in as many instances of as many objects as you like. Furthermore, you can attach several listeners to the same event on the same instance; this means that several different objects can track the same event.

Creating custom events is also fairly easy. In way, you don’t need any real class; just a string. You can certainly do something like:

myObject.addEventListener("mysuperevent", onSuperEventTriggered);

And you can easily trigger them from your object:

dispatchEvent(new Event("mysuperevent"));

You can also create new custom events, if you wish, so the event dispatched can carry more data with it. This can be done with separate event classes, like so:

public class DestructionEvent extends Event {

	// Enums
	public static const EXPLODED:String = "exploded";	// Object has exploded
	public static const IMPLODED:String = "imploded";	// Object has imploded

	// Properties
	_customData = __customData;

	// ================================================================================================================
	// CONSTRUCTOR ----------------------------------------------------------------------------------------------------

	public function DestructionEvent(__type:String, __customData:Object, __bubbles:Boolean = false, __cancelable:Boolean = false) {
		super(__type, __bubbles, __cancelable);
		_customData = __customData;
	}

	override public function clone(): Event {
		return new NavigableSpriteEvent(type, bubbles, cancelable);
	}

	public function get customData(): Object {
		return _customData;
	}

They can be easily dispatched:

dispatchEvent(new DestructionEvent(DestructionEvent.EXPLODED, {id:myId, somedata:"Some data"}));

And easily caught:

myObject.addEventListener(DestructionEvent.EXPLODED, onExploded);

protected function onExploded(e:DestructionEvent): void {
    trace("The object " + e.target + " has exploded, and it was carrying the " + e.customData + " custom data with it.");
}

Despite some syntax awkwardness (especially when transitioning from the ActionScript 1 and ActionScript 2 models), some performance problems, and some great alternatives, this system does the job well, allowing developers to glue together encapsulated pieces of code pretty seamlessly, and is supported consistently through the AS3 ecosystem.

Hence my surprise when I got to Java.

First of all, Java doesn’t allow closures (at least not yet), so you can’t pass functions as parameters for anything. This means I couldn’t even build an event dispatching (or signals) system like the ones I was used to in ActionScript 3.

The first examples I found covering the event model on Java were pretty awful. They were something like this:

public class MyClass implements OnClickListener {

	public MyClass() {
		Button myButton = new Button();
		myButton.setOnClickListener(this);
	}

	public void onClick(Object o) {
		Log.v("", "Object " + o + " was clicked);
	}
}

The problem with this is obvious: by forcing the instance that contains an object to implement a listener interface to the object, it doesn’t allow me to track the same event from two objects at the same time (or even listeners that have method name collisions). In my above example, if I wanted to have two buttons, I would need an additional condition inside onClick to detect where the event came from. This could easily get ugly.

The reason why I’m mentioning it here is because that kind of example was quite easy to find and it baffled me for a while that someone would adopt that kind of design for complex applications.

As it turns out, however, event listeners in Java are a little bit better than what that typical example makes it look like. You can create and extend an object of a class (even an interface!) inline – so the real way to write the above code is something like this:

public class MyClass {

	public MyClass() {
		Button myButton = new Button();
		myButton.setOnClickListener(new OnClickListener() {
			@Override
			public void onClick(Object o) {
				Log.v("", "Object " + o + " was clicked);
			}
		});
	}
}

Still a little bit strange to me (still used to AS3 I suppose), but much easier to read and use.

Implementing custom events is also pretty easy. Here, again, I did a mistake initially – I thought you had to create a separate class for every kind of event you wanted. My initial classes were always awkwardly accompanied by a bunch of separate interfaces for events, making my own packages pretty polluted.

As it turns out, there’s a better, cleaner way of declaring events too: as interfaces declared inside the classes themselves, and then referenced from outside. This seems to be the norm in Java conventions. In a nutshell, my classes that require an event look like so (in a hypothetical button clas):

public class MyButton {

	// Instance references
	protected OnClickListener onClickListener;

	// Constructor
	public MyButton() {
		...
	}

	// Public methods
	public void setOnClickListener(OnClickListener __listener) {
		onClickListener = __listener;
	}

	// Interfaces
	public interface OnClickListener {
		public void onClick(MyButton __button);
	}

	// Internal dispatching
	protected void dispatchOnClick() {
		if (onClickListener != null) onClickListener.onClick(this);
	}
}

And using it is just like before:

myButton.setOnClickListener(new MyButton.OnClickListener() {
	@Override
	public void onClick(Object o) {
		Log.v("", "Object " + o + " was clicked);
	}
});

Notice how the name is used when instantiating (new MyButton.OnClickListener()) to avoid collisions. I’ve seen this in several differenr packages (mainly Android’s own framework) and it’s a pretty clever solution to avoid name collision given that so many events can share the same name.

All in all, despite the syntactical differences, event dispatching in Java works the same as in ActionScript 3, expect for one major caveat: listeners are normally set, not added. This means you cannot have more than one listener to the same event on the same object.

Personally, I’ve added a multi-listener feature to some of my classes (it’s just a matter of adding to an ArrayList afterall), but the real problem is that none of the established classes follow that pattern. So… be careful when adding your listeners in Java, lest you erase a listener that was set previously.

Luckily, I saved a lot of notes in the process, and I thought I’d share my impressions here, so other developers – of any platform, but Flash/ActionScript especially – could read them and know what to expect when doing development for the Android platform. My posts will focus on specific topics and while they won’t cover the whole range of features or capabilities of the Android platform (there are many other places and better articles for that), they’ll cover what surprised me the most.

My first note is: Java has no getters and setters to work as mutators and accessors in the same way that ActionScript (or C#, or others) support them.

Consider the following code:

protected var _position:int;

public function get position():int {
    return _position:int;
}

public function set position(__position:int):void {
    _position = __position;
}

What this code does is create a position pseudo-variable. When you read its value, it simply returns the value of the protected variable _position, which wouldn’t normally be accessible to other objects. Likewise, when you set that property to a value, it simply sets the value of position. This means those methods could then be used as if they were a normal variable, like so:

someObject.position = 0;
trace (someObject.position); // 0

Using a getter/setter combination like that is, of course, fairly useless, since it’s just passing values along, without providing any additional benefit. The real advantage is when you need to have additional code bound to either method. Consider, for instance, that a getter method doesn’t need to be bound to the value of an existing variable, but instead generate its own return value as needed:

public function get numBrokenItems():int {
    // Calculate the number of broken items on a list
    var brokenItems:int = 0;
    for (int i = 0; i < items.length; i++) {
        if (items[i].isBroken) brokenItems++;
    }

    return brokenItems;
}

// Traces the number of "broken items" in this instance
trace(someObject.numBrokenItems);

In the same way, a setter can be used to run additional code after a variable is changed:

public function set x(__x:int):void {
    // Simple implementation of a redrawing method for illustration purposes only
    // This is not very efficient; for a real implementation of position getter/setters
    // it'd be better to have display invalidation and a deferred redraw()

    // Sets the new value
    _x = __x;

    // Redraws the item
    redraw();

    // Dispatches an event
    dispatchEvent(new MyObjectEvents(MyObjectEvents.MOVED));
}

// Changes myObject's 'x' variable, redraws it, and dispatches an event that it has moved
myObject.x = 10;

It should be obvious by now that I’m particularly fond of using getters and setters – I believe they give developers a lot of control, especially for fluid, animated interfaces; getters and setters are a requirement if you need easy tweening with any generic tweening library out there, for example.

Alas, it is not so in the Java world, where Android developers finds themselves in.

In Java, you can still have accessors and mutators (even though some people hate them), but they are normal functions and methods. It’d look like this:

protected int _position;

public int getPosition() {
    return _position;
}

public void setPosition(int __position) {
    _position = __position;
}

This means you access them as you would normally access functions:

someObject.setPosition(0);
Log.v("", someObject.getPosition()); // 0

It works well; I’m yet to see a real disadvantage (you can’t do the typical ActionScript-style tween syntax on Java anyway, so the main advantage of having a pseudo-variable like in ActionScript is moot). But the result is a situation where you’ll always dealing with a bunch of different functions for every class, and, in my opinion, a polluted interface where every variable access is duplicated and actual variables are pretty much never used. There’s probably an argument to be made here in favor of simplicity and encapsulation (whether the value is generated or comes from a hidden variable), but not sure whether that’s enough; right now I’m keeping an open mind and accepting the language for what it is (my love for getter/setters notwithstanding) since it’s a new platform and assumptions can be risky.

The application was written in “pure” AS3 (no components or frameworks used), using FDT 4, and compiled with Flex SDK 4.5.1.21328, and AIR 3.0.0.4080.  The project was mostly adapted from the built-in mobile templates provided by Powerflasher, but the iOS and Android project versions (and desktop) were merged together.

FDT 4 with the Kana Mind project opened

Even though the application is only available in the Android platform now, all versions were built together and use the same code. I just haven’t tried releasing an iOS version on Apple’s app store because I’m still adding features to it and fixing some bugs (as far as I know, Apple’s policy doesn’t allow beta applications on their store).

Interestingly, I’ve also been developing a native Android application at work for the past few weeks, so developing this small project allowed me some important insight on how using each platform compares. I’ll talk about it in parts.

Coding

The cool thing is that for an ActionScript developer like me, it’s pretty easy to just leverage your knowledge to another platform. You basically learn about the interface caveats and you’re good to go – continue building your mobile application as you would do with a normal website. It’s a pretty rapid development.

Kana Mind TO-DO notes

Comparing AIR to Android, things can be both good and bad. For example, it’s interesting how it is easy to create custom visual content in Flash – it’s all vector-based (you can resize anything), the display list is pretty easy to deal with. Other important point is that Flash is a pretty mature platform, and many of the most things you’d need in order to develop a proper, rich, user interface are already available in the platform, in the form of easy-to-use libraries, or built-in Flash Player capabilities (don’t get me started with using Events or XML loading in Android – Flash is heaven in comparison).

On the other hand, when developing for a native platform, you can take advantage of the built-in interface frameworks – buttons, scrollers, etc – that are already there and used by everyone. With Flash, you have to build them yourself, and given the differences in user interactivity patterns (e.g., I had to build a MobileButton class so I could have a LONG_PRESS event), you can’t just use anything that was developed for the desktop. I also ended up having to rebuild my editable textfield classes to take advantage of native features like StageText. Third-party libraries for all of that already exist, of course, but my point is that if you’re like me and you like to have complete control over your interface elements, expect to have to adapt them to that platform.

Developing the application probably took around 50 hours, on and off, split around my free time. No tablet version is available yet (I don’t have a tablet I can test on), but I believe doing so is trivial – just making sure things work and coming up with slightly different layouts based on screen size conditions (right now, the application works, but of course things are just resized and there’s no landscape mode).

Testing

One interesting thing is that testing is, in most ways, easier when you’re using AIR. For Kana Mind, I’d normally compile the application and run it as a desktop application – no emulator needed and, of course, very fast.

Kana Mind running as a desktop application (purple boxes are for debugging purposes)

Compiling and deploying to an Android mobile device was also pretty easy, since installation on a device can easily be done automatically after compilation.

The issue here is, of course, developing for iOS. Deployment isn’t automatic – you have to compile a new .ipa file and the sync it using iTunes. Luckily, though, I didn’t have to do that very often as the application simply worked the same in Android and iOS.

Some Kana Mind device testing

Finally, at least in my case (I wasn’t many mobile-exclusive features), testing on the devices wasn’t frequently needed; I’d usually spend a few hours coding and testing in the desktop, and then doing a round of tests on a device to make sure performance was OK, and that was it.

Adaptation

Flash developers are generally very well prepared for most fragmentation woes – they’re used to dealing with different screen sizes and CPUs. Doing mobile development introduces news challenges, however: you have to deal with screen density (rounded corners, text size, or element margins, for example, can’t just be pixel-based), and different input schemes (what to do if you want to make your application available to a device that doesn’t support touch screens?).

None of this is a showstopper, however. For screen density, I created a function that takes Capabilities.screenDPI (which is useless in desktops, but mostly correct on devices) into consideration and I use that instead of any actual pixel dimension.

Performance

Performance is one of those topics that are very difficult to discuss. People can easily have unrealistic expectations, especially from a platform that is being ported from the desktop to a mobile device. One can easily expect their code to work the same, forgetting it’s a completely different device – with a lot less processing power and memory.

With that being said, it’s easy to be critical of AIR (and Flash) performance in a mobile device. Obviously, it doesn’t work the same as in a PC. My general assessment, however, is that performance of a mobile AIR application is for the most part OK, but not great.

Overall, user interaction and screen updates work well. It is difficult for one to achieve, say, 60fps on an animation, but as long as you keep all your screen rendering in check (knowing when to use bitmap caches and when not to, how to avoid re-renderings of unnecessary elements, etc), it is easy to make a responsive application that works at around 30fps.

The negatives about the platform are the ones that pertain to points the developer has no control over. To me, these are especially true during the application initialization.

The problem for me is that regardless of what you have on your first frame, application initialization takes a long time – up to 6 seconds, on my experience – before any code is even ran or anything is displayed (this is probably especially true of the Android captive runtime, which I have used for Kana Mind). This is true even if you split the application in two frames, like you’d do with an online SWF, to offload code initialization and asset loading.

After the application is initialized, there’s also a few seconds where the application is unresponsive (doing some major memory swapping, I’m guessing), causing user interaction to be glitchy or not work at all.

A long startup time for applications is one of those things that can drive a user crazy. You click an icon and you expect feedback – when that doesn’t happen and you’re just starting at a black screen for too long, it’s easy to just assume the application has crashed or that it’s just some shitty code. It taints the user’s opinion of your application, regardless of what happens later.

Size

When it comes to mobile applications, size matters. Because of this, it’s important to remember the AIR captive runtime adds around 8mb (Android) or 5mb (iOS) to the application size, so it can be pretty bulky. Of course, this expands a little bit once it’s actually installed on a device – Kana Mind itself takes around 20mb of space once it’s installed in my Nexus S.

In Android’s case, if you choose to have a non-captive application instead, it works better – it’s basically your SWF size – but then it requires users to install the AIR runtime.

Conclusion

Regardless of the result, building an application using AIR is one of those things I really wanted to do, to get a chance to test the platform and find its pros and cons myself. As it turns out, there’s plenty of those, so it’s hard to get to a final verdict on whether someone should use it or not.

If you’re building something quickly or free and you want to use the same code on iOS and Android (including mobile devices and tablets) and potentially desktop, AIR is the way to go. You can have the same project (with maybe just some conditional layout or user interface elements) and, at least in my case, cross-platform testing is seldom necessary. It’s a very rapid development and testing workflow and, if you spend time building some user interface and application libraries to work around the caveats of the platform, you’ll be able to create cross-platform applications in the blink of an eye.

On the other hand, it looks like the platform has reached its limits in terms of performance and there’s not much that can be done (I’d love to be wrong, though). Mobile AIR applications are usable, but not exactly snappy, even if you take all the performance tricks out of the bag. The unavoidable truth is, if you want the best performance for your application, there’s no way around it: it has to be a native application.

I’m pretty proud of how Kana Mind turned out and I’ll probably do a few parallel applications for other languages, as I like how well the teaching algorithm works, and still use it as my excuse to play with AIR. But if I was developing a serious, bigger, commercial application, I’m not sure I’d have gone the AIR route.

TL;DR: AIR is good. But not for every case.

I learned the symbols with the help of books and software, and I got to a point where I could read Kana-based Japanese writing pretty well. Then I promptly forgot everything. I’d remember a symbol or two, but in general, one year later, my knowledge of Kana was back to the starting point.

The problem with learning a new language is that if you don’t practice frequently, it’s very easy to forget everything you’ve learned, maybe especially one that depends so much on learning new characters. That’s when it dawned on me – I needed to have some software that helped me keep the symbols and their romaji counterparts memorized. A software that would understand when I forgot something, and help me record that again in my brain. Not just something to test me, but something to target the testing in what was more relevant for me.

I kept that idea in my mind for many years, and testing development of an Adobe AIR-based application was the perfect excuse to build it in my free time. Therefore, I have just submitted a new application to the Android market that does just that. It’s called Kana Mind.

The application is still in beta. This means it works well, but it’s missing some features like proper support for big screens (tablets) and landscape mode. I’m still working on it. The iOS version is working pretty well too, but will only be submitted to the market once it’s out of beta. But even in beta form, this is the kind of application I wish I had many years ago (and, luckily, beta-testing and playing it is already making me relearn Kana in the subway).

There are many games that get you to test your Kana knowledge by matching it with their romaji equivalent – memory games, crossword games, dictionary games, and the alike. However, none of them seem to be as serious about teaching, testing and reinforcing memorization, nor as focused on the task of memorizing Kana, as I believe Kana Mind is.

The way Kana Mind works is by slowly presenting you just a handful of symbols at first. So when you start the game, it cycles through the same 8 symbols – those are the “active” characters you’re being tested against.

While playing, if you pick the wrong pair, the game marks that option as wrong. Then you need to try again, until you get it right; the game then proceeds to the next character in the series of active characters, cycling through them in a randomized fashion.

After you get the same character right 7 times in a row, the game assumes you’re proficient with that character, so it marks as learned and adds a new symbol to the mix. So get something wrong again and again, and you’ll see it often; get it right several times in a row, and it’ll be skipped pretty quickly. This goes on until you reach “proficiency” in all characters. Symbols get more difficult to match as you progress, too, since symbols are grouped into levels of difficulty (although this is invisible to the user).

One additional aspect of the whole algorithm is that after 7 days of reaching proficiency with a specific character, the game assumes your knowledge of that character is decaying, and it throws it again in the mix of characters. Get it right once, and it won’t bother you again; get it wrong, and back it is to the list of characters you’re being tested again.

After you “finish” the game – reaching proficiency in all characters – the game uses its “maintenance” algorithm, always testing you against characters that you haven’t seen in a while.

This helps students that are already proficient enough with the language to keep their knowledge fresh – one needs only to play the game once in a while to test themselves. If you have trouble with any character, the game will be sure to make note of that and test you again and again.

And finally, Kana Mind is a serious application, but overall it was done more as a test than anything else. Therefore, it’s a free application.

I’ll have a more technical post about the pros and cons of the Adobe AIR platform soon. In the meantime, comments and suggestions about the application are always welcome.

Only that when I was trying to use it (with Flex 4.5 and AIR 3), it wouldn’t work, but instead fail with this error message during execution (even though StageText was included on airglobal.swc):

Exception fault: VerifyError: Error #1014: Class flash.text::StageText could not be found.

An online search for the error and its meaning provided no results (!) – information on the new class is pretty hard to come by. So after some trial and error (and luckily stumbling into this video about setting up FDT for Adobe AIR 3 and Flash Player 11 development), the reason is: you need to tell the Flex SDK compiler to compile against a newer version of the SWF format that enables that feature.

So the solution is simple: just add this parameter to your Flex SDK compilation settings (this is in addition to any target-player switch already present).

--swf-version=13

It should then work flawlessly.

Read more about that switch here. The same applies when using StageVideo.

Much like my old Flash video playback benchmark, this is one of those things that started with an assumption that I wanted to investigate further (in this case, “browser updates take much longer than Flash Player updates”) but that ended up with unexpected results that made me look at things from a different perspective.

The takeout of all of it is that while the adoption rate of new Flash Player versions is pretty good (and getting better), browser update rates are getting better too, and Google Chrome is leading the pack, with a user adoption rate that is even faster than Flash, overall (and the frequency of updates released has nothing to do with it). It means new HTML features are making it out to user’s computers faster than ever, with the exception of IE, which continues to hold the platform in the past.

There’s more to it, of course, as it’s a lengthy article (but one with pretty charts to look at). So for the full story, continue on to the developer’s guide to browser adoption rates.

Little did I know that two decades later, I’d be working at this neighborhood myself – no hero costume required – since that’s where Firstborn offices were when I started working here in 2009.

Today is the last day we’ll be in Hell’s Kitchen, though. Firstborn is now moving to a new office in Tribeca, and that’s where the NYC subway will be taking me to starting next week.

We’ll all very excited for it, but there’s a bittersweet sentiment going around as we count the things we’ll miss from this area.

Our awesome doorman, the T. Rudy’s bar, doorman or no doorman. Lenny’s sandwiches (how come those are not all over town?). Rio & You‘s friendly service and grandma-like owner. Kodama‘s curry and the takeout attendant’s looks of bewilderment when we invaded the small shop in 6 or more people. Eating outside at Motherburger. Standing in line for Shake shack. Pretending you’re Sean Connery when you say Schnippers. Picking a random option at Island burgers. Ordering late Five Napkin. Heck, even stuffing your face with some Chipotle.

(And as far as I know, no super hero lives in Tribeca.)

There’s certainly a lot we’ll come to love in the new neighborhood. But, for a long time, there’s a lot we’ll be missing.

Thanks, Hell’s Kitchen. You’re half of New York for me, and it has been a pleasure.

I finally spent part of this weekend setting up such an environment for Flash development that allows me to run my application locally (on the desktop) and on a device (Android) without any porting hassle and I can state that things are nearly as good as they get when it comes to ease of development; it just takes a while to get it running.

(I haven’t tried iOS yet because I don’t have an iOS device at home, but that’s the next step).

I’m using FDT and the Flex SDK with Adobe AIR for development. And while FDT’s blog has a ton of information on how to set up an environment for mobile devices, it’s not complete as it skips the mobile device SDK parts (I guess it assumes the developer already has everything in place). So because of this, I thought I’d share my notes on how to set up a  Flash development environment with Android as a target, with links to the necessary information on each step.

(I’m using FDT because it’s my IDE of choice. Everything I’m doing is possible with other ActionScript development tools – even Notepad – and luckily no commercial tools are required for compilation or deployment, but of course setting up your environment and project templates will be very different depending on your preferred IDE).

So those are the steps:

1. Download and install FDT in case you don’t have it.
2. Install the Flex SDK 4.5.1 and Adobe AIR 2.7.1. Extract them to the same folder (Flex already comes with AIR, but it’s an older version). For a tutorial on this, see this blog post (first video).
3. Install the Android SDK. This can be done by following the instructions on this page. You don’t need to download Eclipse, Eclipse plugins, samples, or the different APIs, however; that’s for native Android development. You’ll only be using the Android tools and, sometimes, the driver for your specific device.
4. Setup your phone for debugging by following these notes (skip step 1, this is done automatically). This includes installing the drivers for your device, if needed.
• Note for Nexus S users on a Windows machine: the documentation mentions that the USB Drivers for your devices are at “…/android-sdk-windows/usb_driver“. This is incorrect; that’s version 3 of the drivers. You need version 4, which is actually at “…/android-sdk-windows/extras/google/usb_driver“.
5. Connect your device to your computer using the USB cable.
6. Test your device. If you did everything correctly, running the command like adb devices (from “…/android-sdk-windows/platform-tools/“)  should list a connected device ID.
7. You can now run FDT and create a new project using the built-in mobile development templates. See this blog post again for more information (second video). Make sure to create your project on the default FDT workspace – if you use a separate folder, the ANT tool won’t work so your application will be compiled but never deployed (I’m still investigating this, as I always use separate folders).
8. Now you can finally write your application’s code. When testing, run the wireless-based debug profile (found on “Run” > “Debug Configurations”) as explained in that blog post again. Your application will be automatically compiled, installed and ran on the device. Notice that you’ll need a wireless network already setup so the device can connect back to your computer to get the result of the trace() statements; for more information on how debugging is done, see the reference to the fdt.startDebugger command, and to AIR’s -connect parameter.

The cool thing about compiling and debugging like that is, if you use the first launch profile, you compile a normal application running on your computer, like you would do with a normal AIR or Flash application; but if you use the other launch profiles, it runs on your device. It’s a super easy testing and deploying method and it certainly beats, say, using the Android emulator for native Android development (although, of course, you’ll have to keep performance in mind since your application will run much faster as a desktop AIR application).

With a few conditionals (or even different “Main” classes), it should be easy to have the same code based being used for deployment on several different platforms. Right now, FDT’s mobile templates offer two separate templates for Android and iOS development, but merging them together for a single project that supports everything should be possible. I plan to create a template that does that as soon as I have some free time and can get my hands on an iOS device.