iFeedme Blog

Inspired by (and based on) Christian Cantrells httpeek AIR application, I’ve knocked up a quick proof of concept http server in AIR 2.0 Beta.
It’s basic (understands GET and HEAD requests only), largely untested and almost certainly has bugs, but in a “Works on my machine” basis it does seem to work.
What you should definitely NOT do is to expose it to the outside world – I can’t say it’s not exploitable to read or execute files on your machine.

So it’s really just for interest only.

I’m struggling to find any compelling reason why you would actually want to use such a thing, to be honest.
Firstly, it only has one thread to work with, so performance is always going to be an issue when serving more than a very few clients.
If you wanted to have something a bit more sprightly or fully featured then it might be a better idea to start up a dedicated server program via the new nativeProcess API.

I did consider that it could be of (limited) use in either a classroom or home network scenario.
In a classroom it could perhaps serve course materials to accompany a presentation on a projecter, but realistically most lecturers are going to struggle to pick a network interface and deal with firewall issues in order to set it up.
Perhaps in a home network scenario one could use it to serve up a remote control interface to something like an mp3 player.
However, you would have to implement something like flash remoting or connect back to the server on another socket to establish control.

Bright ideas are welcome, as are bug reports (but be aware that unless I find a good reason to do so I’m unlikely to take this any further…)

Source code

Usage : Pick a network IP address (Normally 127.0.0.1 for local testing, if you pick one exposed to the network then be aware that it may well be firewalled – depending on your machines setup)
Pick a port number to serve on (if it’s already in use then you’ll get an error, note that ports below 1024 normally require admin rights to serve on unix machines).
Choose a directory from which to serve files and click the “Serve” button – then point your browser to http://[yourIp]:[yourPortNo]/[yourFile].
Note that this does not serve directory listings – you’ll need to point it to an actual file e.g. “index.html” or whatever you’re using.

If you don’t know the term, a tyre kicker is the kind of self styled “expert” who comes round to see the car you’ve got for sale and bores you senseless by talking rubbish (and will invariably kick it’s tyres at some point when doing so). They are in almost all cases almost entirely ignorant and very opinionated of the subject they are talking about, and are only wasting your time.

Which is a little bit like how I feel about writing anything about flex4/Gumbo, but I’ll try to get over that and make an effort to not be too ignorant, opinionated or boring …

Well, I’ve got very excited about the new text engine in flash 10, and even more so about what might transpire in flex 4. I’ve always struggled with the text in flash, and trying to manage clients expectations about what it can do and how hard it will be (Sadly, in most cases so far, not much, and very).

So if you want the get the skinny on what the lovely people at adobe are proposing, check out

Gumbo TextArea – (Mini) Functional and Design Specification ,

Gumbo Text Primitives (TextBox, TextGraphic, and TextView) – Functional and Design Specification

and also flash.text , flash.text.engine , and text.model in the Gumbo asDocs.

From what I can tell, it’s looking pretty comprehensive and well thought out.

So how do you get to play with all this new typographical goodness I hear you ask?

Well, you’ll need to download and install (in my case in flexbuilder 3) a build of the Gumbo SDK, I followed the (as usual) excellent instructions at flexexamples.com

Now, once done I found a flexbuilder project using last fridays SDK build to be, well, a bit flakey!

Code completion, formatting and colouration was all over the place, design view doesn’t work and imports need to be typed manually, plus a few other oddities and occasional blow ups.

This is entirely as I expected, this code is not even alpha and actually I’m quite pleased it works as well as it does. I’m very happy that we are allowed to play with it as it stands and get a feel for what’s coming rather than having to wait for a milestone (alpha) build, so from my point of view it’s all good.

In an attempt at “tyre kicking” I’ve knocked up an awfully simple “not particularly rich at all” text editor, a link to which you’ll find at the end of this post.

What had particularly caught my eye was the ability to populate a TextView from text or xml, and a built in method ( export() ) that should export an xml object that can be saved / used as the content for another TextView. In other words, we have the basic building block for a proper rich text editor in flex, and a markup language for the same.

In practice, when I tried this, it blew up! Never mind, I’m pretty sure that adobe engineers just have not got far with it yet (either that or I did something wildly wrong in my ignorance). The raw export gives an xml object with a “TextFlow” root node and “flow” namespace, but poking that back into the TextView source just errors out. I did find, however, that removing the root node and the namespace gave xml markup that largely worked, so I’ve added a “filter” function in my text editor that does just that, for the moment.
Unchecking the checkbox for that shows you the unfiltered export() output.

I also noticed that:

I could get a div tag to work in mxml markup, but not by setting the content as a string.

On occasion I’d set content that made the TextView unresponsive to further changes.

Spaces can get removed. This may be a configurable setting that I’ve not discovered as yet.

So far, I’ve not really got into exactly what markup you can use, but my “editor” should at least provide a way to experiment. I’m considering adding a “gallery” function for people to save and submit their own markup examples, if you’d like to see that then drop me a comment…

It should allow you to enter markup code in the top textarea, set it as content in the middle (Gumbo) textarea, and export the Gumbo textAreas contents to the bottom textArea for inspection/copying.

There are also some very simple controls for editing properties of selected text in the gumbo textArea.

I’ve included the source (didn’t seem to work in flexbuilder for this project, so click the source link instead) so you can take my rather meagre beginnings as a start for your own experiments (or to laugh at, as you see fit).

I’ve not taken it very far at all, I think it’s probably a little bit early for that given that gumbo is still in the early days, so please forgive me for that.
I hope it is of some interest though, and encourages your own investigations, experimentation and improvements (which I look forward to seeing). If you have any, then please do drop a comment with a link so that people can easily find it if they end up reading this post.

