Archive for the ‘Flex’ Category

Threading in Flex

There have been several times where we have had to process large sets of data in our client side Flex applications. Several of these locked the UI for up to 15 seconds on slower machines until we started chunking up the work load.

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.

Advertisements

Playing with Tamarin

I played around with Tamarin about a month ago and have been meaning to blog about it. Tamarin is the Adobe/Mozilla open source ActionScript virtual machine. You can figure out how to install and build it here (I don’t want to go through all of the gory details).

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. ūüôā

New name for Kashi

Okay guys, we gotta rename Kashi to make it legit. Please vote:

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

Fun With Omnigraffle

I’ve been working on diagrams for my Kashi documentation using Omnigraffle. First of all, sooooooooo much quicker than Visio. Second, here ya go:

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.

How to Control a View

One of the tricks I’m working out for Kashi is deciding how to best attach a view controller to the view. The job of the “view controller” is to handle ui events and animation and move script away from mxml.

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.