AsyncCommand - A PureMVC / AS3 Utility

[puremvc]

The AsyncCommand utility offers a solution to the problem of executing a series of commands each of which may need to complete one or more asynchronous operations before the next command is executed.

The utility has historically been located here: http://trac.puremvc.org/Utility_AS3_AsyncCommand
The project has been moved here: https://github.com/PureMVC/puremvc-as3-util-asynccommand/wiki

Standard and MultiCore versions are included.

The author is Duncan Hall.

[mister_t]

Is there also an action script (as3) version of this utility? As far as I know flash can't import .swc files with only class definitions in it.

[puremvc]

Yes, for flash, simply put the classes in your classpath. Checkout the release notes page for the AS3 port for info about the varios ways you can do this.

-=Cliff>

[Neil Manuell]

feature request:

mmm I really want a pre nextCommand hook:


public final function execute( notification:INotification ) : void{
    note = notification;
    onCommandEnter()
    nextCommand();
}

protected onCommandEnter():void{}

any chance??

[Neil Manuell]

better make it onCommandEnter( notification )

[Neil Manuell]

so I can do this:

override protected function onCommandEnter( notification:INotification ):void{
   var note:INext;
   note = notification as INext
   addSubCommand(note.getNext())
}

[puremvc]

Hi Fleecie,

I see what you're after, but it seems like an edge case. I gather you want an AsyncMacroCommand to open a Notification and use it to dynamically discover the next command.

In the example you give, presumably the next command hasn't been defined yet and is not actually being added to the end of a long list of sub commands. Otherwise there'd be no point in doing this evaluation for each command in the list. It would fail if each notification didn't return a new command to be added, so execution of each command in the list would end up adding another command to the list? Seems like it could get out of hand pretty quickly.

I think it's possible that you might find what you want by using the StateMachine utility in conjunction with the AsyncCommand utility. With the StateMachine, you get notification that you're exiting one state and another that you're entering the next, and you can cancel a transition from the exiting notification.

-=Cliff>

[Neil Manuell]

I thought you might say something like that

hey hold on your right! looking at it again, i see that I've made a huge error... I actually want to extend the nextCommand()   thus:

 override protected function nextCommand():void{
var note:INext;
         note = notification as INext
         addSubCommand(note.getNext())

[puremvc]

That looks right.

-=Cliff>

[Neil Manuell]

sorry, had a server error this is the whole post


actually want to extend the nextCommand()   thus:

override protected function nextCommand():void{
    var note:INext = notification as INext;
    var nextClass:Class = note.getNext()
    if (nextClass != null)   addSubCommand(nextClass)
    super.nextCommand();

}

In this way the subcommands would be created dynamically instead of through the initializeCommand() method.  I completely see that this is a very specialised and unique case that doesn't really warrant a change.  It would just be a nicer to extend the AsychCommand Utility from a swc than create "parallel" code

cheers

[willw]

I think there is a bug in AsyncCommand.as.

The example code only considers AsyncCommand instances being invoked from an AsyncMacroCommand.

If an AsyncCommand is not run from an AsyncMacroCommand, then setOnComplete() is not called for that instance, and onComplete remains null. So when the code in AsyncCommand calls commandComplete() to indicate it has finished, the code barfs.

The cure, I suggest, is to test for an uninitialised onComplete member in commandComplete(), like this:

:

/**
 * Notify the parent <code>AsyncMacroCommand</code> that this command is complete.
 * <P>
 * Call this method from your subclass to signify that your asynchronous command
 * has finished.
 */
protected function commandComplete () : void
{
if (onComplete != null)
onComplete();
}

After this, AsyncCommands can be used standalone and in macros.

Will

[Tekool]

Willw, it's up to you to call the onComplete handler from a standalone AsyncCommand instance.

Look at the comment :

* Call this method from your subclass to signify that your asynchronous command
* has finished.

So it's not a bug. The class do not know the logic that drive to the end of the execution of the asynchronous process, the instance have to call *onComplete* itself to notify of the end of the asynccommand execution.

[willw]

So it's not a bug. The class do not know the logic that drive to the end of the execution of the asynchronous process, the instance have to call *onComplete* itself to notify of the end of the asynccommand execution.

1. You seem to be confusing commandComplete(), a protected method, and onComplete, a private instance variable containing a pointer to a function. It is commandComplete() that one is supposed to call - onComplete is not in scope in an inherited class.

2. Yes, it is a bug. If the inherited code (correctly) calls commandComplete() from a standalone AsyncCommand (ie not run as a macro) to notify end of execution, then onComplete is null, and the program dies.

Will

[Tekool]

@willw You're right, you must understand *commandComplete* not *onComplete*.

To be honnest, I can't see the context where you need an AsynCommand to call *commandComplete* without to have a wrapper that declare the *onComplete* callback like in the AsynMacroCommand. But you're right, your patch will prevent any use of the AsyncCommand as a SimpleCommand.

[willw]

To be honnest, I can't see the context where you need an AsynCommand to call *commandComplete* without to have a wrapper that declare the *onComplete* callback like in the AsynMacroCommand. But you're right, your patch will prevent any use of the AsyncCommand as a SimpleCommand.

The point is that a AsyncCommand shouldn't care whether it is being used standalone or as part of a macro. It should work either way, without needing to change its behaviour. For example, you may design an AsyncCommand to be used by itself, and subsequently add it to a macro.

Will