All 23 entries tagged Air

AIR FileReference and scope

I ran into a small problem recently in my AIR application when using FileReference to initiate and monitor a download operation; no events from a FileReference object created within a method were being fired. After a quick check of the Livedoc entry I found the issue:

if the FileReference object goes out of scope, any upload or download that is not yet completed on that object is canceled upon leaving the scope. Be sure that your FileReference object remains in scope for as long as the upload or download is expected to continue.

So basically a FileReference object needs to be created in such a way that it stays in scope for the duration of your operation; if you instantiate it within a method it there’s a good chance it will go out of scope and any events you were waiting for from it will never fire. The easiest solution is to declare it outside of the method, so instead of:

private function download(event:MouseEvent):void 
{
    var fileRef:FileReference = new FileReference();
    fileRef.addEventListener(IOErrorEvent.IO_ERROR, onIOError);
    fileRef.addEventListener(Event.COMPLETE, onComplete);
    //etc.
}

you need to do something like this:

private var fileRef:FileReference();
private function download(event:MouseEvent):void 
{
    fileRef = new FileReference();
    fileRef.addEventListener(IOErrorEvent.IO_ERROR, onIOError);
    fileRef.addEventListener(Event.COMPLETE, onComplete);
    //etc.
}

Sorted. Afterwards I also found more info about this via a couple of useful blog articles here and here.

Steven Carpenter : 04 Nov 2008 20:34 |  Tags: Air Development Flex |  Comments (4) |  Close comments |  Report a problem

AIR: Rendering native system icons, Pt.1

I was asked how I got AIR to display native file icons in a component – it’s pretty easy to do, although my method is a little convoluted to explain without posting reams of code, partly because it’s buried in a sequence of Cairngorm events/commands but also because there a couple of important issues to watch for and handle (see bottom of this entry for those). Here’s an overview:

AIR has support for retrieving the native system icons in whatever supported sizes exist. The icons are stored as a property of each File object as BitmapData, in an array, File.icon.bitmaps. Each element in the array is the same icon at different sizes, e.g. 32×32, 16×16 etc.

In order to get at an icon at a given size, you can’t rely on what sizes are available at a given element position, so you need to create a new (empty) BitmapData object at your target dimension, then iterate through File.icon.bitmaps until you hit the matching-sized BitmapData object. Once you have a match, you can put the matching data into your own BitmapData object. Here’s a brief example:

public function get32Icon():BitmapData {
            var myFile:File = new File("C:/foo.txt");
            var bmpData:BitmapData = new BitmapData(32, 32);
            for (var i:uint = 0; i < myFile.icon.bitmaps.length; i++) {
                if (myFile.icon.bitmaps[i].height == bmpData.height) {
                       bmpData = myFile.icon.bitmaps[i];
                   }
               }
               return bmpData;
         }

Obviously you need more than the code above to handle situations where the 32×32 icon isn’t available, but that’s a basic way to grab the icon as BitmapData. At this point you could create a new Bitmap object and give it the captured data, but for my application I set the icon data back onto an Object that represents the File object (I actually used an ObjectProxy because I wanted to bind this data to an ItemRenderer later) – again this becomes important later on.

Okay, so now I have my icon data, in an object that also contains other information about the file, like its name etc. To display it in a TileList, or other component, I just use a custom ItemRenderer. I set up an image tag for the icon within the renderer:

<mx:Image width="32" height="32" source="{getIcon(data)}" />

...and then create a method in the renderer to return the icon data to the image component:

private function getIcon(data:Object):Bitmap {
        var bmpData:BitmapData = new BitmapData(32, 32);
        bmpData = data.icon;
        var iconBmp:Bitmap = new Bitmap(bmpData);
        return iconBmp;
        }

Now each time the ItemRenderer has to render an item, it gets the relevant icon, the filename etc. and displays them within the TileList – easy! Here’s the result, showing the app running in XP and OSX:

But there are caveats; AIR does not behave consistently on all platforms with icon data. Here are couple of the problems I encountered:

• Performance. There seem to be some differences in execution time for file system queries in AIR. Originally I had an ArrayCollection of File objects as the DataProvider for the TileList, retrieving icon data for each one in the ItemRenderer as required. On Windows this seemed fine, but on Mac OSX it proved to be very slow, to the point where my app was unusable. I overcame this by using the Flex Profiler to see what was causing the problem, finding that the underlying get icon() execution time was very long on OSX. By grabbing the icon data once, then caching it and other key File properties into an ObjectProxy, I was able to get OSX performance almost on a par with Windows, and this also sped things up elsewhere because I was calling get icon() once, rather than per-item in the renderer. It also improves scrolling performance of the TileList because that component renders items dynamically as they are displayed. In fact you could go one step further than I did and extend UIComponent to improve render performance even more.

