Code Kills

AsyncResult — making async in ActionScript suck less

2010-10-10T01:47:00Z

Let's face it: the tools Adobe provides for dealing with asynchronous operations in ActionScript are basically crap. We've got AsyncToken, which seems pretty good... Until you try and use it yourself, and realize that there's no way to inject your own result. And then we've got the IResponder interface, which also seems pretty good... Except that sometimes your responder gets a ResultEvent and other times it gets the actual result. And then there are the half million events you can listen for (and remember to remove your event listeners for!). And... Well, if you've spent any time in ActionScript, I don't need to say any more.

But I'm not (usually) one to complain without offering a solution.

So let me present: AsyncResult.

In the simplest case - only handling a result / error - it looks something like this:

UserService.loadUser(userID).complete(function(user:User):void {
    // ... do stuff with the User ...
}, function(error:AsyncError):void {
    // ... handle the error ...
});

But that's not what makes AsyncResult cool.

Imagine, for a minute, what that UserService.loadUser function would look like. Maybe it fires off a request to a server which sends back some JSON, which is then loaded into an instance of User then returned. Pretty straightforward... Except it probably takes a small army of event listeners, callbacks and error handlers (which all need to be documented and tested and maintained and...).

This is the kind of situation which AsyncResult was designed for. Check it out:

public function loadUser(userID:String):AsyncResult {
    var token:AsyncToken;
    var result:AsyncResult = new AsyncResult();
    // (HTTP transaction intentionally simplified)
    token = HTTPService.sendGET("http://.../users/" + userID);
    // The AsyncToken is plugged into the Flex AsyncToken
    // through 'getResponder()'
    token.addResponder(result.getResponder());

    // This is where the magic happens:
    result.complete(function(jsonData:String):User {
        var userData:Object = JSON.loads(jsonData);
        var user:User = User.loadFromObject(userData);
        return user;
    });

    return result;
}

Two things to notice about the above code: first, the complete callback accepts JSON data (not an event) and, more importantly, returns an instance of User. Second, no error handling is done.

This is possible because AsyncToken chains all of its handlers. When a result (or error) is received, it is passed to the first handler. If that handler returns a new value (that is, something other than undefined), that new value is passed to the next handler, and so on.

For example, this is what happens if the complete handlers add1 and add2 are used:

>>> function add1(x) { return x + 1};
>>> function add2(x) { return x + 2};
>>> function printx(x) { trace("got:", x); };
>>> r = new AsyncResult();
>>> r.complete(printx);
>>> r.complete(add1);
>>> r.complete(printx);
>>> r.complete(add2);
>>> r.complete(printx);
>>> r.gotResult(0)
got: 0
got: 1
got: 3
>>>

In addition, if any of the handlers return an AsyncResult, the original AsyncResult will wait for the new AsyncResult to complete, then pass the new result to the next handler.

For example, going back to the User example, imagine that we need a (slightly contrived) loadFavoritesForUserID(userID:String) function. It could look something like this:

function loadFavoritesForUserID(userID:String):AsyncResult {
    var result:AsyncResult = UserService.loadUser(userID);
    result.complete(function(user:User):AsyncResult {
        var token:AsyncToken;
        token = = HTTPService.httpGET(user.getFavoritesURL());
        token.addResponder(result.getResponder());
        return result;
    });
    result.complete(function(jsonData:String):Array {
        return JSON.loads(jsonData);
    });
    return result;
}

Well, that's a short introduction to my awesome AsyncResult. If you're interested, check out the code and hit me up on Twitter, @wolever. And if you're not interested, let me know why in the comments.

A Parameterized Testrunner for FlexUnit

2010-02-10T15:54:00Z

