Monthly Archives: December 2008

Peter Elst recently posted the Sneak Peeks session from the Adobe MAX conference this year. It shows some really good projects, that as the disclaimer strongly advises, may or may not be featured in future releases of the various Creative Suite software:

Serge Jespers presented Nitro, a platform to design, build and distribute Flash widgets ‘on multiple screens’ – i.e. multiple target devices. Intended to create a coherent work flow and end-user deployment environment of ‘widgetized’ Flash content.

There’s a nice demo of pulling a widget directly from a browser to the desktop, detected by the central Nitro widget ‘dock’ which simultaneously synchronised to a mobile device and television. If it’s even half as simple as the demo suggested, then delivering widgets recognised as solid portable, ubiquitous single-purpose applications rather than kitschy or novelty desktop ‘toys’ could very soon be far easier realised.

Meer Meer is a virtual laboratory of browsers, basically a Flex app that runs a variety of coded browsers (of multiple operating systems) on a single server and centralised into a one application. Integrated directly into Dreamweaver, you can render all your local files in each browser with one click of a button. Not only does it offer split-screen views, but an onion skinning mode to overlay browser images without the need of endless screen grabbing (as I currently do) if you play to the pixel. This makes my browser testing posts (1, 2) completely useless, excellent. :)

If none of that interests you, just watch Rufus Deuchler presenting Shai Avidan’s Infinite Images and Infinite Panoramas – I won’t even try explaining – you need to just watch, starts around the 55 minute mark.

Also featured was RTMFP Application-level Multicasting, which broadcasts live video with P2P-style distribution methods; Durango, a Flex/AIR framework to easily create mashup applications almost code free; LiveCycle services in combination with CS4; and running server-side Actionscript seemingly without Flex or Flash – the demo didn’t really work out.

Can’t afford Flex Builder? Build your own!

Well, almost. You can get some easy auto-completion, syntax highlighting and simple error checking of MXML scripts with a nifty bit of XSD integration with Eclipse, using an XML Schema doc from an open source project, imaginatively titled XSD4MXML.

The XSD format is the typical extension for XML Schema, a document defining a set of rules to which an XML document must conform. Eclipse can utilise a Schema document then, in combination with some of the baked in plugins – namely Web Tools and the standard XML editor – to offer these benefits.

The XSD4MXML document outlines what properties any given tag can express – at the most basic level for example, an Application tag can have a layout attribute or a frameRate attribute, an HTTPService tag has a url attribute – but it references every attribute, includes inheritance, for all properties, events, methods etc. This document weighs in at 1.2mb, it’s almost 28,000 lines of code.

Combine that with the error checking the standard XML editor offers and the auto-completion when an XSD format is provided and very quickly you’ve got some useful functionality.

So it goes:

  1. Get the latest version of Web Tools. A fresh Eclipse build should come with it, otherwise follow the instructions here. NB: I’m using Europa, the update process is a little different for the new Ganymede release – also, don’t try and get the latest Web Tools version if you haven’t got Ganymede.
     
  2. Grab the latest version of the XSD4MXML doc.
     
  3. Open the Preferences panel in Eclipse, go to Web and XML > XML Catalog and select ‘User Specified Entries’.
     
  4. Click ‘Add…’ and browse to your local copy of XSD4MXML, the namespace should fill automatically when you’ve found it, click OK.
     
  5. Go to General > Editors > File Associations and add the *.mxml type. Under ‘Associated editors’ add the XML editor.
     
  6. Still in the preferences, go to Content Types, open the Text type and select XML, again add *.mxml.
     
  7. Create a new project and MXML file, add the XML header, an mx:Application tag and namespace:
     
  8. <?xml version=”1.0″ encoding=”UTF-8″?>
    <mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml”>

    </mx:Application>

  9. Within the Application tag, hit Ctrl+Space for the Content Assist menu and you should see a full list of MXML tags and you’re done.
     

You can use the Ctrl+Space shortcut for auto-complete on all tags, properties, events, etc. The XML editor should highlight syntax and do a little error checking itself.

Here’s a handy bit of code. Although every release of the Flash Player provides full backward compatibility in viewing published content, the introduction of ActionScript 3.0 and the new Actionscript Virtual Machine (AVM2) in Flash Player 9 presented some challenges for interoperability at author time, specifically switching between code and SWFs of the different Actionscript versions.

