Archive for category actionscript

Open source AS3 frameworks to test run

With so many handy AS3 frameworks out there I often get excited about each new offering, but in the end I’m overwhelmed with the options and so rarely give any a test run.
 
Frameworks I use

Here’s a list of frameworks that I do rely on heavily and couldn’t live without (This is mostly for Flash website development).

PureMVC Brilliant MVC framework for AS3 (and a plethora of other platforms). This was my first foray into MVC and was hard going to get my head around, but now, I don’t look back!

swfAddress Integral for current Flash website development. Adds deep linking and browser history to your websites. Another good thing about swfAddress is that it forces you to use elements of good practice when developing your navigation code, it’s asymmetrical and requires a central navigation function.

Tweener One of the many Tween engines out there. I like Tweener because it’s simple to use and has shortcuts for really handy things (like colour effects and sound control). Most tween engines these days all do pretty much the same thing - either way they are vital tools for any actionscript animation.

And of course I have my own Tool and UI packages that I leverage on projects, being able to streamline and make more robust with each new job.
 
Frameworks to test run

But now to the point of this post. My new resolution is to tackle the mountain of frameworks out there, one at a time. I’ll do a quick “hello world” demo with each to get some hands on experience and see any potential for practical use. So, I’ll add to this list, but to start off with I’ll be looking at:

Flash Camoflage I don’t know too much about camoflage, but my general understanding is that it’s a Flash chrome and skinning framework

Tags: , , , , , ,

No Comments

Changing the behaviour of a class without recompiling.

This is a feature in AS3 that I hadn’t come accross before. If you ever load swf files into one another you might not know it, but you’ll be dealing with application domains. I’ve loaded in SWF’s before, but never had to pay any specific attention to the applicationDomain.

Basically they allow you to specify where the class definitions for an SWF are sourced from. By default if two SWF files use a class with the same name, then only the definition found in the parent SWF will be used. If you want the child SWF to use it’s own version of that class, then you need to give it it’s own application domain.

From the Adobe docs:

1
2
3
4
        request = new URLRequest("http://www.url.com/myflashfile.swf");
        var context:LoaderContext = new LoaderContext();
        context.applicationDomain= new applicationDomain()
        loader.load(request,context);

The current project I’m working on loads in a variety of SWFs that extend a common base class. It ended up that I needed to make a change to the base class, so at first I thought I was going to have to go and recompile all of the external swf files in order to incorporate the changes I’d made. But actually, this wasn’t the case due to the default behaviour of the applicationDomain. It turned out that as long as that base class was used in the parent swf, then all the external swfs that were loaded in would use the defintion found in it and not their own. Way to go! It meant that I could tweak and make changes to those external swfs, without ever open or recompile them. It’s turned out to be really useful, and painless!

Tags: , , , ,

No Comments