I need a custom installer for an AIR application i’m currently developing. That’s because my AIR app needs additional functionality that the AIR runtime doesn’t provide (specifically: detecting USB storage devices, act as a TCP socket server, talk to Last.fm scrobbler plugins). For that purpose i wrote a local RPC socket server gateway in C (one for Mac OS X and one for Windows) which always runs once the user logs in to her OS. The AIR application can then call methods on that local gateway, or receive events.

The problem is that the user needs to install the RPC server before she installs the actual AIR application. The install process should be seamless (one installer installs RPC server, AIR runtime if needed, and the application itself in one go) and the installer should be as small as possible. Currently there is no info available from Adobe on how to write custom installers that automatically download/install the AIR runtime if needed (is there?).

Artemis is another project aiming at extending AIR using a local socket server, but it seems that the project has been shut down because of the reasons stated above.

So i have been pulling out my hair lately on how to solve that problem.

I think i found a feasible solution. I am not sure because i haven’t tested all this, but i wanted to throw it online for discussion. The drawback is that the user needs to install your application with a OS native custom installer.

First you write standard installers for both Mac OS X and Windows, that install the local socket server either as a service/daemon or as an agent so that the server always starts at system launch or user login. Nothing special here yet.

The trick would be to write a simple SWHX application that basically implements the code included with the AIR Installer badge. That helper application can then be included with the installer, which executes it after the local socket server has been installed.

As i said i haven’t tested this yet (will do soonish), but this should work, no?

The question remains why i don’t just use SWHX for the main app and screw AIR alltogether.

FZip has been around for some time now, and people seem to like it. However one feature has been asked for repeatedly: In addition to reading ZIP archive, people want to be able to create new (and modify existing) archives.

So i finally sat down this weekend and added that.

The code is not tested very well (it works for me but may not work for you) and has no ASDocs yet, so i release it as an alpha version, with the hope of massive bug feedback.. :)

Download: fzip_1_0_52_alpha.zip fzip.zip

New methods in class FZip:

• addFile(name:String, date:Date, content:ByteArray)
• addFileAt(index:uint, name:String, date:Date, content:ByteArray)
• removeFileAt(index:uint)
• serialize(stream:IDataOutput)

Sample code:

// Create file contents
var ba:ByteArray = new ByteArray();
ba.writeUTFBytes("Hello World!");
// Create ZIP archive and add file
var zip:FZip = new FZip();
zip.addFile("hello.txt", null, ba);
// Serialize ZIP into a new file
// (we use the Adobe AIR specific class FileStream here,
// but you can as well use ByteArray or anything that
// implements IDataOutput)
var file:File = File.applicationStorageDirectory;
file = file.resolvePath("hello.zip");
var stream:FileStream = new FileStream();
stream.open(file, FileMode.WRITE);
zip.serialize(stream);
stream.close();

Just a quick FYI: FZip and AIRRemoteUpdater upgrades for AIR Beta 2 are now available for download.

FZip now uses ByteArray.uncompress(CompressionAlgorithm.DEFLATE) instead of the now deprecated ByteArray.inflate(). I also tweaked FZip to throw an exception when a parsing error occurs and no event listener is registered for FZipErrorEvent.PARSE_ERROR events.

AIRRemoteUpdater now gets the local descriptor XML via Shell.shell.applicationDescriptor which was added in AIR Beta 2, and uses the upgraded FZip sources.

Enjoy, and please let me know if you run into any problems with this new release.

I just released the first version of AIR Remote Updater, an AS3 class to automate remote software updates in Adobe AIR applications.

It transparently checks version numbers, downloads the .AIR installer file if needed and triggers the AIR-native update process.

It grabs the version number directly from the remote .AIR file without having to download the entire file, eliminating the potential error prone need of having to put a separate descriptor file online along with the .AIR installer file.

Background:

An .AIR installer file is a PKZIP archive containing metadata files along with the packaged application files. The files contained in a .AIR installer file are, in this order:

1. /mimetype
2. /META-INF/AIR/application.xml (contains version info)
3. /META-INF/AIR/hash
4. /META-INF/signatures.xml
5. packaged application files

