http://360flex.uservoice.com/pages/22404-360max/suggestions/257190-automate-flex-with-ruby

Eventually, we solved this issue by developing a framework to instantiate and manage ‘thread’ objects. The threads are really just managed time slices.

The framework has the following features:

* easily instantiate and manage n number of threads
* threads have adjustable priority settings
* messaging between threads handled by reflective method handlers (similar to Fabrication for PureMVC)
* load balancing of thread executions in order to optimize performance
* easy and simple api: start(), sleep(), wake(), kill()
* threads can auto-adjust their workload based on the performance of the application. basically, if the app is slowing down, the threads can buffer down their work load. similarly, they can ramp their workload up if the application is running smoothly and the library feels that there is room for increased load.

This library has gone through our open source review board and has been approved to be released into the wild

You can get it here:
http://code.google.com/p/async-threading/

The project archive file contains src, asdoc, and compiled swc.

Building a project is fairly simple. You use the asc.jar (ActionScript compiler) to create an abc file (action byte code? alphabet a-b-c?). Then you run it with the avmshell. The first thing I did is write this awesome piece of code:

print("hello worlds.")

Note that we get a “print” function. The Tamarin ActionScript language is the same as the Flash/Flex AS3 that we all are used to, but it’s platform is different so the packages are different. The print function dumps text out to the console.

In my Mac terminal (Windows should be similar if not the same), I type:

java -jar ./tamarin-central/utils/asc.jar -import
   ./tamarin-central/core/builtin.abc hello.as

And it makes hello.abc (which clocks in at a whopping 87 bytes).

./tamarin-central/objdir-release/shell/avmshell hello.abc

Outputs: “hello worlds.”

I did some digging around in the tamarin-central/shell path and found shell-toplevel.as. This has all sorts of good stuff in it… a File class memory in and out. A readline function. Here’s the next little test I wrote:

import avmplus.File 

var foo:Array = ["hello", "world", "yo"];
var i:uint = 0; 

for ( i = 0; i < foo.length; i++ ) {
    print( foo[i] );
} 

print( "writing to a hello2.txt..." );
File.write( "hello2.txt", foo.toString() ); 

print( "reading file..." );
try {
    print( File.read('hello2.txt') );
} catch (e) {
    print( e.toString() );
}

It outputs:

hello
world
yo
writing to a hello2.txt...
reading file...
hello,world,yo

And creates a “hello2.txt” along the way. Sweeet.

Now I just have to figure out what this is all useful for.

The time is 13:30 PST and the polls are closed. “Monarch” is now the the official name for Kashi. I’m gonna tack on “MVC” so “Monarch MVC”. Hopefully the name will strike fear and reverence into our, um, Flex code.

Update: We will have a run-off vote of the top 2 during today’s code-review.

I think the last one is the coolest looking, but it’s the more complicated option…. The first two use code-behind for the views. The last uses a map to assign a view controller to the mxml view.

This may be something we want to leave up to each application…. projects that don’t need multiple-skins may be just fine with a more tightly-coupled view controller. On the other hand, some projects need a more flexible approach.

Approach #1: Code Behind

This is the tightest-coupled approach with the least overhead. You simply create a class that extends Canvas (or whatever container), then you create an mxml class with the base tag set to your custom class.

So, if your class is:

class Foo extends Canvas

In mxml:

<Foo xmlns="*">
...
</Foo>

You can easily call functions from the mxml like this:

<mx:Button id="myButt" click="someClick(event)" />

The reverse is a bit trickier. You have to instantiate the button in your code-behind class before you can access it…

var myButt:Button;

 Approach #2: Dependency Injection – VC into MXML

In your mxml you have a public variable vc. Ideally, this is typed to an interface, otherwise you loose code-hinting and compile-time checking. When you instantiate the mxml you do something like this:

<Foo vc="{fooVC}" /> 

One down-side here is that you refer to vc a lot in your mxml. You also have to have the fooVC easily available at the point where you instantiate Foo.

Approach #3: Dependency Injection – MXML into VC

Another way to go about it is to do something like PureMVC’s mediator approach (thanks Ben and Benjamin!). This method allows the mxml to be controller-independent. I like that. You create very Flexy (that’s a word) mxml with public bindable properties, then you could do something like this:

<Foo id="fooView" />
<FooVC view="fooView" />

Ugh. That looks ugly. The downside here is that Flex is mxml-centered, so it doesn’t make mapping this direction as clean as it could be. Optimally, we’d have a ViewControllerMap class (or something along those lines) that would do the attachments:

fooVC = new FooVC( path.to.view.fooView );

This has two down-sides. First, we have to worry about timing issues… too soon and you’ll get a null error, too late and you might see a blip on the screen. Second, drilling down that path is ugly. I suppose this would work out okay, if all the views were on Application.application and we did it on initialization.

The Front Router

The most significant change so far is a FrontRouter mxml class. This let’s you map events to routes. Routes consists of one or more commands.

Not only does this fix the messy state of Cairngorm’s SequenceCommand, but it adds the ability to set properties on commands before they execute. This makes the commands a lot more portable. You can use the same command multiple times with different models to push the results into.

Added bonus: multiple events can trigger a single command. The view layer doesn’t need to know about this.

Name-wired Dependency Injection Defaults

Okay. I need a more catchy name for this feature. Here’s the deal: injecting an instance of a model into views and commands is the best practice… better than locking the code into a singleton (Cairngorm) or even singleton factory (our current system). But it’s annoying to specify for “fooView” that you want “fooModel”. So, Kashi figures it out for you. If you have an instance named “fooView” it will automatically look for a model instance named “fooModel”. Also, if a route is named “fooStartupRoute” it’s commands will default to use “fooModel”. These are defaults, so you can always set them manually.

I’ll post some concrete examples with code shortly.