view example
(yes, it requires flash player 10)

source

Firstly a disclaimer : I don’t really know what I’m talking about here, this entry is a summary of a series of (hopefully educated) guesswork.

That said, todays task was to make an installer for an AIR application that could reside on CD/DVD, detect if AIR is already installed on the users system (And install it if not), and then install the application. All in a familiar (to users of our products, in any case) style of installer and without any reliance on an internet connection.

You should note that I am a big fan of the AIR “badge” installers, but reliance on the presence of flash player v9.1.1.15 + and an internet connection to download the AIR installer makes it rather unsuitable for our purposes.

Why would I want to do such a thing? Well, our marketing department seem to think (rightly or wrongly) that’s it’s a requirement.

Anyway, on with the tech stuff.

We use NSIS installers for our current product line. Not my decision, I was gifted it by a previous (and now departed) programmer.

Personally I have little experience of it, I normally manage to use an existing install script and change a few variable names, possibly hack in something from their support forums or examples and just about get the job done.

All in a “hack at it till it looks like it works” style (which I will continue here).

No doubt anyone who actually knows what they’re doing with NSIS will be laughing at me here, but hopefully they will kindly correct any glaring errors I may make.

I believe the general approach I take here will hold true for any other windows installer you may use, however.

The first task is really to determine whether AIR is installed or not, which I’ve chosen to do by reading a registry string that the AIR runtime install seems to write when it is installed (I don’t have any information or documentation on this, by the way, I just compared registry settings pre/post install). It would appear to tell the system where the application “Adobe AIR Application Installer.exe” is installed, and lives in HKEY_CLASSES_ROOT/AIR.InstallerPackage/shell/open/command.

In the nsis case, the the code to detect/install the AIR runtime looks something like this (probably! It’s all a bit “GoTo” for me, but it seems to work ok)

ReadRegStr $R0 “HKCR” “AIR.InstallerPackage\shell\open\command” “”

StrCmp $R0 “” airNotInstalled copyApplication

airNotInstalled:

MessageBox MB_YESNO “You first need to install Adobe AIR Runtime to run this product. Would you like to install it?” IDYES yes IDNO done

yes:

DetailPrint “installing AIR RUNTIME”

Push $CMDLINE

Call GetParent

Pop $R0

ExecWait “$R0\adobe_air_installer\AdobeAIRInstaller.exe”

;ReadRegStr $R0 “HKCR” “AIR.InstallerPackage\shell\open\command” “”

;DetailPrint “AIR RUNTIME is installed at: $R0″

;MessageBox MB_OK “AIR is installed at $R0″

Now, if you merely wanted to do an offline CD based installer, then I think that would be more or less all you needed.

If you pass the path to your .air archive as an argument to “Adobe AIR Application Installer.exe” then it will handle the install for you in the usual AIR runtime manner with the same dialogues you’ll no doubt be used to by now. Handy!

However, in my case I need to install a “protected” executable rather than the small “stub” exe that AIR sticks in your programs folder, so I need to get my installer to copy the files for me. (Please don’t start me on this “copy protection” thing, I tend to rant profusely about it, but my hands are tied once again). The “protected” executable is the original with a whole load of super secret gubbins wrapped into it that ties the program to the disk that we supply the product on. Apparently. Somehow. We have 3rd party software that will do that to an existing .exe, once done that .exe will not run without the original DVD being present in the drive of the users pc.

It turns out that if you install an application via AIR in the usual way, then head to it’s folder in “program files” and grab the files straight from there then you can install them on another system and they will work (if the AIR runtime is present).

(I wrapped the air application .exe file with the “copy protection” at this time, before making an installer)

I initially didn’t expect this to work, reckoning that there would be some sort of check of integrity of that file by the runtime, but as far as I can tell (in my limited testing) that’s not the case.

As far as I can tell, you will need the files/folders “your_application_name.exe”, “META-INF”, “mimetype”, “your_application_name.swf” and any of the assets that you may have included when you packaged up your AIR app.

In my case, the lines

———————–

copyApplication:

File /r data

File /r img

File /r META-INF

File /r movies

File /r pics

File /r web

File mimetype

File myApp.exe

File myApp.swf

———————–

will grab those files/folders (the “/r” makes the copy recursive) from the directory in which I make the installer and compresses/packages them into the installer (which will unpack them when run).

(NSIS actually does very good lzma compression, which means that you may get a smaller installer than your original .air archive (if you’re lucky, which I was )).

This all seems to work very well, and once installed the application appears to run as it normally would.

Never the less, I would be careful. For instance, I made a tiny test application that just used AIR’s update mechanism to update itself. In the end, it updated itself to the location from which I’d copied the files for the installer on my machine, rather than where my custom installer had placed them on another. Obviously the original AIR install location is stored somewhere, but I have no idea where. So for updates you’d have to build your own system, and I can only guess where there may be other gotchas that I’ve not discovered as yet.

It’s worth noting that this method avoids the user seeing any warnings about code signing (which they would if they were using the AIR installer, if the app is not signed).

Since drafting this article I’ve very briefly tried the “shu-player” installer, which appears to wrap both your AIR application and the runtime into one .exefile which can be run from DVD without any tedious “install the runtime” dialogues for the user.

My first impressions were good, it’s easy to use and worked well in my quick first use test.

It appears to uncompress the runtime and your application into the users temp folder, then attempt to remove them when the app is shut down.

I do have some concerns with this approach : though I’ve not tested it yet I can see some issues with storing persistent settings due to the varying location of each instance of the application on the users system. In use, it also appeared to not clear the temp folders it created, though it did delete their contents.

I’m also not convinced that it would work all that well with our “copy protection” format, though I have yet to try, test and analyse it.