A couple of days ago, I complained about FlexUnit's Theories. Well, with a bit of encouragement from @drewbourne, I broke down and wrote a proper parameterized testrunner:


    [RunWith("utils.testrunners.ParameterizedRunner")]
    class AdditionTests {
        public static var numbersToTest:Array = [
            [1, 2, 3],
            [4, 5, 9],
            [-1, 1, 0]
        };

        [Parameterized("numbersToTest")]
        public function testAddition(a:int, b:int, expected:int):void {
            assertEqual(a+b, expected);
        }
    }

And that code will do exactly what you'd expect: run three test cases, one for each of the inputs. If one test fails, the others will still run. Helpful error messages will be provided when a test fails.

The source can be downloaded from: http://gist.github.com/299871 (and it will be getting a new home when ever I get around to releasing all of my AS utilities)

Look useful? Give it a try and tell me what you think – I'd love to know.

Update

Since this article was written, parameterized tests have been added to FlexUnit core. The documentation is over on the FlexUnit wiki: http://docs.flexunit.org/index.php?title=Parameterized_Test_Styles

And this is the above test, using the FlexUnit syntax:

 
    [RunWith("org.flexunit.runners.Parameterized")]
    public class AdditionTests {        

        public static var numbersToTest:Array = [
            [1, 2, 3],
            [4, 5, 9],
            [-1, 1, 0]
        };


        [Test(dataProvider="numbersToTest")]
        public function testAddition(a:int, b:int, expected:int):void {
            assertEqual(a+b, expected);
        }
    }

FlexUnit's Test Theories: Don't Bother

2010-02-05T23:47:00Z

I've just been playing around with FlexUnit 4's nifty new "Test Theories"… And I have come to the conclusion that, right now, they are basically worthless.

Here's why:

They aren't documented. At all. There are approximately two examples on the internet, and the wiki page is a joke. Nothing explains what algorithm is used to calculate which DataPoints are applied to which theories.
They make test error messages less helpful. If a a theory fails, instead of getting a helpful error message like "Theory `checkUrl("this is a bad url")` failed with message: could not determine protocol", it gives a message like this: "checkUrl urls[1]". Yea, thanks guys.
They don't do anything "cool". At all. It would be cool if, given five data points, five distinct tests would be generated. It would be cool if one data point could fail while others succeed. Heck, anything which would make them better than a for loop would be cool. But, alas…

So, don't waste your time on Theories just yet. For now, just use a for loop:


[Test]
public function runTestsOnData():void {
    for each (datum in testData)
        doSomeTest(datum);
}

Or, if you want to test the cartesian product of a set of data, use my handy cartesian product function:


[Test]
public function runTestsOnCartesianProduct():void {
    for each (data in cartesian_product(testData0, testData1))
        doSomeTest.apply(this, data);
}

Followup: as Alan (see comments) said, what I really want is a parameterized testrunner. So I've gone ahead and written one. See my post on a Parameterized Testrunner for FlexUnit.

Best Ever Implementation of "indexOf"!

2009-12-08T03:31:00Z

(alternate title: The "Fail Early, Fail Often" Principle in Action)

I would like to award Adobe the "best ever implementation of indexOf". Ready for it? Here it is:

override flash_proxy function callProperty(name:*, ... rest):* {
    return null;
}

This beauty can be found in mx.collections.ListCollectionView.

And the kicker? The function's documentation:

/**
 *  @private
 *  Any methods that can't be found on this class shouldn't be called,
 *  so return null
 */

The author clearly knew that unknown methods* shouldn't be called… But instead of doing something sensible – like throwing an exception – they do something wholly nonsensical and return null. Or, of course, they could also have left the function unimplemented, which would result in a strange and unhelpful exception… But, of course, I would expect nothing but the best from the Flex standard library.

Next up: why implicit conversions from null to int are always wrong.

</rant>

*: the magic callProperty method is called on subclasses of Proxy when a method can't be found. For example if bar is not a method of foo, executing foo.bar()will call foo.callProperty("bar").

PS: Instead of calling indexOf, I should have been calling getItemIndex.

Making Flex's PopUpMenuButton More Helpful

2009-08-25T22:09:00Z

