I was just catching up on Keith Peter’s blog and one of the posts that really caught my attention was on Toolkits vs Frameworks. The defining difference between the two, as Keith quotes Gamma, is “Toolkits do not attempt to take control for you…”.The Framework vs. Toolkit debate was in my mind when I started OpenPyro, but I feel I never stressed that enough so I felt it was worth a blog post.

OpenPyro was written in a way that it can be leveraged in either fashion. Lets take a few of examples:

The “Sprite” equivalent in OpenPyro is the UIControl, which does a few things like interpret percent based measurements, etc. It can also have a painter attached to it that can paint solid colors, gradients, stripes etc. So to create a gradient on a UIControl, all you have to do is:

var uic:UIControl = new UIControl();
var painter:GradientFillPainter = new GradientFillPainter([0xdddddd, 0xffffff]);
uic.backgroundPainter = painter

Now everytime the UIControl resizes, the painter repaints the gradient on its graphics context. However if you are not using a UIControl, and just plain sprites, you can leverage the painters again as so:

var sprite:Sprite = new Sprite();
var painter:GradientFillPainter = new GradientFillPainter([0xdddddd, 0xffffff]);
painter.draw(sprite, 200,200);

Now the painter paints the gradient on the Sprite’s graphics context. Its up to the developer to decide when to repaint the Sprite.

Here is another example with the layouts package:

var container:UIContainer = new UIContainer();
container.skin = new AuroraContainerSkin();
container.size(600,100);
container.layout = new VLayout(10);

var c1:UIControl = new UIControl();
c1.size(100%, 60);
container.addChild(c1);

var c2:UIControl = new UIControl();
c2.size("100%", 60);
container.addChild(c2);

In the above example, we have bought into the OpenPyro framework and just this code will let you create 2 control, position them vertically with a gap of 10px and automatically create a scrollbar since it will be needed ( The 2 children measure up to 60+10+60 pixels > 100px)

But the layouts package classes can be used for pure sprites too by using something like this:

var layout:VLayout = new VLayout(10)
layout.layout(sprite1, sprite2);

Similar examples can be drawn from the effects package etc. Also, OpenPyro has a fairly complete controls package each of which can be instantiated in a few lines of code as well completely independent of any framework dependencies. In fact almost all my tests are pure AS3 classes applying the package classes to non OpenPyro classes.

There is a lot of buzz going around twitter and the blogosphere the last couple of days around the future of AS3 and what the community wants. These discussions include Joa Ebert’s post on community contribution, language extensions and compiler performance, Nicolas Cannasse’s (author of the Haxe programming language) post on AS3 as a failed language and Andre Michelle’s post adding to the earlier two.

All the above posts do have valid points even if they are rather sensationally titled, though calling AS3 a failed language would be stretching it considering how many of us use it and do fairly complicated things with it even if typing “addEventListener” is a pain in the ass. The flip side to the above arguments come from Peter Elst’s post Making the case for ActionScript.

So here are my takes on the topic:

• AS3 has not failed but is definitely gotten more verbose as painful to type. Traditionally ActionScript seemed to suffer from a love affair with Java which is probably why Java/C# developers do not see the points here. However the new fashionable languages are a lot less verbose and draw a lot of attraction on that front.
• A lot of twitter conversation at this moment is talking about decoupling the AS3 language from the ActionScript Virtual Machine, and that would be cool, you could write Flash apps in a language you feel is cleaner. Alchemy enables this with C++ code, could probably be extended. For me the excitement isnt about compiling Python to the Flash Byte code but rather leveraging the language specific libraries I could use with my apps.
• I had already blogged how AS3 has gotten a bit slower to work with than AS2. Adobe should look at the mistakes people are making everyday and improve either the language or the tooling (like maybe Flash Builder could warn you if you created a displayobject but never added it as a child). Simpler constructs for everyday things like getURL, loadXML would realllly help. This could be done with a framework that wraps lower level calls, but its a pain to add a swc to a classpath that I could do without.
• Finally, lets have Adobe concentrate on features than language aesthetics. Take a look at how ugly Objective C is and you’d know we dont have it so bad. And yet, the language would not be the deterrant for me to write an iPhone app. So Adobe, I’d much rather get some player level features, and better performance for sure.

Oh and my big request of the Adobe peeps:
Adopt a secondary language and integrate well with it, especially AIR. AS3 will never have the libraries I would like to use, so if there could be a way to leverage Python or something as well on the desktop at least, that would be great. I am right now looking at TitaniumApp for some apps I wish I could have done in AIR.

One of the things that the Flex List component does pretty well is handle large data collections (Arrays, ArrayCollections, etc). The List uses renderer recycling when displaying data, ie, it creates an itemRenderer only for the items that are displayed and not for each item in the dataProvider. As items scroll offscreen, the renderers associated with those data items are reused to render the new data that appeared on screen.

For the last few projects I have worked on Flex has not been an option because of file size concerns besides others which prompted me to start working on OpenPyro, a light weight Flex-esque framework and I have been pretty happy with it so far. However its List component is a far cry from Flex’s, implemented more like a Repeater, creating as many renderers as the length of the dataProvider, and as my new projects seem to get more data intensive, I started feeling a real need for a List that does the efficient renderer recycling that Flex does. Not finding any on the web, I decided to write one for myself.

The algorithm is as follows: The List creates an instance of a class called ObjectPool, which manages used and unused renderers. Whenever the List needs a new renderer, it asks the pool for a new one and when it does not need a renderer, it returns it to the pool. The pool tries to find unused renderers to satisfy the request for a new renderer and if it cannot, will create a new object and return that.

The core part of the logic resides in the onVerticalScroll function. The list always maintains a map of all visible renderers and as the scrollbar scrolls, the map is recalculated and renderers managed if the map is changed. The source and embedded example are the first stab at the implementation. The example renders an array of 200 values but ends up creating only the 8 or 9 renderers it needs to display.

The code is not complete but I am blogging it here so that if someone feels I am on a wrong track or should investigate a different approach, you can let me know.

It should be noted that this technique only works right now for fixed rowHeight lists. I haven’t thought of the variable height renderers yet, so suggestions on that front are welcome.