Adobe iPhone Packager 2.0

The whole Flash community has been jumping for joy ever since Apple revised their controversial App Store License Agreement in early September this year. Apps created with Adobe’s “iPhone Packager” are not longer banned from the App Store, and Adobe started working on the product again.

Section 3.3.1 now merely forbids the use of private APIs.. tooling and language restrictions have been lifted, especially the part that prohibits “linking to documented APIs through an intermediary translation or compatibility layer or tool” – the iPhone Packager uses LLVM to cross-compile ActionScript to iPhone-native byte code, which is now allowed.

I didn’t hear many people commenting on Section 3.3.2 though, which i find weird. I think the real good news is this very section. Code interpreters are now explicitly allowed, given that “all scripts, code and interpreters are packaged in the Application and not downloaded”.

This means that Adobe could potentially shelve the existing, LLVM based iPhone Packager, and instead deploy a regular AIR runtime with a separate SWF. This would certainly make the publishing process a lot faster, as there is no cross-compilation step anymore – a standard SWF is published, which is then just packaged together with an iOS AIR runtime. I am uncertain which approach would perform better though: interpreted and JIT compiled via virtual machine, or LLVM translated native code.

Also feasible: a Flash Player engine that developers can plug in to their Cocoa apps, to mix UIKit and SWF. Best of both worlds.

Where do you think the iPhone Packager is heading?

Flash IDE Inspired Flex 4 Timeline Component

Here’s a little demo of a Flex 4 component i wrote that displays a Flash IDE-like timeline for any SWF you load into it. The timeline data is reconstructed by as3swf (i discuss how that works in a previous blog post, SWF Timeline Reconstruction with as3swf). The timeline is not interactive in this demo, and only the root timeline is shown.

Continue reading

My Silly Gist Collection

I’ve been quite busy lately on both client and personal projects (can’t talk about the former, other than it being a big ass Flex 4 enterprise application i’ve been working on for the fine folks at Powerflasher; and it’s too early to talk about the latter.. stay tuned).

In the last few weeks i silently released random little experiments on Gist – mostly fallout from personal projects of mine. Nothing super impressive, all pretty rough, but i thought some of you might be interested.

Continue reading

AUPEO!

In case you were wondering what i have been working on in the last few months (and what will keep me busy in the coming months).. AUPEO! is a brand new platform that combines music and community – online, offline, on the road, on the web, on your desktop, on your devices.

I can’t tell too much just yet but i think it’s safe to say that it’s going to seriously rock the tardis. It will feature an open REST API for your integration pleasures, it will come with a super sweet AIR application that i am sure you will love (not only because it will be 100% open sourced), and the site (handcrafted in Rails and designed by one of the coolest design houses in the universe) is definately going to please your eyes and ears.

Be one of the first to play with it, sign up for the closed beta today!

AUPEO!

Custom Installer For Adobe AIR Applications

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 Alpha Release: Create And Modify ZIP Archives

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();

FZip, AIRRemoteUpdater Upgraded for AIR Beta 2

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.

Automating remote software updates in Adobe AIR applications

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/

FZip Update

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/

Adobe Apollo and Last.fm: Proof of concept

I have been toying around with the idea to write an Adobe Apollo application that’s able to monitor your favorite media player (such as Winamp, Windows Media Player, iTunes, Rhythmbox, etc) for play back status and song information.

Last.fm provides an application along with plugins for pretty much all existing media players on all major platforms (Windows, MacOS, Linux, etc) that does exactly that. During installation of the Last.fm client, the user is prompted to install the required plugins for the media players she uses. When a media player executes and plays a song, the plugin establishes a TCP socket connection with the client application and sends status and song infos.

The problem: The Apollo runtime (alpha) that is currently available on Adobe Labs doesn’t provide any documented way of (a) talking to shared libraries, (b) launching executables or (c) serving as a socket server, and Adobe indicated that Apollo likely is not going to support those features in it’s 1.0 release version.

There is hope though. Afaik, the last word on launching executables at runtime from an Apollo app isn’t spoken yet, and there exist some undocumented hacks that enable Apollo apps to do just that. If Adobe should decide against letting apps launch executables, then the only way of solving it is to provide second installers that install a socket server of some sort to do the dirty work.

However, i sat down last night and wrote a proof of concept Flash application that can live in Apollo, which talks to a custom daemon via sockets. The daemon in this proof of concept runs as a Windows Service. I took the Last.fm iTunes plugin and modified a bit so that it also connects to that daemon. The daemon then simply echoes the messages it receives from the Last.fm plugin to the socket listener in Flash. VoilĂ .

Here’s a screenshot of the app in action (iTunes on top, Flash below):

iTunes talking to Flash

[Update] I also modified the Last.fm Windows Media Player plugin to work with my daemon. All plugins can be used simultaneously. See this screenshot (Windows Media Player on top, Flash below):

Windows Media Player talking to Flash

Note that this is only a proof of concept, and sources aren’t ready for release yet. I would very much like to make this an open source project (The Last.fm plugins are released under GPL), so if there are any interested developers out there who like to help, please contact me or leave a comment. Thanks!