AIR again

In a previous post of mine I had briefly jotted down what I liked about AIR and how it all came together for Workstreamr. This time around I would like to write about some of the problems I had to face when coding in HTML , Javascript, CSS (AIR application) and how I managed to find a way about those problems. I would especially like to thank Snitter for developing a great product in HTML/Javascript/CSS so that learners like me could evaluate and understand the product.

I initial idea was the same as any other Open API system. Access data using certain credentials via http, parse and interpret the data, format the data and then display the data. So my primary concern was to separate the modal/controller/view layers that come into picture. The javascript files were written using the prototype library and the effects (even though little) were done using scriptaculous. After defining the stuff that I wanted, I went on to make managers (like sound manager) and providers (like htmlcreator which gave me the html designed code when I gave a json). The main application was the launch pad for all the other Javascript classes.

The application required a modal window and an accordion. The Modal Window was created with Controls.Modal in mind but I simplified it a bit. The Accordion was inspired by accordion.js found in scriptaculous. The Modal window had problems loading the first time as AIR had issues attaching/running events after the window is opened. So what ever code you are going to write you better initialize it first. eg - The eval execution is limited in the Sandbox Application and Prototype uses evalScripts for all insert statements.

The posts that I displayed had links in them with hrefs. Now if I had left them as it were, as soon as a user clicked them, they would open in the same window as the application. To open links in you default browser window you will have to use

air.navigateToURL(new air.URLRequest('http://google.com'));

Sanctifying this was necessary as we did not want them to load in the same window. Adding an onclick event to the got post/message wont do any good here as the evalScripts will not be executed after the prototype insert statement. Snitter does a work around this by attaching an event listener for the whole area where the message displays. Checks whether its a link type, if yes issues this command. The problem that I faced still was even though I returned false from that method, the link open in the same window. The change that I did was that I took the href attribute value and put it in the alt attribute and cleaned up the href attribute value.

As the eval function accessibility is limited the passing of a string to settimeout/setinterval is also not allowed. The way around is to actually pass a function/function name to this

polling = setInterval(function(){alert('getting');},timeout);

There were also CSS based minor issues. As you see in most of the twitter clients, when the user hovers over the avatar, he sees a envelope which he uses to send a direct message. I thought of doing it the JS way but then some clever CSS caught my eye. If you consider the image to be in a div and the sub envelope image to be in a child div then the CSS would be like

.child {visibility:hidden;}
.parent:hover .child{ visibility:visible;}

which I think is brilliant.

I also juggled around naming divs in such a fashion that it becomes easy to get details in a certain fashion. Say I needed a user id when I clicked a checkbox. This generated checkbox could be given an id something like 'user_22_message_3242', so that parsing/splitting it and finding out the user id was a piece of cake. I cannot think of a better way than this. :)

Icon tray setting up was also a great feature that AIR offers. But be careful when you aim for the MAC as well. A specific check is required to see if there is dockicon support else when you minimize the window, the whole application may disappear.

nativeWindow.minimize();
if(!air.NativeApplication.nativeApplication.supportsDockIcon) { // Fix for Mac
nativeWindow.visible = false;
}

Always do an ordertofront after you restore the main window. This will make the application better and sane.

The other thing which gave me some problems was the notification system (Growl). Now AIR does not support this but we make the application have this by using certain actionscripts. I looked through the actionscripts that Twhirl and Snitter uses. You could write your own script if you want the customization. We will have to tell AIR to add this in the path as well by doing a script include

<script type="application/x-shockwave-flash" src="notification.swf">
</script>

I wanted a clean interface without those Adobe AIR based controls so I went for the transparent -true, chrome- none and visible -true configuration in the main file. This also requires that you have the close control (as in a image which calls the close routine).

The theme manager was another thing that I loved doing. As of now the theme manager loads a predefined xml file with all the theme details in them and on changing the selected item in the list displayed, it changes the CSS file which dynamically loads the theme. The images are also maintained in this theme folder so that a uniformity is obtained. The sound implementation was pretty easy. It only plays mp3 files(as I understand) but thats ok.

The development time required for an AIR application with HTML, Javascript and CSS is quite rapid. This client was developed within 1.5 months (I had other work as well). It has a great platform support (even linux now!!) and I expect a lot of verified AIR Applications to come up pretty rapidly.