Fixing multiple parsley result handlers being called [Update]

This passed week I was testing my application and noticed some odd behavior. After some debugging, I noticed that two command result handlers were being called, when in fact only one of them should be. The application was built using the Parsley framework, so to quickly explain the problem and solution, here is what was happening:

1. Application was dispatching the MyEvent1 event
2. The MyCommand1 was being executed and the MyCommand1 result handler was being called
3. Then the problem, the MyCommand2 result handler was being called.

So why was the MyCommand2 result handler being called? Because Parsley didn't know any better based on how I coded both handlers. Here is how both handlers were coded:

[CommandResult]
public function onResult( event:MyEvent1 ):void

[CommandResult]
public function onResult( event:MyEvent2 ):void

In both cases, the remote java call returns void, so I declared only one parameter for each function, the event that dispatches the command class. Since I didn't specify the event class name (the type as Parsley calls it) in the CommandResult metadata tag, Parsley will use the 2nd parameter to determine the type. Oh, but I don't have a second parameter! Hence the problem, so Parsley just ended up calling both handlers. So there are two ways to solve this problem...

1) Add another parameter to the handler function of type Object that will not be used, like so:

[CommandResult]
public function onResult( obj:Object, event:MyEvent1 ):void

[CommandResult]
public function onResult( obj:Object, event:MyEvent2 ):void

2) Declare the event type in the metadata tag, like so:

[CommandResult(type="bla.MyEvent1")]
public function onResult( event:MyEvent1 ):void

[CommandResult(type="bla.MyEvent2")]
public function onResult( event:MyEvent2 ):void

I ended up using solution #1 and then I only had the one result handler being called, which is what I wanted.

UPDATE: Actually good catch by Devin, if you just use the [CommandComplete] metadata tag, then your handler method only requires one parameter, the associated event object. Totally missed this one while reading the documentation.

AIR 3.0 beta and Flash Player 11 beta available!

Well a big day today, shows that Adobe is busy at work even though we are in the middle of the summer. Today Adobe has announced the beta availability of the next major versions of AIR and Flash Player.

The AIR 3 beta, is a run-time only beta at the moment, so as to test backward compatibility with applications built with the AIR 2.7 SDK. The AIR 3 SDK beta will be made available at a later date. Major speed improvements are the highlight of this release, but more details will come I'm sure.

As for the Flash Player 11 beta, we have a bit more details on this side. The next version of our little player that could will contain Stage 3D APIs, 64-bit support (finally!), HD Surround Sound, Socket Progress Events (you can now built FTP clients), G.711 audio compression and H.264/AVC for higher quality video encoding. Well that was a mouthful, go check it out!

Great AIR for Android tutorial

As I was building my first AIR application for Android, I was naturally doing some research into how to get started. No article helped me more than this one from Narcico Jaramillo from Adobe. It properly explained the basics about the new Flex components that you need to use for mobile development and also had some links to some great step-by-step tutorials (scroll all the way to the bottom of the page) on how to build your first application using Flash Builder.

Kudos to Narcico for the great articles!