The file we are interested in, /META-INF/AIR/application.xml (the “application descriptor file” that contains the version number), is always the second file in the archive. AIR Remote Updater uses FZip to stream in the remote .AIR until (and only until) the application descriptor file has loaded. We can then close the stream, uncompress that file and extract the version number.

More info and download here:
http://codeazur.com.br/lab/airremoteupdater/

We just released an update for FZip (the Actionscript 3 class library to load standard ZIP archives and extract/decompress contained files):

• Added support for Adobe Air. The Adobe Air runtime provides a low level inflate method, making it possible to load any ZIP archive and decompress compressed files without the need of injecting Adler32 checksums.
• Added FZipLibrary class for higher level access to files in a ZIP archive. “FZipLibrary processes files (based on file extensions) from an FZip instance and converts them into usable formats. Files can be converted to either a BitmapData or DisplayObject classes. Data embedded in SWF files (like classes) can also be retrieved. Flash’s built-in Loader class is used to convert formats, so the only formats currently supported are ones that Loader supports. As of this writing they are SWF, JPEG, GIF, and PNG.”
• Bug fix: There was a problem with filenames containing special characters. Filename encoding now defaults to UTF-8. In case the filenames are encoded differently in your ZIP, you can specify the encoding in the FZip constructor.

Special thanks to Daniel Wabyick at Adobe for contributing the Adobe Air support!

Enjoy!

http://codeazur.com.br/lab/fzip/

Big propz to Adobe for sending me a set of HUGE (and beautiful!) Flex 2 and AS3 API posters! It didn’t even take a week to arrive here in São Paulo. Sah-weeet! Thanks a bunch, much apprechiated!

In celebration of todays release of the Flash Player 9 for Linux beta, i finally updated the demo of FC64, our C64 emulator for Flash Player 9.

Some time ago i implemented support for sprites and the lo-res bitmap mode, so quite some more games work on FC64 now, including Elite (see screenshot below – i added it to the demo), Fort Apocalypse, Frogger, Donkey Kong, and a whole bunch of others.

Also, Voidrunner renders properly now, including the sprites in its intro.

Check it out:
http://codeazur.com.br/stuff/fc64_final/

The fine folks at gotoandplay.it recently interviewed Darron and me about FC64 – what it’s about, how we did it, and what our plans are. Go check it out!

Darron already blogged it: FC64 won Flashforward Film Festival in the Technical Merit category. Ohhh yeah!

I promised i show you the FC64 trailer that was shown at the ceremony, so here it is:

http://codeazur.com.br/stuff/fc64_final/flashforward/

(takes a while to load, i didn’t bother writing a preloader)

The fun part of it is that the trailer is written in 6502 assembly and executed by FC64. Even more fun: FC64 loads the assembly sourcecode at runtime, compiles and executes it. The scrolling arrows are actually lots of custom 8×8 pixel characters, animated by the C64 graphic chips smooth scrolling feature. I used raster interrupts to switch scrolling off in the middle part where the text appears (we don’t want that to scroll).

Ok, i also cheated a bit. Credits go to Andre Michelle: i ripped the Super Mario mod off his fantastic mod player. SID emulation in FC64 is being experimented with at the moment by Martin Wood and Ralph Hauwert, but we don’t have anything stable to show yet. Be patient :)

Did you ever write an image gallery or a game in Flash? Did it bother you to write rather complicated load queues to load lots of small files such as image thumbnails or game assets like tiles? Are you working with big text files and need a reliable way to compress/uncompress them to save valuable bandwidth?

I’m proud to announce FZip, a cute little Actionscript 3 class i’ve been working on together with Max Herkender that enables you to load standard ZIP archives and extract contained files while the archive is still loading.

FZip is released under OSI approved zlib/libpng license.

Sample usage:

public function YourApp() {
   var request:URLRequest = new URLRequest("your.zip");
   var zip:FZip = new FZip();
   zip.addEventListener(FZipEvent.FILE_LOADED, fileCompleteHandler);
   zip.load(request);
}

private function fileCompleteHandler(evt:FZipEvent):void {
   var file:FZipFile = evt.file;
   trace("File loaded: " + file.filename)
   trace("  " + file.sizeCompressed);
   trace("  " + file.sizeUncompressed);
}

Check it out: FZip at côdeazur brasil lab