Combining Actionscript 3.0 code with previous language versions can’t be achieved as easily as the old school hacks of plugging together bits of Actionscript 2.0 or 1.0 wherever they fit  - but that’s half the intention, I’m sure.

It’s fully documented at Flash LiveDocs, but now, essentially:

  • A single SWF file cannot combine ActionScript 1.0 or 2.0 code with ActionScript 3.0 code.
  • ActionScript 3.0 code can load a SWF file written in ActionScript 1.0 or 2.0, but it cannot access its variables or functions.
  • SWF files written in ActionScript 1.0 or 2.0 cannot load SWF files written in ActionScript 3.0 (without a couple fiddly exceptions).
     

Generally, avoid it – it’s bad practice anyway. But if you have no other option – or, as I recently encountered (thus this post), your designer inevitably sends you an AS2 SWF for your AS3 project ;) – you can use the LocalConnection class to create a simple interface between the two files that actually also gives you quite an amount of scope for interoperability as and when desired.

If you’ve not used it before, the LocalConnection class facilitates communication between LocalConnection objects instantiated within the same or multiple SWF files. With that ‘access’, you can invoke any amount of methods on connected clients as you can write. The communication exists within a specified domain and all clients must be on the same computer, but it’s not limited only to the Flash player. SWFs can communicate within a browser sandbox, or from browser to standalone SWF viewer, or to a projector etc etc – and anything in between.

For this example, we establish an AS3 SWF as our sending file, calling methods within an AS2 SWF receiving file, which handles the call and invokes the methods.

In the AS3 (sending) file:

var localConnection:LocalConnection = new LocalConnection();
localConnection.addEventListener(StatusEvent.STATUS, onStatus);
localConnection.send(“testConnection”, “connectionHandler”, “Boo.”);

function onStatus(event:StatusEvent):void {
switch (event.level) {
case “status” :
trace (“LocalConnection.send() succeeded”);
break;
case “error” :
trace (“LocalConnection.send() failed”);
break;
}
}

In the AS2 (receiving) file:

var localConnection:LocalConnection = new LocalConnection();
localConnection.connect(“testConnection”);

localConnection.connectionHandler = function(string:String):Void {
trace (“Message from AS3 SWF: ” + string);
}

Easy peasy. You can send any amount of arguments and call any method on the listening SWF – so long as there’s a handler to deal with it.

I’ve recently started playing with Adobe Alchemy, a beta project for compiling C/C++ libraries into Actionscript.

I was having problems compiling the sample app – the GCC couldn’t find the Actionscript libraries and I was seeing a duplication in the path:

cc1 error: /usr/lib/alchemy/usr/lib/alchemy/avm2-libc/avm2/AVM2Env.h

I posted it up on the Alchemy forums and it would seem I wasn’t the only one experiencing this problem.

Turns out it’s an unnecessary Perl hack, in the hacks.pl script in the /alchemy/achacks/ directory.

Commenting out the following lines of the pfix function:

$p =~ s/(^|^-[-\w]+=?)(\/usr\/include\/)/$1${home}\/avm2-libc\/include\//;
$p =~ s/(^|^-[-\w]+=?)(\/usr\/)/$1${home}$2/;

and it stops the incorrect ‘fix’ of the file path.

Try again, and the SWC compiles. Who says forums don’t work? There’s a lot of excitement about this project, glad to see them so active.

Adobe recently beta released a new project codenamed Alchemy.

Alchemy is basically a research project that allows you to compile C and C++ code to run on the Actionscript Virtual Machine (AVM2), essentially, enabling you to utilise compiled C and C++ libraries, ‘as Actionscript’, in all your web applications:

Alchemy is primarily intended to be used with C/C++ libraries that have few operating system dependencies. Ideally suited for computation-intensive use cases, such as audio/video transcoding, data manipulation, XML parsing, cryptographic functions or physics simulation.

It used to be called FlaCC, and was previewed at Adobe MAX last year. Although it’s not intended to produce complete applications, it can run up to ten times faster than Actionscript – although still slower than native C/C++ code.