If you're anything like me, you cringe every time you think about implementing a popup menu in Flex: the options, PopUpButton and PopUpMenuButton, are both terrible.

For example, PopUpButton makes you jump through the hoops of creating a Menu and PopUpMenuButton forces you to create an event handler just to get the currently selected item.

Well, cringe no more! I've done a bit of hacking on the PopUpMenuButton to make the most common use-case, "showing a list of options", a little bit less painful by adding a 'selectedItem' field:

    <mx:XML id="colors">
        <colors>
            <color name="Red" rgb="0xFF0000" />
            <color name="Green" rgb="0x00FF00" />
            <color name="Blue" rgb="0x0000FF" />
        </colors>
    </mx:XML>
    
    <HelpfulPopupMenu id="colorMenu"
        dataProvider="{colors}"
        labelField="@name"
        showRoot="false" />

    <mx:Label
        color="{XML(colorMenu.selectedItem).@rgb}"
        text="You've chosen: {XML(colorMenu.selectedItem).@name}" />

Which can also be used to set a temporary default option:

    <mx:Script><![CDATA[
        var people:Array = [
            { name: "Bob", age: 16 },
            { name: "Alice", age: 42 },
            { name: "Jo", age: 31 }
        ];
        
    ]]></mx:Script>
    
    <HelpfulPopupMenu id="peopleMenu"
        dataProvider="{people}"
        labelField="name"
        selectedItem="{ { name: '(select a person)', age: null } }"
        showRoot="false" />

    <mx:Label
        visible="{ peopleMenu.selectedItem.age !== null }"
        text="That person is { peopleMenu.selectedItem.age } years old." />

Useful? I'd like to hope so.

You can see a demo by clicking the image below (sorry, I don't actually know the first thing about embedding SWFs into HTML, and I don't feel up to learning right now):

And you can download the source (which is MIT licensed) from more or less the same place: http://wolever.net/~wolever/HelpfulPopupMenu/.

Also, this is a small part of a larger library of helpful ActionScript utilities which I'm going to be releasing… At some point.

Using Hamcrest to Filter ArrayCollections

2009-08-11T16:03:00Z

Neil Webb's post on filtering an ArrayCollection on multiple property/values reminded me of how I recently solved exactly the same problem using Hamcrest-AS3.

So, you know the story: you've got an ArrayCollection that's full of, say, Laptops, and you want to filter it by, say, price, size and (of course) color.

Because you're a good programmer you always try to do the simplest thing that could possibly work first, and end up with a function something like this:

function laptopFilter(laptop:Laptop):Boolean {
    if (laptop.price > appliedFilters.maxPrice)
        return false;

    if (laptop.size > appliedFilters.maxSize)
        return false;

    if (laptop.color != appliedFilters.preferredColor)
        return false;

    return true;
}

Cool - that defiantly works, and it's pretty simple.

"But wait a second", you're thinking, "what happens when the rules get more complex? That function is quickly going to loose its simplicity!"

Enter, Hamcrest.

Hamcrest is a library of "matchers" which are often used to build unit tests. Here is a quick example of a unit test written with Hamcrest:

[Test]
function testApplePicker():void {
    var apples:Array = ApplePicker.pick("granny smith");
    assertThat(apples.length, greaterThan(4));
    assertThat(apples, everyItem(hasPropery("color", "green")));
}

But, of course, there is no reason that these same matchers shouldn't be used for other things too.

Other things like, say, filtering an ArrayCollection:

var filters:Array = [
    hasProperty("price", greaterThan(1000)),
    hasProperty("color", either("red").or("blue").or("green")),
    hasProperty("size", between(10, 15))
];

var laptopFilter(laptop:Laptop):Boolean {
    return allOf.apply(null, filters).match(laptop);
}

Of course, I've hard-coded the values in this example, but it doesn't take much creativity to imagine how they could be dynamically generated, keeping the code nice and simple while still allowing for complex rules.

So, that's how I filter ArrayCollections

