Andy McKay's blog

So you have a REST style API on a server that returns JSON that you'd like to access from Adobe Air app (using Javascript). Seems simple right? There's a few tricks in there.

Firstly cross domain. Once you've set up your URLLoader and made your request, you'll get a response back. The only problem is that you can't access the data in it. In the Air Introspector:

event.target

Will show you there's a data element and the data contains your JSON. But no matter what, you can't access it:

event.target.data

Will always return "undefined", not "You can't access this due to cross domain policy" or something useful. So go to your server and add in the following at the URL /crossdomain.xml:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>

Now you've got your JSON. So you could just eval it? Fortunately Adobe blocked that, eval is nasty anyway. How about using jQuery.parseJSON? Nope:

Adobe AIR runtime security violation for JavaScript code in the application security sandbox

So I grabbed json2.js and did:

JSON.parse(event.target.data)

...and then we've got the JSON.

Adobe Air is nice, but I have to say, moving onto the next steps has stalled me because I don't have a set of libraries to play with. Consider these two toy quick apps:

• SVN proxy that monitors all your SVN traffic, allowing you to log exactly what you logged when (useful with multiple SVN servers) and show statistics, including automatic timesheet hint generation.
• IMAP statistics tool that tells when and where your email traffic is coming from and going to.

Both of these would be simple to do in Python and matter of calling out to say HTTPServer, urllib, imaplib for the various protocols to setup proxies or query IMAP servers. However how do I do that. I've got access to javascript and Flex. I'm stuck with: clunky system calls to another language, passing things off to the cloud (not sure thats possible or desire-able) or looking for SWF libraries.

There is a C compatibility layer which gives the prospect of being able to access Python, but still no news.

There were a few red herrings, this article by Bruce Eckel covers calling Python for XML-RPC. Another red herring was this project in PyPI, thankfully I found a download URL that got me around the site that it's hosted on that requires registration and makes no sense. In the end it turns it out its Windows only and comes as an Air APP and a py2exe app. A quick rummage through the source of the .exe reveals it contains links to XMLRPCServer, so I'm guessing its just an implementation of Bruce's ideas. I must admit I was incensed that sort of thing gets into PyPI, but I know there's no policing of that.

Those examples both ship an Air app and a "frozen" python instance. My wife wouldn't be able to run that, it's not user friendly and fraught with problems (one is running the other isn't etc). So currently I'm stuck, I can't see how I can easily extend Adobe Air to do anything beyond interact with what I get. Surely there must be a way forward and I'm missing the big picture.

This one had me confused for quite a while, simply I wanted to do a PUT in Adobe Air to my Plone site. Something that you think would be quite easy but somehow all I got were errors. The problem turned out to be I was doing an upload, when it should have been uploadUnencoded which has a slightly different signature.

function uploadFile(file) {
    // an internal function to get our upload url
    var url = getPref("url");
    // an internal function to get the file name for the PUT
    var urlRequest = new air.URLRequest(url + "/" + fileFromPath(file.url));

    var headers = new Array()
    // an internal function to get the Plone security cookie
    headers.push(new air.URLRequestHeader("Cookie", "__ac=" + getPref("cookie")));
    // an internal function to get the file extension
    headers.push(new air.URLRequestHeader("Content-Type", extensionFromFile(file)));    
    
    urlRequest.requestHeaders = headers; 
    urlRequest.method = air.URLRequestMethod.PUT;
    
    file.addEventListener(air.ProgressEvent.PROGRESS, uploadProgress);
    file.addEventListener(air.Event.COMPLETE, uploadComplete);
    file.addEventListener(air.SecurityErrorEvent.SECURITY_ERROR, uploadError);
    file.addEventListener(air.HTTPStatusEvent.HTTP_STATUS, uploadError);	
    file.addEventListener(air.IOErrorEvent.IO_ERROR, uploadError);
    
    file.uploadUnencoded(urlRequest);
} 

If you are dragging multiple files into your Air and you need to grab them, make sure you do the following:

function dropHandler(event) {
    var files = new Array;
    files = event.dataTransfer.getData("application/x-vnd.adobe.air.file-list")
    ...
}

That mime-type is what you need to get a file list and not just the last file.

This blog post started out as talking about Adobe Air frustrations, but as I ran through the post I actually started fix my issues so within 3 days expect this post to be completely inaccurate.

1. Some simple HTML, CSS and DOM things just seemed to fail. They are the sort of things that you sit and look at and think continually you've done something wrong. As it turns out adding event listeners to DOM nodes is slightly different, but I still couldn't get background images assigned in CSS.
2. Air comes with a nice URLRequest object to talk to external sites and give progress over the result via an asynchronous event. However it can only do GET and POST to external sites. So no PUTs to a Plone site (for example). Ouch. This might kill off my little project to provide a simple file upload tool for Plone.
3. I've just now found a way to handle multiple file drag and drops, in theory.
4. Almost everything is an asynchronous event, which is great for flexibility. Writing everything in JS without any templating and attaching events to everything is starting to get tortuous. Perhaps it's just growing pains and learning a new style, but at this point a big complicated project looks like it might get insanely complex.

On the plus side there were a few nice things in there that rocked. It comes with it's own SQL database either in memory on the filesystem. User preferences for the application can be stored away in its own encrypted space with no configuration, just:

function setPref(key, value) {
  var bytes = new air.ByteArray();
  bytes.writeUTFBytes(value);
  air.EncryptedLocalStore.setItem(key, bytes);
}
...
setPref("plone-cookie", cookie);

...and simple preferences data is being stored. Hopefully first Air app should be done next few days, depending how much real life interferes again.

Alright comparing spats (Simple Page Template Server) to Adobe Air is like comparing ZServer to Plone. Air is a very big complex package that does a huge amount of stuff. By comparison spats does very little, but I'd like to keep interest in it up.

Spats is a program I worked on at Enfold to solve a problem we had (example file browser in piccy). We needed to a client side GUI that would do basic installer or controller like things, running as a powerful user able to delete directories, install services and the like. Spats provides a web control embedded in a window, so it looks like a normal program. Behind the scenes you are writing Page Templates (yay) and running Python.

Air is a big complicated program released by Adobe that provides a HTML, Flash or Flex in a window. Air has full menu support, local database, drag and drop and a whole host of true native program like features. So far I've produced Hello World from it. I've probably under stated what Air does here.

But in the end I still like spats for a few reasons:

• I can write Python to do what I want, not Javascript. You'll pry Python from my cold dead arthritic hands. In Air I have to write Javascript all the way. Ugh.
• Page Templates rock, at this point there isn't anything in Air for doing templating.
• I like writing unit tests for my Python.
• It's open source and can easily come with your Plone install.

What would I chose to write my next client side project in? Adobe Air probably because it has about 8 gazillion features that spats does not. But don't discount spats, its neat and at Enfold made installers and controllers easy to write in familiar technologies that were the same. Plus it makes me think that 3 years ago when I wrote spats, I knew where things were going. For once. Maybe.

• Spats
• Spats projects
• Adobe Air