Fun with HTML, JavaScript and Adobe Air
I've been tracking Adobe Air for a while now, since it was called Apollo in fact, and earlier this year we ran a couple of tests for some of our prototypes. Last Thursday I caught one of Adobe's CS3 roadshows in Sheffield and got an overview of the latest release of Air which brought it back to mind.
For the last few weeks I've been hacking together some sweet AJAX for the interface for our upcoming alpha trial - after running into the same old IE doing it's own sweet thing nightmare I realized that wrapping the whole app up in Air and deploying to the desktop might solve all manor of headaches.
So, easy thought I, simply run my app through the air 'compiler' and ship to all OS's and no longer worry about rogue browser behavior. The current iteration of our app doesn't need any OS interaction, taking as it does only with a Web server, so what could be easier.
Well, its not quite as easy as that. The new version of the Air beta is quite different from the one I was playing with a while back. See, the post load alterations to the 'web page' which is the bread and butter of AJAX have become a security concern, especially when you throw HttpRequest coupled with JSON into the fray. Imagine a suspect JSON payload being eval()ed and doing all manner of nasties - now imagine that running under a framework which can also read and write to you file system - ouch!
So, Adobe have implemented a security model which tries to rectify the issue by running two sandboxes simultaneously:
i) The Classic Sandbox which will run all you good old Web apps but not allow access to the Air API which gives access to the OS etc
ii) The Application Sandbox which gives access to the Air API set but will not stand for any of that AJAX fiddling.
The good news is that you can still have your nice AJAXy interface built the way you like to do it and make use of the API through the use of the 'Sandbox Bridge'.
What all this means is that you can't just take you existing web app and run it through the Air 'compiler' an end up with a desk top app. If you do, your JavaScript won't run and you may see an error such as "Error: Parsing Disallowed". This is because the default mode is to assume the more paranoid (safer) Application Sandbox.
I myself spent hours crawling the web trying to work out why my HTML/CSS/JabaScript app worked perfectly in the browser (IE max-height humour ) but failed to work when compiled to a .air file. All the docs I had were out of date. At first I thought maybe it was something in the JQuery framework I was using - but after building simpler and simpler test models I eventually realized that even an alert box called as a function with 101 JavaScript doesn't work!
Part of the issue was that I abandoned the command line SDK because I was having issues with the path settings - again the result of out of date documentation - and instead added the DreamWeaver Air extension. Now - I'm old school, I started my scripting long before DreamWeaver, GoLive et al came along and so it took me a while to find the 'site' arrangement. Any how, in the end I got my app together and ran it though the Air create extension, which worked smooth enough - but my app didn't work.
It was only after getting a little bash help (I swear I used to know this stuff in the early 90's) and running my tests through the command line SDK that I found the error message "Error: Parsing Disallowed" - which gave me something else to ask The Google. Which lead me eventually to the security model documents and some worked examples!
Now all this sounds a little bit like hard work especially if you have a nice Web app and all you want to do is port it to the desktop to start getting a feel for AIR!
Well, the fact is that it is actually very easy - its just new so there are precious few quick start idiots guides out there.
So if you have been harassing search engines with queries like "Why doesn't my JavaScript work in Air","Air JAVASCRIPT problems" etc, I hope the example below helps you.
So, how is it done?
Well - You create a new HTML file which is the root for your Air app (the file your air XML file calls root) and in this you call your app start page as an IFRAME. Simple as that - well for the base case anyway. This new Root HTML file is the place where you set up the Sandbox bridge and Application Sandbox etc too - but hey you can work up to that.
So by way of a helpful example:
Your App start page:
Lets call this HelloWorld.html
Your Air app root
Lets call this HelloWorldRoot.html
And finally your Application Descriptor File
Lets call this HelloWorld.XML
Download a text file here with all this code in for cutting and pasting.
And thats it - stick these in the same directory at run the Air command line at the XML file - job done!
Now you know how to get your Web app to work on the desk top you can start looking at interacting with the OS through the Air APIs and setting up you Sandbox bridge.
Read about the security model and why here.
See worked examples to help with your next steps here.
I've been tracking Adobe Air for a while now, since it was called Apollo in fact, and earlier this year we ran a couple of tests for some of our prototypes. Last Thursday I caught one of Adobe's CS3 roadshows in Sheffield and got an overview of the latest release of Air which brought it back to mind.
For the last few weeks I've been hacking together some sweet AJAX for the interface for our upcoming alpha trial - after running into the same old IE doing it's own sweet thing nightmare I realized that wrapping the whole app up in Air and deploying to the desktop might solve all manor of headaches.
So, easy thought I, simply run my app through the air 'compiler' and ship to all OS's and no longer worry about rogue browser behavior. The current iteration of our app doesn't need any OS interaction, taking as it does only with a Web server, so what could be easier.
Well, its not quite as easy as that. The new version of the Air beta is quite different from the one I was playing with a while back. See, the post load alterations to the 'web page' which is the bread and butter of AJAX have become a security concern, especially when you throw HttpRequest coupled with JSON into the fray. Imagine a suspect JSON payload being eval()ed and doing all manner of nasties - now imagine that running under a framework which can also read and write to you file system - ouch!
So, Adobe have implemented a security model which tries to rectify the issue by running two sandboxes simultaneously:
i) The Classic Sandbox which will run all you good old Web apps but not allow access to the Air API which gives access to the OS etc
ii) The Application Sandbox which gives access to the Air API set but will not stand for any of that AJAX fiddling.
The good news is that you can still have your nice AJAXy interface built the way you like to do it and make use of the API through the use of the 'Sandbox Bridge'.
What all this means is that you can't just take you existing web app and run it through the Air 'compiler' an end up with a desk top app. If you do, your JavaScript won't run and you may see an error such as "Error: Parsing Disallowed". This is because the default mode is to assume the more paranoid (safer) Application Sandbox.
I myself spent hours crawling the web trying to work out why my HTML/CSS/JabaScript app worked perfectly in the browser (IE max-height humour ) but failed to work when compiled to a .air file. All the docs I had were out of date. At first I thought maybe it was something in the JQuery framework I was using - but after building simpler and simpler test models I eventually realized that even an alert box called as a function with 101 JavaScript doesn't work!
Part of the issue was that I abandoned the command line SDK because I was having issues with the path settings - again the result of out of date documentation - and instead added the DreamWeaver Air extension. Now - I'm old school, I started my scripting long before DreamWeaver, GoLive et al came along and so it took me a while to find the 'site' arrangement. Any how, in the end I got my app together and ran it though the Air create extension, which worked smooth enough - but my app didn't work.
It was only after getting a little bash help (I swear I used to know this stuff in the early 90's) and running my tests through the command line SDK that I found the error message "Error: Parsing Disallowed" - which gave me something else to ask The Google. Which lead me eventually to the security model documents and some worked examples!
Now all this sounds a little bit like hard work especially if you have a nice Web app and all you want to do is port it to the desktop to start getting a feel for AIR!
Well, the fact is that it is actually very easy - its just new so there are precious few quick start idiots guides out there.
So if you have been harassing search engines with queries like "Why doesn't my JavaScript work in Air","Air JAVASCRIPT problems" etc, I hope the example below helps you.
So, how is it done?
Well - You create a new HTML file which is the root for your Air app (the file your air XML file calls root) and in this you call your app start page as an IFRAME. Simple as that - well for the base case anyway. This new Root HTML file is the place where you set up the Sandbox bridge and Application Sandbox etc too - but hey you can work up to that.
So by way of a helpful example:
Your App start page:
Lets call this HelloWorld.html
Your Air app root
Lets call this HelloWorldRoot.html
And finally your Application Descriptor File
Lets call this HelloWorld.XML
Download a text file here with all this code in for cutting and pasting.
And thats it - stick these in the same directory at run the Air command line at the XML file - job done!
Now you know how to get your Web app to work on the desk top you can start looking at interacting with the OS through the Air APIs and setting up you Sandbox bridge.
Read about the security model and why here.
See worked examples to help with your next steps here.
Comments