The Alchemy site at Adobe Labs offers a promising ‘Getting Started’ guide with tutorials for Windows, Macintosh and Linux now that each platform – Flash Player 10, Adobe Air, the Flex SDK and the Alchemy toolkit – are all cross-platform and open source.

I decided to give it a go, working with my preferred development environment running on Ubuntu 8. However, in following the seemingly quite simple steps to compile my first library, I ran across a number holes in the guide and problems in the toolkit.

Alongside my efforts, Tim Crook tried the same on Machintosh.

Unable to get any success from Adobe’s instructions, we took following steps to get Alchemy up and (almost) running:

Set up your environment – make sure you have up-to-date versions of Java, Perl and GCC. Then download the latest Flex SDK and add the bin directory to your system path. If you’ve not done this before, you’ve basically two methods. Firstly get the path to the SDK, mine is at:

/usr/lib/flex_sdk_3/

Then, to add the bin directory for the current session, execute:

export PATH=$PATH:/usr/lib/flex_sdk_3/bin

Obviously change the path accordingly if yours isn’t in the same place. But you’ll have to do this with every new session you create, because the append is only temporary.

Instead, to add the path automatically you’ll need to modify your login script or bash profile – depending on your system. On Ubuntu 8, I add the above line to the end of of my bash startup file, which I find at:

/etc/bash.bashrc

There are different ways to add directories for various user types – whether for single or multiple users, for the root user etc – there’s a troubleshoot here. You can check whether either method was successful by calling:

echo $PATH

You should see the path appended – there’ll most likely be other directories listed too. Test the path and SDK by running:

adt -version

You should see output similar to:

adt version “1.5.0.7220″

Which is just your Air Developer Tool version number. You’ll need to restart the session if you’ve modified your bash script rather than modifying the path temporarily.

Then download and extract the Alchemy toolkit, again, mine is at:

/usr/lib/alchemy/

Run the configuration file by navigating to the folder using the cd command and execute:

./config

As you’ll be prompted, there’s a set-up that needs to be run every time you login. To achieve this automatically, open up the bash profile again and before the path modification add:

source /usr/lib/alchemy/alchemy-setup

If you’ve followed the ‘Getting Started’ guide – it’s all the same up until now, but here’s where we begin to differ. Restart your terminal session. As far as we found, you’ve no need to modify your path any further. To check whether the set-up did run successfully, turn Alchemy on and check which GCC you are using:

alc-on
which gcc

You should see something along the lines of:

/usr/lib/alchemy/achacks/gcc

The Adobe instructions say you’re now ready to compile one of the sample libraries. Navigate to:

cd /usr/lib/alchemy/samples/stringecho

Then run:

gcc stringecho.c -03 -Wall -swc -o stringecho.swc

And you should see some ouput. But I didn’t, neither did Tim – ours both die silently. :(

After a lot of head scratching a Googling we found a forum complaint that there are some bad symlinks in the current release of the toolkit – and we found them too. There’s two symlinks in /alchemy/bin:

llvm-g++ -> /usr/lib/alchemy/bin/llvm-gcc4-ubuntu-install/bin/llvm-g++
llvm-gcc -> /usr/lib/alchemy/bin/llvm-gcc4-ubuntu-install/bin/llvm-gcc

These go nowhere, so created new links to the correct compilers as follows:

ln -s /usr/lib/alchemy/bin/llvm-gcc4-ubuntu-install/bin/g++ llvm-g++
ln -s /usr/lib/alchemy/bin/llvm-gcc4-ubuntu-install/bin/gcc llvm-gcc

Then try again.

For Tim, success – for me, not so much.

There’s obviously something in the Linux toolkit that’s not in the Macintosh version. Amongst the output I do get though, is the following line:

cc1 error: /usr/lib/alchemy/usr/lib/alchemy/avm2-libc/avm2/AVM2Env.h

So it’s another path issue somewhere that’s causing the duplication – I’m just yet to locate it, or find a way to resolve it. I’m working on it.

This whole project could be incredible, Adobe are strongly encouraging developers to share ported libraries and support the open source ethos.

If anybody has run into the same problems as I, or even fixed them – get in touch!

Update (03.12.08): I’ve since found the fix.

Is there anybody alive out there?