• Missing icons. AIR on Windows won’t retrieve some icons, in particular for .EXE, .TMP and .INI files. These are stored in shell32.dll on XP, but for some reason AIR can’t get to them. I also found one or two similar issues in OSX. AIR on Linux using the most recent AIR beta just returns a null value for File.icon.bitmaps, so rendering native icons is currently impossible. You need to add some way of checking for a missing icon in these cases, and swop it out for an embedded one if you can; I created a temporary workaround where I parse the BitmapData for null pixel values.

The next part of this article will deal with how I got native icons to render for remote files, but I bet you can already guess how that’s done…

Steven Carpenter : 26 Sep 2008 14:01 |  Tags: Air Development Flex Rich Media |  Comments (5) |  Close comments |  Report a problem

AIR: Creating a custom status bar

It’s easy to create your own customised status bar for AIR applications. For my example, I wanted to be able to display a network status icon that indicates whether the application is connected – this is bound to a state set by AIR’s network service monitor, via Cairngorm.

First of all, in your application MXML file, make sure showStatusBar is set to true, add the statusBarFactory parameter and point it to your custom component:

<mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml" 
    layout="absolute" 
    showStatusBar="true" 
    statusBarFactory="{new ClassFactory(CustomStatusBar)}">

Then just make a new MXML component called CustomStatusBar and add any elements you want to display in your new status bar. There are a couple of things AIR will be expecting from a StatusBar, most importantly the status setter and getter methods required to display status text:

<?xml version="1.0" encoding="utf-8"?>
<mx:HBox width="100%" 
    xmlns:mx="http://www.adobe.com/2006/mxml" 
    backgroundColor="#E3E1E1" 
    >
    <mx:Script>
        <![CDATA[
            import mx.events.FlexEvent;
            import uk.ac.warwick.filesclient.model.AppModel;
            [Bindable] private var modelLocator:AppModel = AppModel.getInstance();

            [Bindable] public function get status():String
            {
                return this.statusText.text;
            }

            public function set status(value:String):void
            {
                this.statusText.text = value;
            }

            private function showNetworkStatusIcon():void
            {
                var path:String = "";
                if(modelLocator.isNetworked)
                {
                    statusIcon.source = "greenlight.png";
                } else {
                    statusIcon.source = "greylight.png";
                }
            }
        ]]>
    </mx:Script>
    <mx:Label id="statusText" paddingLeft="7" fontAntiAliasType="advanced"/>
    <mx:Image id="statusIcon" 
    toolTip="Network status"  
    horizontalAlign="right" 
    width="100%" 
    height="10" 
    verticalAlign="middle" 
    render="showNetworkStatusIcon()"/>
</mx:HBox>

You can add almost anything you like in there with this technique; animations, custom text etc. Here’s a quick screen grab of my basic custom status bar with its status light on green after a bit more tweaking of the layout and styling – nothing amazing, but its useful to be able to add your own elements when required (click to enlarge);

Steven Carpenter : 25 Sep 2008 12:26 |  Tags: Air Development Flex Rich Media |  Comments (2) |  Close comments |  Report a problem

David Tucker's 10 common mistakes when building AIR applications

David Tucker recently posted an article on the Adobe Developer Centre citing 10 common mistakes with developing AIR applications and how to avoid them. I thought I’d quickly compare David’s points against my current AIR project, a remote file-system/transfer manager:

1. Making an application platform specific

David primarily refers here to the UI/UX differences between platforms, but I also found it essential because I encountered significant performance differences with some file system operations (icon getters, mostly), which were fixed with the help of the Flex Profiler. At the moment we can’t test it on the Linux Alpha, but hopefully we’ll be able to try that soon.

2. Not including update capability in an application

We included this as soon as the framework became available and it works very well – whenever the application starts it can check for a newer version of itself, and the user has control over whether to update or not.

3. Changing the application ID after an app has been released

Oops – I ran into this early on; changing the application ID means the update framework will break, amongst other things. Changing the name of your application halfway through the project also risks confusion.

4. Not planning for offline support

Our application relies on a live connection to work, but it does use AIR’s network monitoring APIs to check for a valid connection at startup and then continually monitor connection status, and warns the user if connectivity is lost.

5. Not thinking in AIR

I didn’t find this too difficult – some things were relevant and others weren’t. There have often been moments where I’ve discovered a capability and thought “I didn’t know it could do that”; we do use the application storage directory and the user’s temp directory for file transfers though, and the File , FileStream and FileReference classes were the key to making it work.

6. Using custom chrome to create confusing interfaces

