A friend just sent me the YouTube link Chris Hall, Ali Mills – Useless Wooden Toys 1990 New Deal. Wow, I’m on YouTube. Check it out:

The second skateboarder in that clip is me! That was seventeen years ago when I was a skateboarder (OK, I’m still a skateboarder, but now I happen to run, surf, boulder, spearfish, and code much more than I skateboard). I get a lot of credit (Ali Mills, first documented nollie kickflip) for one of the tricks I did in that video part, and that credit is one of my proudest accomplishments. Like all worthwhile things in life, that accomplishment came from a lot of preparation combined with a little luck. I was lucky enough to have been skateboarding at a time when invention and innovation were still pretty easy to do in the sport, and I was prepared enough to make the best of that time. Back then, I was skateboarding so much that I could make my skateboard do almost anything with a day of practice.

These days, I spend so much time writing code that I almost feel the same way about it…

To the point – I have a strong feeling that we’re at a time in application development history that’s comparable to skateboarding in the ‘90s. Right now, it’s still pretty easy to invent new ways of doing things and innovate on the old. There’s a lot of it going on (Web 2.0). As SWF developers, we’re at an advantage because the platform we’ve practiced with is optimized for this future.

Focus on the future, and accomplish something you’re proud of. Now’s a great time.

The code below may look like ActionScript, but it’s not. It’s haXe. Can you spot the differences?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

package mediator.events;

import mediator.events.Event;
import mediator.events.EventListener;

class EventDispatcher {
    private var listeners:Array<EventListener>;
    private var eventTarget:Dynamic;

    public function new(?eventTarget:Dynamic) {
        listeners = new Array();
        if(eventTarget) this.eventTarget = eventTarget else this.eventTarget = this; 
    }

    public function addEventListener(type:EventType, handler:Dynamic, context:Dynamic):Void {
        removeEventListener(type, handler, context);
        listeners.push(new EventListener(type, handler, context));
    }

    public function removeEventListener(type:EventType, handler:Dynamic, context:Dynamic):EventListener {
        var listener:EventListener = new EventListener(type, handler, context);
        for(i in 0...listeners.length) {
            if(listeners[i].equals(listener)) {
                return listeners.splice(i, 1)[0];
            }
        }
        return null;
    }

    public function dispatchEvent(event:Event):Bool {
        var type:EventType = event.type;
        var listener:EventListener;
        untyped {event["target"] = eventTarget;}
        for(i in 0...listeners.length) {
            listener = listeners[i];
            if(listener.type == type) {
                Reflect.callMethod(listener.context, listener.handler, [event]);
            }
        }
        return true;
    }
}

I must have learned something from the first chapter of The Pragmatic Programmer by Dave Thomas (who’s probably better known these days for his contributions to the Ruby community through his publishing company and must-have book Programming Ruby) when I read it long ago. In that chapter, Dave’s 8th tip is to, “Invest Regulary in Your Knowledge Portfolio”. One of the ways he suggests doing so is to learn one new language a year. Well, this year I seem to be making up for years gone by, because I’ve been spending a lot of my extra time working with several different languages and their frameworks. This year, I’ve been working with – in order as of today – haXe, Flash Lite 1.1, Ruby, ActionScript 3.0, XUL, and the Nullsoft Scriptable Install System. I’ve been working with their frameworks Ruby on Rails, Flex, and XULRunner.

All of these languages are tools to build the kind of software that I’m interested in building: software that’s fun to write, easy to distribute, a pleasure to use, useful, and affordable. For software to be distributed easily and a pleasure to use has to be universally available. And, to be universally available it needs to be truely cross-platform – cross-software and cross-hardware. It needs to work on win, mac, and nix and also in a browser, on a desktop, and on a palmtop. Today, the best format to make software universally available is the SWF format. It’s undeniable, more people have the Flash Player than any other piece of software .

It is, granted, worth noting that some feel like traditional Java, non-traditional Java, Python, Ruby, .NET, and the Mozilla Foundation’s XUL are also acceptable tools to make available software, and depending on the goal, they’re correct. In many cases, these technologies can even enhance a SWF’s funcionality. For example, it’s possible to use Mozilla’s XULRunner as a desktop wrapper for SWFs, or if you’re really smart, to do what Rich Kilmer did and write a SWF view to a Ruby controller and Berkeley DB model. Rich gave me and Luke a sneak peak at his indi product at RailsConf, and we were blown away. The product is a great idea, and it’s built on an extremely smart and interesting architecture. Get indi when it’s available.

Invest regularly in your knowledge portfolio.

On this second Twosdays, I’m posting photos of two iPods that I’ve been given as gifts from companies who make SWF creation tools. I got my iPod shuffle from Xamlon for wearing a Xamlon shirt to Robin Debreuil’s QA session at Flashforward a couple years ago. Here it is:

In the previous post Library Type Assets in ActionScript 3.0 :: using the [Embed] metatdata tag, I mentioned that an ActionScript 3.0 application can load library type assets (i.e. SWFs) created in current releases of Flash Authoring during run time. This is a big deal – a huge deal – because without this ability there wouldn’t be any way to create a MovieClip and include it in a Flex Builder 2.0 project until Blaze becomes available.

The simplest way to load a legacy SWF is with the Loader class. After it’s loaded, you can manipulate its DisplayObject properties with the Flash 9 Player’s AVM1Movie adapter class.

While this method works well for canned widgets like video and music players that don’t need to communicate with their host application, it doesn’t work well when host communication is a requirement. When this is a requirement, it’s necessary to take advantage of features available through the LocalConnection class, because the only way for ActionScript 3.0 running in the AVM2 to communicate with legacy ActionScript running in the AVM1 is over a LocalConnection .

While researching an elegant solution to the problem of how two pieces of code (AS2 and AS3) running in two separate virtual machines (AVM1 and AVM2) can communicate, I looked to the book Enterprise Integration Patterns : Designing, Building, and Deploying Messaging Solutions from the signature series of one of my favorite authors Martin Fowler. Chapter 2 of the book explores different integration styles and suggests that the Remote Procedure Invocation approach is a, “mechanism for one application to invoke a function in another application, passing the data that needs to be shared and invoking the function that tells the receiver application how to process the data.” After reading this and the rest of the section (the full Remote Procedure Invocation section can be found online at http://www.awprofessional.com/articles/article.asp?p=169483&seqNum=4), I was convinced that the Remote Procedure Invocation approach would work and designed an AS3 stub and AS2 skeleton class. They follow: