I’ve tried the last couple of years to keep a blog up to date, but I’ve just not got enough time at the moment. I could make a snide remark that I’m going the way of the Flash runtime, but that would be harsh! Also if you actually want to keep up with my stuff it is better to use github or last.fm or follow me on twitter.
This will be around until the hosting runs out, which is about 5 days or so.
Again I’m talking about Adobe and another missed opportunity in regards to the AVM/ActionScript3 stack. The following is a criticism of the company and not thinking about the broader horizons, not really anticipating what developers want. It’s only now that I believe they’re beginning to understanding this, but I think it’s a little too late, the ship has sailed! Developers are what push the technology, look at all the 3D engines created 3-4 years back with massive push of client projects and money for developers. It’s only now that real 3D was implemented!
Look how Javascript/CSS3 has moved to the forefront, developers are implementing what flash could do a few years back, but are improving it with semantics and readability. Taking on some of the frailties of Flash (screen readability, fallbacks and other browser implementation issues), don’t get me wrong, it’s still not perfect, but it’s better than some of Flash’s attempts.
I know that there is only a limited amount of resources to implement some of the things developers want, but it seems that they’re not thinking about the broader picture. The company has spent quite a long time implementing the iOS packaging tool for Flash for example. It’s a great little tool, but probably underused considering it’s possible potential. Why do I talk about this, well it turns out that the way the packaging tool works is that it provides away to compile your ActionScript3 code via the LLVM into AVM code. It now turns from a JIT compiled language to AOT compiled language with some issues currently that you can’t have multiple swfs with code in them. This missed opportunity here is that LLVM can have many backend outputs, Adobe only implemented/used one backend and that’s targeting ARM (for iOS). It would be that much of a stretch of imagination to implement a different backend, C/C++/Java (the list continues). So instead of seeing ActionScript as a dead end language with no possible road a head long term (unlike haXe) there could have been a possibility where your ActionScript code could run natively on any platform with the speed of C/C++ (hand written code would obviously be much faster that this version, but it would be faster than running on the AVM!).
Imagine the possibilities, super fast code with the ease of developing with ActionScript… shame it’s never going to happen!
The stream of tweets this week revealed that Flash Player 11 is out… awesome! Maybe they implemented some really cool new features that I would like to play with…. hmmm…. the list looks small… bummer!
In all seriousness, I think the new 3D stuff is awesome, it’s going to be really amazing. If we can somehow utilise it for user interfaces then we’re off to a winner! That’s one of the major issues that I had and still have is that when it comes to rendering it just doesn’t cut the mustard. Hopefully this will change and it will give one less thing for me to bitch about. It’s sort of a love hate relation ship I have with the ecosystem that is Flash. One things for certain, I’m really thinking of leaving it and moving on to Java/Scala and even dare I say it Javascript (probably using haXe if anything)! Why I hear you cry, here be a list:
I really do hope this stuff is coming, because I think it really is make or break time. People that didn’t want to invest that much into Actionscript 3 are now moving or have moved on to other languages (Javascript). The people that are still riding it out for better language expressiveness to get down in code what’s on the tip of their fingers are thinking about it or have already done so!
Edit:
I was speaking with various colleagues about this thread and we all tended to agree, that most of this is syntax sugar. We use this language day in day out, I’ve invested a lot of time into this language and it would be helpful if this language could help us out as well.
You may as an observer say well this looks like language A or like B, I would love to work in A or B, but I’m on a project that requires AS3 and we don’t have to option to move to A or B. In the future though I think A or B is on the horizon, especially in these fast moving times.
My list of libraries are growing, not only have I got AS3-Mixins and AS3-DOM I’ve started to gather pass and add lots of new AS3 libraries with a liberal license (MIT). Quick overview:
I’ll be investing most of my time in the components and improving them 
Today I managed to get some free time at lunch to implement a very quick example of what is possible with AS3-DOM. There isn’t much really to it, all it does is sort through a series of Layers (DOMNodes) and then animate them to a new position. It’s amazingly quick for a first example and I was more than impressed with the results! As this is release 0.0.1 alpha there is a lot to improve, especially the need to create an object pool for the expressions. Maybe I’ll get some free time next week to implement this…
View the source code
This is a very small update about the AS3-DOM project. The project has under gone some massive updates in the last couple of days, including the syntax. I was running in to a lot of problems trying to work out an easy way to parse methods and groups for if statements, but was just hitting a brick wall. So I took the plunge and ripped out the implementation part of the DOMPath compiler and put in a new one. The great thing with the new one is that it’s already surpassed the old one in terms of speed, readability and syntax which can be used. The reason it was actually so easy to do this was because I started the path part of the project in a more Test Driven Development way. There is a lot of open discussion about TDD, but I can say at the moment that I’m sold on it for this type of project and possibly for work, but I would need to try it out whilst working with others. You can see some of the tests in the public repo here and the syntax which can be used.
I’m currently experimenting with the fusing of the DisplayList and the DOM and currently looks like I’ve got two approaches. More on this when I’ve got a solid test setup to verify this.
This is just a really quick update on a couple of projects I’ve got going:
AS3-Mixins
I’ve been fortunate to have some free time recently (no idea how or where from!), but I’ve managed to get AS3-Mixins to a stable enough state so that it can be used without it break everywhere. There are a few notable improvements over the first initial creation of the project. It’s gone through a massive re-factor, with the aim to improve the speed of mixin creation at startup. Most of the work has also been looking into improving memory consumption and I spent a lot of time caching bytecode and types from flemit and the mixins project. There is still a bit to do in this area, but it’s a lot more efficient that it’s ever been.
I’ve also added the ability for method overloading from a super class, added the ability to use a mixin in a MixinFactoryPool and tons more. This was mainly aimed at the creation of say tiles in a game, so at the start of a level you can create a series of titles/enemies/etc and reuse them without worrying about how to store them or reuse them. It’s a strongly type factory so it knows what mixin belongs to which pools. There is even a debug helper class which you can use to find out how healthy the MixinFactoryPools are i.e. you can monitor how full the pools are and when they’re about to be grow because the pools will be exhausted. All very useful for development.
AS3-DOM
Another project I’ve started (told you I’ve got some spare time!) is the creation of a DOM system in AS3. With the aim to provide a very easy selection tool for user interfaces (or anything else you can thing of using it with). It’s basically in it’s infancy, but it’s going to be something like xpath for AS3. It’s not going to be the same as xpath, as I’ve not got the time nor the inclination to write every single xpath rule and it would take far too long and I’m sure you could get paid for doing that! One added bonus is that the xpath selection can actually work on the DisplayObject list. The down side is you have to convert the DisplayObject list to the DOM. I may look at away to make a better adapter for this, but for now a help function should suffice.
You can view all of this at my github repo
It all began when I started reading a book about scala and Traits and wondering about how it would be possible to bring it to AS3. Mixin/Traits are away to provide multiple functionality to one or more subclasses, which becomes extremely powerful.
This is an example of how I would like my take of mixins to work in AS3. I’ve simply created a interface called IPosition, it will hold x and y positions.
1 2 3 4 5 6 7 8 9 10 11 12 13 | package org.osflash.mixins.support { public interface IPosition { function get x() : int; function set x(value : int) : void; function get y() : int; function set y(value : int) : void; } } |
Next we create an implementation that will for fill the interfaces.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | package org.osflash.mixins.support.impl { import org.osflash.mixins.support.IPosition; public final class PositionImpl implements IPosition { private var _x : int; private var _y : int; public function PositionImpl() { _x = 0; _y = 0; } public function get x() : int { return _x; } public function set x(value : int) : void { _x = value; } public function get y() : int { return _y; } public function set y(value : int) : void { _y = value; } } } |
Then finally we would need a implementation of the final subclass where all the mixins are provided. Notice I’ve also created a ISize, which is relatively the same as IPosition, but uses width and height rather than x and y.
1 2 3 4 5 6 | package org.osflash.mixins.support { public interface ISquare extends ISize, IPosition { } } |
I did a google search on traits and it sent me to a stackoverflow page, where Brian Heylin was asking the same question that I was thinking. This page lead to the working prototype he had created using AS Mock. In AS Mock it dynamically adds dependencies with alternative implementations, but it does this in a really clever way. Rather than overloading the prototype system, this injects bytecode at runtime. The great thing about doing this, is that you can design to interfaces, you get strong typing and most of all you get performance when the objects have been created.
So I created as3-mixins. It’s a separate project from the prototype because I wanted to be able to grow this into what I wanted. Get it whilst it’s hot, I’m going to working on a lot of things, but I’m currently looking at improving the performance of the creation of the bytecode at the moment. The project that actually handles the bytecode creation and runtime SWF generation is a project called flemit. I’ve only just started on refactoring this, but I’ve already started to rip out bits that are surplus to requirements. The end result might be that flemit gets consumed by as3-mixins. I’m hoping the two can be separate, but that depends if I make flemit so unusable to others that it actually makes no sense as another separate entity.
Hopefully I’m going to be able to work on this more, blog post about how the internals work. It’s actually relatively simple if a little long winded. And just so you know this is an example of how you would create a ISquare implementation.
1 2 3 4 5 6 7 8 9 10 | var mixin : IMixin = new Mixin(); mixin.add(IPosition, PositionImpl); mixin.add(ISize, SizeImpl); mixin.define(ISquare); mixin.generate().completedSignal.add(function(mixin:Mixin): void { var square : ISquare = mixin.create(ISquare); square.x = 5; trace("I have a square!"); }); |
Recently we’ve been working on a project for a limited device and have been concentrating on the performance aspects of the application. We use signals quite extensively in the project application (to good effect!), but it does intrigue me when you come to any stage of application development, that there are certain things you know about the application and what it does and when. When looking at Signals specifically these things are:
I’m more interested in number 2 for now. As the application is ironed out over time, it makes me wonder why we’ve got this extra functionality of allowing multiple listeners to registered to a Signal, when only one suffices. I’ve never been a fan of hooking on to direct callbacks, mainly for the reason that you don’t know what is coming through as the arguments and the added bonus of reading the documentation every time. I’m more interested in self documenting code, not that I’m against documentation! I just want to be able at a glance to understand what the code does (where possible of course).
I had thought about implementing a SingleSignal. The whole purpose of this is to provide away to have a one listener at a time callback. The SingleSignal had to satisfy the following:
It didn’t take me long to implement the functionality of the SingleSignal, as I already had the excellent work of Robert Penner and Joa Ebert to start from. The current implementation is in my github repo. I’ve also created some unit tests to help improve the robustness and prevent errors slipping through.
The last thing I did was verify the performance using the existing performance testing in the repo. Here are the results from a release Flash Player (10.1r85.3) on a mac running 10.6.2:
AddOncePerformance
Note: All tests min time was 0ms for all.
| DeluxeSignal | Signal | SingleSignal | |
|---|---|---|---|
| Frames per second (fps): | 49fps | 60fps | 60fps |
| Memory used: | 6mb | 6mb | 4mb |
| Max time: | 8ms | 7ms | 4ms |
RemovePerformance
Note: All tests ran at 60fps and the min time was 0ms for all.
| DeluxeSignal | Signal | SingleSignal | |
|---|---|---|---|
| Memory used: | 6mb | 6mb | 4mb |
| Max time: | 6ms | 6ms | 4ms |
There you have it. It’s up to 33% faster, which won’t be that noticiable, depends on how many addOnce or add and dispatches you’re doing. It also uses 2mb less, which is a good improvement overall. So if you know what the restrictions are of your application and you know you’re going to add one listener and you want to use less memory then a SingleSignal might be for you…
EDIT: slight refractor to make the article more concise.
Over the Christmas period I normally get a bit of free time, it’s not much but I can normally prototype a library/framework/demo which I’ve been thinking about at work. Well this Christmas is no different. I’ve moved my internal framework to Signals, removing the need for me to keep handles on my listeners. I’ve now off loaded it to Signals, which means there is less things to manage (management, optimisation, etc) when the concerned class shouldn’t care about these things. The great thing about Signals is the callback arguments are strongly typed, unfortunately we at ustwo™ use pureMVC as the framework of choice. The one problem we have with pureMVC is the fact that the event bus used is not strongly typed. In fact you pass anything in the notification body. This is fine if you’re the developer coding the item, but if you’re part of a large team, it becomes incredibly hard to keep track of what’s being sent where. Recently we’ve had the idea of using Signals for the event bus, so I took the time to implement this. I finished a working version, that sat on top of the pureMVC framework. It was great a signals mvc that work along side pureMVC event bus. You could even send notifications that hooked into the signals. Signals had priority over notifications when sending, so if you list the signal hooks it would be called before notifications every time. There was no way to change this, literally because the two event busses where completely polls apart.
So over Christmas I completely re-wrote the pureMVC into signalMVC which is nearly identical to pureMVC except for a few exceptions:
You can view all the code here – https://github.com/stickupkid/ui-signals-mvc