We used the standard chrome, but most of the AIR applications I’ve seen that use custom chrome have done so pretty effectively. One of the most powerful aspects of AIR is that you have very fine control over the UI. As a counter to this though, in addition to the native window chrome there are valid use-cases for having access to native system controls, like toolbars, buttons etc. – platform UI differences can make this even more acute, so I’d like the ability to use standard UI elements where appropriate.

7. Not using the seamless install badge

We implemented this early on – having an install badge makes installation a snap for most people and like the update framework it works well – installation of the AIR runtime can be managed automatically and so far the whole thing has worked fine, except when I broke it myself by not updating the right fields in the updater XML file.

8. Not encrypting sensitive data

Not relevant for this application (yet) – we don’t store any information other than the last file-space used, using a standard SharedObject. AIR has an EncryptedLocalStore for this kind of thing though.

9. Not preserving native interaction

As yet we haven’t got a complete set of keyboard interactions in place (e.g. cut, copy and paste) but some are there. The core interaction type is dragging and dropping, and Flex/AIR gives you control over the process by splitting this action into discreet event-driven stages, so providing visual feedback about whether a drag/drop is allowed can be controlled via your own logic. Something I’ve not yet overcome is how to work with internal and external drag handling at the same time – I may be wrong here but so far it looks like the external drag management only knows about drag in/out operations at the application level, not at the component level, so I need to work on how to use the external drag management to allow items to be dragged into components with the same level of control as the internal drag manager.

A more difficult problem is when a standard component doesn’t quite mimic the operation of a native system control – take the Tree for instance, which will close when its DP is refreshed – in situations like these its nearly always possible to closely replicate the native behaviour by extending or over-riding the component default, but there can be some work involved when finding out what to do. At this point I’ll thank Peter Ent and the excellent Flex Examples Blog for their invaluable resources; they saved me a lot of time.

10. Assuming performance doesn’t matter outside of the browser

In this case, the performance issues highlighted when checking across platforms also highlighted the importance of using the Flex Profiler, the net result being a five-fold increase in speed on OSX and smaller but useful increases on Windows, plus reduced memory usage. The original performance on OSX was bad enough to almost make the application unusable, but after identifying and fixing/working around the problems, the application performs similarly in Windows and OSX.

Thanks to David for writing about what to avoid – fortunately most of them we’d already come across and fixed, so that’s good!

Steven Carpenter : 28 Aug 2008 13:04 |  Tags: Adobe Air Development Flex Rich Media |  Comments (1) |  Close comments |  Report a problem

On Dialogue Boxes…

I’m currently writing a few dialogue and interaction menus for my current AIR project, and the thought had occurred to me that having established a reasonable methodology for handling and displaying modal dialogues within my Cairngorm-based app, I was perhaps using them almost by default, without thinking too carefully about whether a modal dialogue was the most appropriate means of interaction. By modal in this context we mean “A state of a dialogue that requires the user to interact with the dialogue before interacting with other parts of the application or with other applications”.

At the same time, Chris and I have been talking about metadata recently (another entry to come, but the premise was that persuading users to input metadata about assets is hard to incentivise). Related to that, Chris sent me this great link to an entry by Jeff Attwood that in turns talks about an entry by Eric Lippert on how dialogue boxes are perceived by users:

* Dialog boxes are modal. But users do not think of them as “modal”, they think of them as “preventing me from getting any work done until I get rid of them.”

• Dialog boxes almost always go away when you click the leftmost or rightmost button.
• Dialog boxes usually say “If you want to tech the tech, you need to tech the tech with the teching tech tech. Tech the tech? Yes / No”
• If you press one of those buttons, something happens. If you press the other one, nothing happens. Very few users want nothing to happen—in the majority of cases, whatever happens is what the user wanted to happen. Only in rare cases does something bad happen.

In short, from a user perspective, dialog boxes are impediments to productivity which provide no information. It’s like giving shocks or food pellets to monkeys when they press buttons—primates very quickly learn what gives them the good stuff and avoids the bad.

I liked that, especially the bit about “Teching the tech” – while it’s quite funny it’s also a pretty accurate reflection of my experience as a user.

This is also related closely to what Chris and I were discussing about metadata; expecting the user to fill in information that has no obvious purpose and slows down the primary task of upload/publish or whatever it is that they are trying to do, is likely to be ignored. If those fields/dialogues are modal or conditional, it’s worth thinking carefully about whether there are alternative ways to complete the operation or gather the infomation. That’s harder to do of course, and there are cases where modal dialogues should be considered appropriate, e.g. where the application is about to do something destructive like deleting or overwriting a file, but there are alternatives, like how IE and Firefox avoid breaking the flow of interaction when blocking certain actions.

Steven Carpenter : 18 Jul 2008 12:45 |  Tags: Air Rich Media Ui User Interaction Ux |  Comments (1) |  Close comments |  Report a problem