Overriding private methods in ActionScript, the hard way

2009-07-10T14:49:00Z

Are you working with a proprietary .swc? Does it have lots of bugs? Did the authors, in all their infinite wisdom, decide to hide those bugs in private methods, so you stand no chance of being able to fix them? Well, friend, let me show you how to fix that.

Step 0: Uncompressing the `swc`/`swf`

First make a backup copy of the library (just incase you botch something):

 $ cp binary_library.swc binary_library_backup.swc

Then unzip the swc file like you would any other zip file:

 $ unzip binary_library.swc

This will extract, among other things, a library.swf file.

This library.swf will probably be compressed, so you've also got to uncompress it. To do that, I like to use SWFTOOLS:

 $ swfcombine -d library.swf -o uncompressed_library.swf

Step 1: Dumping the ABC

Now that you've got a nice uncompressed swf, it's time to decompile it. To do this, you can use or my patched version of swfdump.

 $ java -jar swfdump.jar -abc library.swf > library.abc

Step 2: Finding the multiname pool entry

Now pull up library.abc in your favorite text editor and search for the method's name under the "MultiName Constant Pool Entries" heading. For example, if the method's name is "priv", you'll be looking for something like this:

6 MultiName Constant Pool Entries
07 01 04 private:priv <-- here
07 02 06 :void
07 02 09 :pub
07 02 01 :A
07 02 10 :Object

Note that the method may be prefixed with a namespace:

6 MultiName Constant Pool Entries
...
07 01 04 com.foo.ClassName:methodName

Technical details: The first of those three bytes refers to the entry kind. The second is a one-based index into the list of namespaces (which are listed under "Namespace Constant Pool Entries") and the third is a one-based index into the list of string constants ("String Constant Pool Entries"). For all the details, see section "4.3 Constant Pool", "4.4.3 Multiname" and "4.1 Primitive data types" (for the definition of u30 – making sure to read the paragraph witch mentions that it uses little-endian byte order) in AVM 2 Machine Overview.

Note: If you're dealing with a large .swf, there may be four or even five bytes:

07 01 B9 03 :methodName

Don't worry – that's ok!

Make note of the bytes (in this case, 07 01 04) which prefix the method, then move on to step 3.

Step 3: Find a similar method

Next thing you've got to do is find a method of the same class which has a pubic (or protected) scope. In this case, we have a method called 'pub':

6 MultiName Constant Pool Entries
07 01 04 private:priv
07 02 06 :void
07 02 09 :pub <-- here

Make note here of the byte (02): that tells the AVM which namespace the method belongs to.

Step 4: Hex edit the uncompressed library

Now, pull up your favorite hex editor and open up the uncompressed_library.swf, which you created in step 0. Now, remember those bytes which prefix the method name? Search for them (and make sure you only find one instance of them – if there are multiple instances of them, expand the search to take into account the next few bytes (so, in this case, 07 01 04 07 02 06). Now, once you've found them, simply replace the second byte (in this case 01) with the second byte of the similar method:

07 01 04

is replaced with:

07 02 04

Step 5: Checking that you got it right

To check and make sure that you got it right, run the swfutil again, then check the output:

$ java -jar swfdump.jar -abc uncompressed_library.swc

You should see your change reflected in the MultiName constant pool entries:

6 MultiName Constant Pool Entries
07 02 04 :priv
07 02 06 :void

Note that the method is no longer prefixed with 'private' (or whatever the original namespace was).

Now, if the utility crashes, or something else doesn't work, go back and try again – you'll get it eventually.

Step 6: Putting it all back together

You're almost done! All that's left to do is put everything back into the .swc.

First, copy uncompressed_library.swf over top of library.swf:

$ cp library_uncompressed.swf library.swf

Or, optionally, you can re-compress it:

$ swfcombine -z -d library_uncompressed.swf -o library.swf

Then put library.swf back into the swc:

$ zip binary_library.swc library.swf

Finally try linking against it to see if everything worked!