ActionScript & Android

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:

• ECMA 4 – I’m guessing Adobe are still in the spoils of the ECMA fallout, where Adobe aren’t 100% sure what to do. If that’s not the case, this is what is perceived from the dwindling hordes of developers. Is Adobe following ECMA Harmony or are they doing their own thing? The latest FP11 doesn’t look like it’s done any sort of move in any direction. The great rival that has appeared in the last couple of years (Javascript) seems to moving lightening fast, ok maybe they’re not all singing from the same hymn sheet, but at least they’re moving when it’s concerning the language (probably excluding MS here somewhat). Things that look appealing to me from a Javascript point of view or even original ECMA 4 document, which I believe should be in FP11. Even if there is no official ECMA 4 now, at least have the balls to follow it through!
  
  • Union types and the set of predefined union types
  • Type definitions
  • Subtypes
  • “like”
  • yield
  • let
  • Iterators
  • Map
• Enums – Why can ActionScript 3 not get enums, they’re basic simplicity that help reduce boiler plate.
• Abstract Classes – With all the functionality that ActionScript 3 is getting, it becomes a necessity to have more help from a language and I consider Abstract Classes part of that. Why can’t the compiler tell me I should override a class if I mark something as Abstract, hell it moans about something when I don’t override something which I should, it’s not like a massive leap?
• Private constructors – Why did we remove these again?
• Generics – Generics in ActionScript 3 is just decent, not good and not excellent, it’s just decent. It’s like they went, “we want to implement generics, but we don’t have the time. I know, lets implement it in a half arsed way!”
• Const – How about const keyword, is it implemented? Who knows? It’s not implemented in the Flash IDE, but is implemented the Flex SDK compiler, but you can create a swc file from the Flex SDK and use it in the Flash IDE? How have they managed to do this without changing the player or the Flash IDE? Well it turns out they only do a compile time (better than not I suppose!) and once the check is done, they use the var AVM2 Bytecode instead.
• Flex compiler – Why oh why is the Flex compiler aka mxmlc and compc two separate entities and why oh why do they not implement some really basic rules of optimisations.
  
  • Inlining
  • Constant propagation
  • Tail recursive optimistations

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.

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.

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!");
                                        });

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:

• Signal event bus – you make your interests in the mediator using IHooks, these are strongly typed classes.
• Removed singletons – these have become a big hinderance in the past. This has the consequence of removing the multicore code base.

You can view all the code here – https://github.com/stickupkid/ui-signals-mvc

I’ve been playing with Robert Penners Signals for a new project, I find it’s amazing for direct component to component communication. The only issue I’ve had is that I end up having quite a few signals hanging out as public class variables. I can end up with tight coupling of components if there are a lot of signals. That’s a big issue if you want to swap out some functionality or change some way that happens. I personally think that we could be exposing to much, we should be encapsulating the Signals and letting the author of the class let you know what to subscribe to and not let you subscribe to everything or guess! Knowing which ones to subscribe to get a feature to work or not is a bit of a pain. So I just hooked it up to the old observable pattern (I know Signals follows the observable pattern itself, but the class you created the signals on doesn’t, it just instantiates variables that are observable.)
You get all the benefits of Signals and the benefits of encapsulation to boot!

1
2
3
4
5
6
7
8
9
10
11

public final class Main
{
     private const signal : Signal = new Signal(Boolean);
 
     public function addObserver(observer : IMainObserver) : void
     {
          signal.add(observer.watch);
     }
 
     // note : add other observer methods
}

And for the interface, couldn’t be more simple.

1
2
3
4

public interface IMainObserver
{
     function watch(value : Boolean) : void;
}

That’s it! A quick snippet that can grow, you could rename addObserver to something that you want to add multiple signals to i.e. addKeyboardObserver, which could listen to both key down and key up.