Dabbling with Drag and Drop in Adobe AIR with Flex 3

One of the fun things about my job is checking out where we can use new technologies to enhance our service offering. I’m a doubting Thomas when it comes to new technologies. I don’t like to rely on third party sources (whether blatant marketing, analyst reports or even developers excited about a new tool). I need to have a go myself. 

I’ve been keeping tabs on the development of Adobe AIR over the past months. Readers of this blog will know that I’m an ardent believer that the user experience needs to be got right first, and only then should be enhanced with something whizzy. But for sure we all want to have a range of whizzy tools available to us to use judiciously.

So I thought I’d have a look at how easy it is with Adobe AIR to do some drag and drop.

A few points before I start. You can develop AIR applications in a number of languages, e.g. Flex or HTML/JS. The documentation isn’t all that clear but from what I can figure so far:

  • If you use HTML/JS then you are limited to the usual drag and drop of items within a web page. But you can’t drag to/from the desktop
  • If you want to be able to drag items to/from the desktop you need to use something like Flex.
  • Flex apparently also supports limited dragging of certain items from the application to the desktop. From what I can figure in practice this means dragging a data table into a spreadsheet.

So I’m using Flex in this example. There is some sample code out there (e.g. http://www.mikechambers.com/blog/2007/11/07/air-example-native-drag-and-drop/) but when I checked it out it hadn’t been updated for Flex 3. The example below is an updated version based on the code at http://blog.everythingflex.com/2007/06/18/simple-drag-and-drop-air/
I’m on Windows so I’m using the mighty FlashDevelop. The example below is using 3.0.0 Beta 8.

1. Fire up FlashDevelop
2. Select Project -> New Project
3. Select an AIR MXML Project and give it a sensible name (e.g. dnd)

Flash Develop
Flash Develop

4. Expand the src directory and delete the Main.as file
5. Replace the contents of the Main.mxml file with the following code (WP isn’t keen on pasting in the indents – so no indents today).

<?xml version="1.0" encoding="utf-8"?>
<mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml"
import flash.desktop.NativeDragActions;
import mx.controls.Alert;
import mx.controls.Image;
import flash.filesystem.File;
import flash.desktop.ClipboardFormats;
import flash.events.NativeDragEvent;
import flash.desktop.NativeDragManager;

private function init():void{

public function onDragIn(event:NativeDragEvent):void{

public function onDrop(event:NativeDragEvent):void{
NativeDragManager.dropAction = NativeDragActions.COPY;
var dropfiles:Array = event.clipboard.getData(ClipboardFormats.FILE_LIST_FORMAT) as Array;
for each (var file:File in dropfiles) {

//NB The following is case sensitive - so Image.JPG will produce "unmapped extension"
//but Image.jpg will work fine
trace("Adding file with extension [" + file.extension + "]");
switch (file.extension){
case "png" :
case "jpg" :
case "gif" :
Alert.show("Unmapped Extension");

public function onDragExit(event:NativeDragEvent):void{
trace("Drag exit event.");

private function addImage(nativePath:String):void{
var i:Image = new Image();
if(Capabilities.os.search("Mac") >= 0){
i.source = "file://" + nativePath;
} else {
i.source = nativePath;




6. Hit F5 to test the application
7. Drag images into the big empty window to see them shown there

Simple as that. You will notice inside the code that the app is looking for .png, .jpg, .gif files only. Turns out these suffixes are case sensitive inside Flex so make sure your file extensions are lower case. Or change the code.

Conclusion from this:

  1. If it’s correct that HTML/JS can’t be used to support drag and drop between the application and the desktop then this is not desperately surprising when you think about browser architecture, security, sandboxes and so forth.
  2. If using Flash/Flex is the only way to address this challenge then so be it. My initial worry was that in order to use Flex in anger I’d have to hire a whole cadre of Flash/Flex developer/designers. But it turns out that Flex is very reminiscent of HTML and JavaScript/Java so there isn’t going to be much of a learning curve for developers already familiar with web apps.
  3. I’m glad this exercise forced me to have a look at Flex because it has a lot going for it as far as aspects of RIAs are concerned.
  4. But. I have a concern about how maintainable Flex code is in the long run. Check the example here about the use of View States, in particular the example of how to maintain three different-sized windows. To be fair there are some MVC frameworks out there for Flex but even so I would be tempted to keep AIR usage to the fringes of my applications for now.

Careful with all that Flash, Flex and AIR

I read with interest James Governor’s write-up of his Adobe/SAP nanoconference  and enjoyed watching the video, showcasing all kinds of cool new UI stuff you can do with Adobe AIR

There was an example with screens swooshing around like they do on the iPhone. There was an example of a car insurance claim where rather than describing an incident on paper they can drag around images of cars to “draw” an example of who crashed into whom, when and how.

And then there are the likes of http://www.zui.co.uk/ who use Adobe technologies to build cooler UIs for SAP – certainly cooler than the ones I remember from 1999.

This is all great.

But in amongst all this whizz-bang technology it’s worth remember that first and foremost users want interfaces that let them get on with their day jobs quickly. Google is always a good example for a simple, pretty ugly, user interface that seems to work well.  Here is a page I’ve linked to before on usability – it’s well worth a read before loading up your user interface with bells and whistles.  http://www.asktog.com/basics/03Performance.html

And here are a few gems from random pages of Gui Bloopers by Jeff Johnson (the Web 1.0 version from 2000) that are still worth bearing in mind:

On the research at PARC into what has now become established as the GUI:

Fairly quickly, PARC researchers relized that one that that did not work very well was for the computer – or more accurately, its software – to unilaterally move objects around the screen. Some researchers had initially assumed that it would be helpful to users and more efficient for software to sometimes move or “warp” the mouse pointer automatically to new positions. Similarly, some researchers tried having their software automatically reposition, stretch, and shrink windows “when appropriate”. Although well-meaning, these attempts to be helpful and efficient disoriented and frustrated users more than they helped them.

And on designing consistent screen layouts (the Ribbon in Office 2007 may be a lot better once you are used to it, but for most people the menu structure in Office 2003 was just fine and shouldn’t have been messed with):

The vast majority of computer users these days are interested in getting their work done. They are not interested in the computer and its software per se … They want the computer and its software to help them develop habits, and then they want to forget the computer and software and concentrate on their work. In fact, they are often so focused on their work that if they are looking for a Search function but the application window spells it “Find”, they may overlook it. For this reason, developers should design user interfaces as if the prospective users were autistic – people who abhor any difference or variation in their routine.

Get these basic considerations wrong and it doesn’t matter how much AIR gadgetry you throw at the UI. It’ll just be putting lipstick on a pig.