I Just came back from the great Haxe conference in Paris. Was a wonderful weekend with great hosts (SilexLabs) and a great community!

I am looking forward to get my hands dirty with Haxe.

Specially the macros seems to be an incredible power tool to bend the limits of a language.

But the most important feature of Haxe is the multi platform compilation.

Write your code in Haxe and compile it to:

• Flash (Bytecode as well as AS3 source code)
• JavaScript
• NekoVM
• PHP
• C++
• C#
• Java (soon)

Thanks to NME you can also compile code written against an API similar to the Flash API to:

• iOS
• Android
• webOS
• BlackBerry
• Windows
• Mac
• Linux

Of course the platform specific code (rendering, features, limitations) needs to be treated for every platform specifically. But luckily a lot of this effort is already done in some frameworks.

Sounds all great but of course the reality is a bit more complex.

The support for all platforms will have its limits with the inherent problems from these platforms and from the more and more growing variety of platforms.
And unfortunately the HTML inherent problems will not be disappearing magically when using Haxe ;-).

Peter Halacsy presented at the conference a problem which address a very basic problem of HTML. The problem with pixel exact layout of text/fonts.
There are cases where an exact layout is not necessary, but others where it is essential, for instance if you need to zoom into it, then any inaccuracy will be multiplied and would screw up the whole layout.
It seems that a proper solution to solve these problems is very hard to find and probably needs to come from the browser vendors.

But there are maybe some “hacky” solutions to get around this.

So I would like to share some ideas here.

The problem:
When the layout of some graphical element is derived from a text, it is not possible to get the exact pixel position of any text character.

A simple example would be to display a custom graphic which is dependent to the width of the text.
If in one browser the text is a few pixels wider then in another, you have a problem to display everything pixel perfect.

In Flash you would not have any problems with static text. You simply place the graphic the way that it looks perfect. There are luckily no differences in browsers with text layout (embedded fonts).
With dynamic text you get some help from TextLineMetrics and properties of the TextField. This works basically fine. Even if it is not absolutely accurate, it is for the most use cases good enough.

In HTML the font rendering is different in every browser/OS and you don’t get any help to read out the metrics. I am not a HTML/JS guy but I think there is no possibility to access the font metrics in HTML.

So for static text a solution could be to create a custom font for every different browser and embed this font into your webpage with CSS3.
Lets assume we want to use Arial but it does have a different layout in Firefox and Chrome. We could derive from Arial 2 versions, an Arial_Firefox and an Arial_Chrome font which have different font metrics, so they look exactly the same on screen.

To do this change of the font metrics by hand you need to display a character in both browsers and find out the differences to a reference font display (for instance in Flash embedded Arial). Then change the font metrics in the way that it fits exactly the position and size of the reference font. If the layout engines are treating all characters the same way, it should be fine to do this metrics tuning only with one character. Otherwise it is much more work to repeat this procedure with all characters, but it is doable as well.

Then export the Font and use it in HTML as embedded font.

This way you have 2 different fonts in 2 different browsers with different font metrics, but both should look exactly the same. Of course it is some boring work and it would be great to have a tool to do this for you.
If using free fonts there should be also no problems with license issues and once a font is deployed for all major browsers, it could be shared to the community, so the effort only needs to be done once for a certain font and browser.

We used such an approach when getting layout problems with the Chinese version of the Flex trading application of the company i am working for. The Arial Unicode has different font metrics then the standard Arial, so our layout got screwed up. By changing the font metrics we solved this problem.

I know this sounds a bit hacky, but HTML/Javascript is a hacky world. And if you have a look to other assets, like video or sound, it it quite normal (in HTML) to deploy and create different files/formats for different browsers. If the approach works fine and someone creates a tool, then the whole process would be automated and a new font for any browser could be easily added .

With this you should get pixel perfect and unified font rendering.

For dynamic text you might also want to know the pixel position of any character.

A font specific metrics table could help here.

You could create this table from the (browser specific) font metrics and from measuring the actual pixel size/position.

It could be done by taking one character with a huge font size, display it in the browser and measure the exact pixel size/position. If all behaves in a linear manner you should be able to interpolate any font size and use the factors derived from the font metrics and the pixel size to apply it to all other characters. If this does not deliver good results you need again do the procedure with all single characters, but as long as you does not need to support chinese fonts it should be doable. Again a task for a tool to do this boring work…

So once you have a table with the exact metrics for any character and font size for a specific font, you could calculate the exact position and size of any character in the text.

In reality this will probably become more complex and difficult (many kind of font format options…), but I think it should be possible to get more or less the same range of accuracy like in Flash.

Please note this is only a rough idea without testing the approaches. But I guess for the ones who are suffering from these problems in the HTML world, it could be worth to give it a try.

Why another Dependency Injection framework?

One thing nearly all DI frameworks have in common, is the use of reflection to obtain the extra information needed to inject the objects.
The downside of this approach is that reflection in general (and particularly in Flash) is pretty slow. This will probably not matter much for smaller application, but for large apps you can save several seconds of start-up time if you are not using reflection.

Unfortunately there is no solution out there beside a project from Joa Ebert, who is using a different approach. I wrote about this in another blog entry.

Another solution would be to use code generation.
With code generation you can inspect your code base at compile-time and write the information needed to a class.

I have added such a project to the nucleo library at github.

So how does it look like and how is it used?
Here are a few code snippets from the mojito example at github:

First we need the generated class for the constructor parameter keys. This will be created by an ant task, more about this later.

[code lang="actionscript3"]public class ConstructorParameters extends AConstructorParameters {
protected override function config():void {
constructorParameterKeys[BarProvider] = [IWaitress];
constructorParameterKeys[Bar] = [IWaitress];
constructorParameterKeys[Client] = ["theFewSpanishWords", IBar];
constructorParameterKeys[Waitress] = ["isInTheMood"];
}
}[/code]

You need to create the Config class which contains the mappings of the objects used for injection.
It passes an instance of the ConstructorParameters class to the AConfig super class.

[code lang="actionscript3"]public class MojitoConfig extends AConfig {

public function MojitoConfig() {
super(new ConstructorParameters());
}

override protected function setup():void {
mapInterface(IClient).toClass(Client).asSingleton();
mapParameterName("theFewSpanishWords").toInstance("¡Muchas gracias guapa!");
mapInterface(IBar).toProvider(BarProvider).asSingleton();
mapInterface(IWaitress).toClass(Waitress).asSingleton();
mapParameterName("isInTheMood").toInstance(true);
}
}[/code]

Then the setup can be done. After that you can access some root object and use this.

[code lang="actionscript3"]// first we need our Config. This is the place where our injection
// mappings are defined.
var config:MojitoConfig = new MojitoConfig();

// createInjector is a package level function used for convenience
// to get the injector
injector = createInjector(config);

// we take the root object out of the injector. The other objects will
// be injected just in time when they are needed.
var touristInBarcelona:IClient = injector.getObject(IClient);[/code]

Beside this, there are no traces left from the framework.

The Classes which gets created by the DI container are straight classes with constructor parameters totally unaware of the framework.
They don’t need any “Inject” Metadata tag. They does not know anything from the DI framework and how they get created. This is not their responsibility.

I think this is violated by the use of the Metadata at other DI frameworks. There the class has the information inside itself that a DI container is used for creating an instance of this class. I think this should be only the responsibility of the outer world using this class like a factory or the DI container.

But back to the project.

How does it work internally?

Basically the injection works pretty simple as a chained instantiation of all the dependent objects, starting with the first object requested from the injector:

[code lang="actionscript3"]var touristInBarcelona:IClient = injector.getObject(IClient);[/code]

This will create an instance of the class which is mapped to the key IClient. In our case it is the Client class.

[code lang="actionscript3"]mapInterface(IClient).toClass(Client).asSingleton();[/code]

For creating the Client class it looks up in the ConstructorParameters Class and get the information to create the 2 arguments needed there:
The instance mapped to “theFewSpanishWords” and an object of the class mapped with the key IBar.

[code lang="actionscript3"]constructorParameterKeys[Client] = ["theFewSpanishWords", IBar];[/code]

For creating an object of the Bar class it will need other objects as well, so the chain goes on like this until all objects needed are resolved.

The binding key can be an Instance, a Class or a String (named annotation).

For the named annotation I use a simple convention:
The parameter name must be the same as the annotation name in the Config class, like the “theFewSpanishWords” in the example. I think there is no reason not to use this simple and sensible convention and it makes life much easier and there is no need to add a Metadata for packing in this information.

I only support constructor injection as I prefer this style and it lets the class stay free of any Metadata.
Property or method injection could also be added but then you need to mark them with Metadata. As they would be invoked directly after the class is created i don’t see any reason why not to add these injected data to the constructor.

Now have a look to the code generation:

I used the as3-commons-jasblocks project which is using ANTLR. With this Java project you can read in your sources and it creates an object tree with all the elements of your code (abstract syntax tree). From this you can comfortably grab the constructor parameters and write (again with jasblocks) them into a class file.

I packed this into an ant task, as ant is pretty easy to use, good integrated into the IDEs and well known.
In the ant task you need to setup 2 parameters:

• The source directories (as comma seperated list)
• The target directory for the generated Class.

To automatically trigger the code generation for the ConstructorParameters Class before the compilation, you can use the built-in support for ant tasks of the IDE.

In FlashBuilder and IntelliJ there are easy ways to achieve this. So if the setup guarantees to always run the ant task before the compilation, the ConstructorParameters Class will be always up to date.

Here a quick description how to do this in FlashBuilder:

• Right-click in the project and open the project properties.
• Under Builder add a new Ant Builder before the Flex (compile) builder.
• Under Main point to the build file: eg. ${workspace_loc}/${project_name}/build/build.xml
• Under JRE: select separate JRE

That’s it.

In IntelliJ you need to set an “Execute On” event (“Before Compilation”) to the ant task target. Then it will be executed just before the compilation.

If you don’t like to use the code generation you can also write this class by yourself of course, you just have to maintain it and it violates the DRY principle.

A few words about code generation in general:

For some people code generation has a kind of bad smell and they don’t like to rely on it.

I think it is a very powerful tool to get around the limitations of the language and to outsource boiler plate code.
And if you use Flex you are using it anyway even if you are not aware of it. Flex use a lot of code generation behind the scenes (add the -keep compiler flag to see it) for creating ActionScript code out of MXML, css files, RPC or Data Binding.

I think for the coding experience and productivity it is not only the potential of the language which counts, but also the features of the tools (IDE) you are working with.
What would you (as a developer writing code) benefit much from a type system if you would write your code in a primitive text editor without any code completion or error highlighting (the old Flash IDE was like this, I cannot imagine anymore how to work that way).

With these tools you can get also over the shortcomings of a language.

So I think when you hit the limitations of the language or runtime, it is valid to go in this direction and add features to help you to write clean and fast code.

There are also some limitations and the project is at the moment just a kind of “proof of concept”. It is not bulletproof yet and not tested in a production environment!

So use it at your own risk. I added comments and TODOs in the Java source code about known issues.

One limitation is about external library (swc) files.

With the as3-commons-jasblocks project you can only inspect the code base you have as source code, but not the code compiled into libraries.

There are some solutions (like flagstone) to access this as well, but I have not added this yet.

With the providers (see docs and example code) you always can get around any problems with classes out of your control like 3rd party libraries.

Beside this I think DI should only be used in a limited scope of a project (module).

I used a small ant task after a compilation in Flash Builder. That is done pretty easily with the builder feature in eclipse.

Basically this worked fine, but sometimes it was not executing the ant task. The ant task was also not executing when started manually in the ant view. As this task was just for convenience I never found the time for investigating the problem further. Now for some other task where it is essential to get it run, I needed to find out why it seems to behave instable.

I am not totally sure if I found the real reason (there are some bug reports around this topic if you google for it), but at least I could manage it to make it working again. I suspect that when switching the workspace in Eclipse you need to set the ant home path newly (>preferences>ant>runtime). I did this when comparing the differences between a working Eclipse instance with a non working one. After changing the ant home path to the other Eclipse installations path (I use the ant directory inside the plugins directory of your Eclipse installation), it was working fine. After changing it back to the original path it was also working fine. So I assume that the ant home path got somehow corrupted when switching the workspace (or for some other reason), after setting it again, it seems to solve the problem.

Nasty stuff, but after a long search for the problem I am glad to get it (hopefully) running stable .

The first small nucleo.io project is out!

It is a scheduler framework for easily configuring tasks to be executed in sequence, parallel or based on their data dependencies.

The SequenceScheduler and ParallelScheduler are somehow self explaining. The 3 rd in the row needs maybe a few comments:

The DependencyManagedScheduler is used to automatically detect which tasks can be executed and which one needs to wait, until the data required in this task has been written by any other task. It simply checks if the data needed is available, and if so, it starts the task. Every time a task has completed all remaining tasks will be evaluated again if they are ready to run.

I used a special style of model for storing and exchanging the data between the tasks. There is a Dictionary holding the data objects. As key you can use any type of object, so you can use an Interface or a Class as well as a String as Dictionary key. There is a kind of registration mechanism, and the access is handled over a read and write method. With this style you get the benefits of a type safe access (if you use an Interface or Class as key) to the properties. The alternative solution would have been to use always a string as property name. Then you could use a simple model with public properties.

There are examples included in the project so it is maybe easier to checkout the code and read the comments there.

A typical use case could be a startup process scheduler, where many different synchronous and asynchronous tasks are executed. To find out the optimized and correct order can be tricky and hard to maintain (when new tasks are added). The scheduler helps to give a better overview with the MXML declaration of the tasks and schedulers. The DependencyManagedScheduler is taking care of the correct and optimized execution order based on the required data of the tasks.

Here is a small example how a MXML style scheduler configuration would look like for a Mojito mix recipe:

[code lang="actionscript3"]
    

        
        
            
            
                
                
                
            
        

        
        
            
            
            
            
            
            
        

    
[/code]

Joa Ebert has written a Dependency Injection framework as part of his funk-as3 library.

Basically his API is orientated on Google Guice and does not use reflection, which is great, because reflection is pretty expensive regarding performance.

And Performance matters. We reduced the start-up time of our application from 8 seconds to 3 seconds just by removing Spring Actionscript and using a pure factory-based DI which does not use reflection and has no performance overhead. The code was also better to manage then the XML based solution of Spring Actionscript. Other frameworks which are more in the Guice-style would be nice to use but have the same negative impact on performance, so it was a No-Go for us. The drawback of our factory-based solution compared to Guice-style frameworks was, that it was not so easy and nice to use and more boilerplate code has to be written.

When stumbling over Joa Eberts DI framework I first wanted to use it directly as 3rd party library but I got some problems with the compiled swc. So I started to build my own small DI framework based on previous ideas in this direction and refined with some of his ideas and a similar API style. Unfortunately I cannot share the code but I can give the basic ideas.

So let’s get started:

First you need to setup the Locator. It’s a one-liner and is done like this:

[code lang="actionscript3"]myLocator = Locator.getLocator("myScope", myContext);
[/code]

The explanation for this will follow later.

Further you have a Context Class (the Module in Guice) where you define the bindings of what you want to get injected for a special Interface, Class or named annotation.

Additionally you define if the object should be only created once (asSingleton) or every time newly.

[code lang="actionscript3"]// Interface to Class
bind(ITestInterface).to(TestImpl).asSingleton();
 // String annotation to Class
bind("myList").to(ArrayCollection);
// Interface to instance
bind(IResourceManager).to(resourceManager).asSingleton();
[/code]

To support also some special classes which are outside of your control (3rd party) you can use a Provider to get an instance created in a custom fashion in the Providers getObject() method.

[code lang="actionscript3"]// String annotation to Provider
bind("myServcice").to(RemoteObjectServiceProvider).asSingleton();
[/code]

When you want to inject these objects somewhere in your Classes, just write inject(bindingKey) to obtain the instance defined in the Context.

But when not using reflection we are facing some problems.

Without reflection you don’t have information at run-time about the constructor arguments. This is a problem when creating the classes. One solution to prevent this problem is to use only constructors without arguments.

Instead of the classical way like here:

[code lang="actionscript3"]public function TestClass(testInstance:ITestInterface) {
    this.testInstance = testInstance;
}[/code]

We assign the mandatory members directly in the constructors body with the inject call.

[code lang="actionscript3"]public function TestClass() {
    testInstance = inject(ITestInterface);
} [/code]

Another solution would be to register the Class with it’s parameters annotations explicitly to the framework, so the information what needs to be injected when creating this Class is available.

Something like this (you can use a static function call as it is specific to the class, so it could be located directly above the Constructor):

[code lang="actionscript3"]registerClass(TestClass).withParams([ ITestInterface, "myList" ]);
public function TestClass(testInstance:ITestInterface,
                           myList:ArrayCollection) {
    this.testInstance = testInstance;
    this.myList = myList;
}[/code]

This would have the drawback that you need to maintain changes in the parameters in 2 places, and additional code needs to be written.

My preferred solution without constructor arguments has the drawback that the mandatory parameters are not visible in the signature of the constructor.
So both has some small penalties, but the good thing is it has zero overhead performance-wise and it is as easy to use like the classic Guice style injection.

Of course you can use the injection in properties or methods as well. But i prefer the constructor injection for all mandatory dependencies, so it’s more clear what a class needs initially.

So how does it work:

Technically it is not real injection but more like the Locator pattern.
You have a Dictionary where you define the mappings of keys (Interface, Class or named annotation as String) to instances, Classes or Providers.

What happened when calling the inject() method inside the Locator?
It looks up for the value stored for the given key.
That can be:

• An instance, so return it.
• A Class, so create an instance of this Class and return it.
• A Provider. Create an instance of the Provider and call the getObject() method to get back an instance which is created in a customized way and return this instance.

The optional asSingleton() call is handling the behavior if the object is cached or not.

So why not use the Locator pattern?

When using the Locator  pattern you need the instance of the Locator. You can pass the Locator in the constructor to not rely on a static dependency inside your class.
That would be fine, but there is a more elegant way.

You can use a package level function (native Flash Functions like getTimer() or trace() are using this technique), so you can call directly the function without reference to the Locator. Inside the function it forwards the call to the package level property which got assigned the reference to the Locator from the setup. The “dependency” is only the package in which these 2 files are defined. If you follow a clear architectural structure this results in the positive side effect, that your Locator is used only in the correct scope and protects from cross-scope misuse.

Note that the file name must be the same like the Function or Property names (inject.as, myInjector.as) and only one Function/Property is allowed.
Here are code examples like these 2 files could look like:

[code lang="actionscript3"]package org.yourDomain.yourProject {
	public function inject(bindingKey:Object):Object {
		return myInjector.inject(bindingKey);
	}
}[/code]

[code lang="actionscript3"]package org.yourDomain.yourProject {
	import org.yourDomain.Injector;
	public var myInjector:Injector;
}[/code]

The myLocator property gets the concrete Locator instance assigned at the setup.

[code lang="actionscript3"]myLocator = Locator.getLocator("myScope", myContext);[/code]

Scopes:

When having a single project you probably don’t need to use different scopes, but this becomes important for larger projects. As different projects are normally using different root packages, the projects root package would be a perfect candidate for the scope key.
When you add the package level property and function file into these packages, you have in every project the access to the right scope of your Locator (need to import them where used).

The Locator implementation is pretty straight forward.

It does the management of the scopes as well as the mapping and handling (creation) of the instances when the inject() is called. I used the fluent interface style but you could implement the Binding also with a plain function and parameters.

Some final discussion:

So you may ask that fetching dependencies is not the same like injecting them, and classes should get the dependencies from outside instead of fetching them from inside.

Yes that is basically true.
But why it is better to get it injected?

Because normally to fetch something you need a reference to the container from where you get it. In classical ServiceLocator patterns it is mostly a Singleton.

[code lang="actionscript3"]ServiceLocator.getInstance().getObject("myObject");[/code]

Better would be to inject the ServiceLocator in the constructor, so the provider of your dependencies is free configurable and you don’t need to change your class if you want to use a different implementation of the provider.

It is not about getting or fetching, it it about to keep the class clean from static dependencies.

With the solution using package level functions it is less code needed to be written and has the benefit to implement a scope mechanism which can serve as protection.

Maybe it depends on the architecture and structure of the project if this approach makes sense. Another solution would be to pass the scope to the Constructor of the Class and lookup for the Locator inside the constructor with the scope key. Or simply pass the already resolved Locator instance typed as Interface to the Constructor.

So using it a bit different, the good old ServiceLocator mimics the fancy Guice-style Dependency Injection without really hurting, but saving a lot of performance.

With the heavily discussed announcement from Adobe about their commitment to Flex they crossed the line were it seems very likely that the Flash platform will not survive in the long term.

What Steve Jobs started, seems to be completed by Adobe themself.

This is somehow weird and bizarre because they own a technology which was incredible successful the last 12 years and is still the best solution for many kinds of Rich Internet Applications.

To just name a few reasons why I see Flash as such a strong platform:

• Nearly multi-platform technology. Ubiquitous penetration of the browser plugin + AIR (well I know: Steve Jobs left his marks….)
• Good development environment (language, tools, community, Flex framework…)
• Good performance and security model
• Easy and cheap to deliver good looking multimedia enabled user experience

Flash has set new standards and drove the internet forward (ok, I know ads are done with Flash as well…). Animation, multimedia, rich user interaction and the possibility to build desktop-like applications running in the browser are with Flash not a big deal. The rise of what Adobe coined Rich Internet Applications (RIA), were mainly driven by Flash/Flex.

I am not saying Flash is the best platform, and there are many things on my wish list and stuff to complain about. I also would prefer an open source technology following standards.

From a technology point of view there are many better solutions, like Director or the Java plugin were in the past much better then Flash but did not survive because of the low plugin penetration and the odd installation process. Flash was somehow the star for a long time and left the others behind, probably mainly because of the ease to install the plugin which leads to the high penetration rate of >98%. With Flex Adobe managed it to deliver a pretty good GUI framework and also attracted developers from more traditional languages like Java or C#.

The competitors like Silverlight, JavaFX or now HTML5 are seeming somehow (in the best case) like a copy and did not shine with much innovation.

Of course Flash is used in many places where it does not make sense, like for video or more complex web page navigation combined with HTML pages. So it is good that the modern browsers are able now to do this stuff directly without the indirection of a plugin. And of course it would be much better to have a browser being capable doing all kind of stuff directly which is done currently in Flash or with other plugins.

But why has this not happened in the last 15 years since browsers are prominent actors in the IT world?

Probably the biggest advantage of Flash was, that it bypassed the nasty problems with the incompatibility of the browsers and the slowness of innovation with the trick of using the plugin architecture to deliver a standard runtime for any browser and OS.

Like Java Flash can proudly proclaim: Write once, run everywhere!

And it looked great, was fast, was multimedia aware and made fun to play around. Concentrate the work on the application or game and not on dealing with browser compatibility problems.

With Actionscript (2,3) they set the foundation for a robust development environment. When you read about features of Googles Dart or some of Scala it somehow seems similar to that hybrid and well cooked mixture of Java and dynamic language features.

On this foundation it was possible to build large scale applications which were previously build as Java or C# desktop apps.

Why did companies move from the mature software development standards to something new and risky like Flash/Flex?

Because the apps looked good just out of the box, it was easy to develop and customize, multimedia was just a natural ingredient and it was more suitable for agile development models (rapid prototyping). At the end the costs were much lower as with a traditional software development process.

I think that was the main driver why RIAs became a success story. I think often the real reasons are pretty trivial.

Of course it is a benefit to have a browser based application available anywhere and the management of updates is much easier to handle. But the nature of RIAs is different to web pages. With an application you have a closer relation and there is no real barrier to install the app if it shows some real benefit to you. The success of mobile apps is proving that users have no problem to install an app they are using on a regular basis. If the way how to install it is easy, secure and free, the user does not mind the installation and even prefer the app model over the browser model (If you use twitter on your mobile, you use the app not the browser, right?).

What I want to say with this:

I do not believe the rise and success of RIAs came from the fact that the application is available on any computer via a browser, but more from other factors.

• The browser is recognized as trusted environment (no problems with security issues)
• The development costs are lower
• The maintenance costs are lower
• The User experience is often better (looks better)

With the decline of Flash/Flex I do not see yet any alternative technology which has the strength and market power of Flash.

The main problem with HTML5 I see in the politically motivated fragmentation of the browsers.

That seems even worse then 10 years ago. Back there was Microsoft against the rest. Now we have Google against Apple against Microsoft ignoring the rest.

They are all following totally different business targets with their browser concepts and I do not see any reasons why they should work better together in the future.

For me the problem with HTML5 is that you have to write code handling the differences of the most important browsers, so the main features works on all of them. Then you need to support some other browsers with a reduced feature set. And you need to test all versions in a very fast changing environment. That all comes with a poor language (Javascript is like Actionscript 1 12 years ago), a poor development environment and poor performance. I do not see any technological progress with this HTML5 hype. Flash 5 in 2000 was already more advanced (is the matching version number a coincidence?).

So in my opinion the only solution will be a technology which strongly supports multi-platform compilation.

Unity3D does this, haXe is doing this and openLaszlo did this partly already since 2004, as well as some other interesting moves in this direction (Joa Ebert). Adobe seemed to missed this trend.

The developer should not care about the output platform and concentrate to build applications without hacking to make it run in different environments.

Isn’t that the evolution of computer languages?

Machine code -> assembly -> C -> VM languages -> ?

Liberate the developer from the low level technical implementation and let him concentrate to the domain he is modeling in software. Writing hacks to make an application run on different browsers is against this evolution.

Of course writing multi-platform apps comes with some inherent problems. There are different capabilities, sizes, contexts and limitations to deal with, but they come naturally with the platforms and are not politically motivated hurdles created artificially by browser vendors.

I think the right candidate must be able to deliver an application for all major target platform without dealing with significant adoption problems and provide a modern, state of the art development environment (language, tools,…):

• Desktop (Win, Mac, Linux)
• Mobile/Tablet (Android, iOs)
• Web (Flash, HTML5)
• And maybe also Consoles or even Set-top boxes

This will define a new situation for the RIAs:

Assume you can develop an application for any platform, getting results which are close to native apps for this platform.

What are the benefits of RIAs when the Desktop app is much faster and has more capabilities?

Of course sometimes it makes sense to have the app, maybe as light or demo version, in the web for giving a lower entry barrier or to get a higher visibility. But in general the choice for the main platform will be much more derived from the nature and usage of the app then from external factors.

The stuff I use regularly I want to have as desktop or tablet app to get the best performance, security and feature set. If I need it to be mobile I install it as mobile app. Only the casual stuff will be a target candidate for the browser.

I do not think the browser will have the same importance in future like now (I know I am in opposition to Google with this). With a multi-platform compiler you can choose which platform matches best to your needs, and the browser will be reduced to that what it can do best. Displaying web pages and not imitating desktop applications.

I think sometimes ones success is more driven by the weakness of the others. Again pretty trial and no hot slogan for driving a hype.

Flash was successful because the browser vendors did (and still do) such a bad job in making a common standard and to being innovative.

The browser has been so successful because the OS vendors did a real bad job to not providing an easy and secure installation environment (the reason for Apples app store success). As well as not providing a native platform for cheap and easy software development (it is much easier to start with Flash or HTML then to write C code) and ignoring the importance and integration of the internet.

I guess in future there will be a multi-platform paradigm with focus on a main platform which makes most sense for the specific domain. The Desktop applications are looking somehow old as they have missed many important trends and can learn a lot from some successful RIAs. The RIAs which are imitating desktop apps will loose ground as with a multi-platform compiler there is no much motivation anymore not to deliver the better target platform.

Maybe I am all wrong with this. I know that I am against the current trends with these opinions, but i simply cannot see any real progress with this HTML5 hype and feel that there is a real need for something new.

Jack Viers has posted a great performance comparision between Flex 3 to Flex 4 components.

Unfortunately the Flex 4 components suffer from big performance decrease (163% slower). But just read the article it is very profound discussed there.

Have you ever tried to use usePhasedInstantiation? It is not so easy, as you will see…

What is usePhasedInstantiation?
This is a property at the LayoutManager which is used to decide if the methods for the 3 Lifecycle phases (validateProperties, validateSize and validateDisplayList) are deferred with 3 (half-)frames or if they are all executed synchronously in one Frame. So if it is set to true (default state) at an EnterFrame event validateProperties() is called, on the next Render event validateSize() and on the next EnterFrame event validateDisplayList().

As I discussed in a previous blog entry, I was wondering why Flex is using a deferred asynchronous execution model. I tried to find out what happens if you change this property.

First I tracked the executed frames and checked out how it behaves with different use cases of Flex applications:
With a simply Flex application with a few random components it was like expected: 1 Frame delay for the whole cycle (3 half frames).
Then i added much more components and also some really heavy weight components like DataGrid, DateChooser or ColorPicker.
Here it took 3 frames, so it seems that there is some code in some of these Flex components which causes additional invalidation cycles (for instance if you call a invalidateProperties method inside of a creationComplete handler you will trigger a new cycle).
At last I measured with our Spreadbetting application at CMC Markets. Here it was a bit more difficult because there was more complex stuff going on. I measured the executed frames and time it takes until the application was idle in the login state and waiting for user input. We will compare the results later.

I tried to investigate to change this property to see and measure the effects on performance.
But unfortunately it didn´t had any effect. After stepping into the SDK sources, i found the reason:
It is set to true in the Containers createComponentFromDescriptor method which is called for adding the MXML children inside a Container. So it doesn´t help much if you set it to false at any place in the Application, because it will be overwritten by the adding of the first child at any Container class (Canvas, HBox,…).
I am not sure if there is a clean solution how to change this default behavior, but for my test case it was enough to simply ignore the value passed into the setter method in the LayoutManager and set the value to false by default.
But to change the LayoutManager is not so easy. It is setup in the SystemManager and to override this implementation you need to change the SystemManager which can be only defined in an own Application class.

Here are the steps how to do this:

In your MXML Application you use a custom Application class:

[code lang="actionscript3"]
MyApplication defines the custom SystemManager as factoryClass in the "Frame" metadata tag:
[code lang="actionscript3"][Frame(factoryClass="com.test.bootstrap.MySystemManager")]
public class MyApplication extends Application
[/code]
MySystemManager overrides the docFrameHandler method and set MyLayoutManager as implementation class for the ILayoutManager:
[code lang="actionscript3"]public class MySystemManager extends SystemManager {
override mx_internal function docFrameHandler(event:Event = null):void {
  Singleton.registerClass("mx.managers::ILayoutManager",
    Class(getDefinitionByName("com.test.bootstrap::MyLayoutManager")));
  super.mx_internal::docFrameHandler(event);
}
[/code]
In  MyLayoutManager you can bypass the assignment of the usePhasedInstantiation property:
[code lang="actionscript3"]public function set usePhasedInstantiation(value:Boolean):void {
  // for simple testing purpose:
  // simply ignore the values coming from Container and
  // set it by default to false
  value = false;

  if (_usePhasedInstantiation != value) {
    _usePhasedInstantiation=value;
    var sm:ISystemManager=SystemManagerGlobals.topLevelSystemManagers[0];
    var stage:Stage=SystemManagerGlobals.topLevelSystemManagers[0].stage;
    if (stage) {
      if (value) {
        originalFrameRate=stage.frameRate;
        stage.frameRate=1000;
      } else {
        stage.frameRate=originalFrameRate;
      }
    }
  }
}
[/code]
Another interesting detail is that Flex is setting the framerate to 1000 while these phased instantiation is active to speed up the execution (but this could also lead to strange side effects with too fast running animations like we have in our application with a pre-loader animation).
So lets do the tests again with this new setting:

The simple setup showed that all is executed inside of one frame and the time measured showed a faster startup, but the difference was pretty small.

The setup with the more complex Flex components gave a bigger difference in time and of course all was executed in one frame again.

In our CMC application the startup was 400ms faster (2300ms vs. 2700ms).

So 15% faster startup with usePhasedInstantiation set to false in our application startup.
To be honest, I was expecting more. Maybe it is related to the fact that at our application startup (until the login screen) there are not many components created.

I also tried to compare the 2 versions after the user has logged in and under heavy load with a lot of modules and windows open. I could not see a distinct difference but that was probably because of the complexity in this setup caused by a lot of network events.

At least i could not see any problems with rendering. The application was not freezing in any state, so the reason why usePhasedInstantiation was introduced to make the startup more fluidly, does not show any effect in our application.
What is the conclusion?

It does not improve the startup performance much if this property is changed (15% in our application), but I could imagine, when using a lot of components created all at once at startup time, the difference could be stronger. Maybe there could also be problems with freezing the rendering when setting the flag to false.
Even the result is for our use-case not much improvement, it was interesting to see how it is implemented, and to show that Flex is working fine without the deferred lifecycle as well. Also the technique how to exchange the SystemManager and how the implementation for a LayoutManager is configured, was an interesting learning.
			

Great news!: Unity will support the Flash platform in future!
Wow that is really an exciting move!

I have had recently a look to Unity in search for alternatives to Flash, and was wondering why they are not supporting the Flash Player. They already supports a lot of different platforms, but Flash was missing. I thought the technical limitations and differences would be a too hard barrier.

But now they released the news that they are working on the support for exporting Unity projects to the Flash platform as well as to Android, IPhone (and the rest of the I… derivates), XBox, Mac/PC desktop apps and their Unity Web Player (Linux Player is in development). It is becoming a real tough multi-platform tool! This could have a deep impact, as Unity seems from technological point of view much more advanced then Flash and the main barrier for using it in the web, was the low player penetration of the Unity Web Player. So it was locked to the special cases where the installation of a new plugin is no problem for users, but unfortunately for 90% of the mainstream clients and projects this is a no go. But with this strategy they will get in one move the support of the 99% penetration of the flash player (ok, with the latest player version that is not correct, but people don´t care so much about an update of the Flash Player then about a new installation of an unknown plugin).
And Adobe is getting a real strong competitor, so hopefully they are forced to pay more attention to performance and development environment. The current Flashbuilder is compared to the tools available for Java or .NET not very competitive, to express it friendly. I have not worked with Unity yet, but will use the next opportunity to try it out.

I am also wondering how much they can cover outside the classical 3D world? Flash has started as a pure animation tool and has become a main player for web application development. I bet the inventors didn´t expect this. So why should not Unity become a tool also for classical applications, 3D comes free if needed, and it seems that 3D will become more and more an intrinsic part of up to date software. 3D-TV sets and Mobiles are currently the hot thing and I think it´s only a question of (hopefully not too much) time, until 3D displays are common also at desktops. 3D content will be the missing link then.

Unity is just ready to take off!

Looking forward also to the new Flash Player (Molehill) which brings GPU-accelerated 3D to the Flash platform.

After working 10 years with Flash and 3 years with Flex I am still not convinced that the Flex Life Cycle is necessary.

I discussed this topic already with many developers but nobody could really give me a satisfying answer.
So I spread out my thoughts now to the public in the hope to get some valuable feedback.

Of course I am familiar with the concept of the Flex Life Cycle and the “elastic racetrack” behavior of the Flash Player.

The reason why I am not a friend of this concept is because it introduces an asynchronous code execution where a synchronous code execution would be much easier and faster.

In all my ActionScript based projects it was never necessary to use this pattern and defer code execution to another frame (or Render Event).
At bwin we have built a similar application as the current Flex-based Live Betting application previously in AS2, with a lot of complex components and auto layout containers, without running into any serious problems.
And to be honest the performance of the AS2 project felt somehow the same as the Flex version. But AS3 is about 10 times faster (of course that´s a bit too simple said and we did not measure the difference, but I am not the only one complaining about poor Flex Performance).

So isn´t it valid to question the concepts Flex is based on?

I am sure the architects at Adobe have had good reasons why they decided to introduce this pattern.
In the Docs and Blogosphere one can find several papers about it, but none of these explanations satisfied me, and some are not telling the full truth (that code execution is deferred to another frame).

So I try to discuss some assumptions for possible reasons:

• Avoid Performance bottlenecks
• Keep the Frame-rendering fluidly
• Avoid Performance penalty from unintended repeated method (setter) calls
• Pattern for separating different concerns
• Problems with reading out the measurements of DisplayObjects before they are rendered on screen
• Problems with complex execution flow from auto-layout containers code

So let me add my thought to these points:
Avoid Performance bottlenecks

That was my first assumption when I started with Flex, that this pattern is used to avoid performance bottlenecks. First I thought there is a hidden mechanism for detecting code execution which is running too long and delay this execution to the next frame. After checking out the SDK code I found out that it is simply delaying the 3 phases to 3 “half-frames” (Render Events and Enter Frame Events). So if you have really heavy code your player is still freezing up for a certain time and the Life Cycle does not give you any support for solving this problem.

That leads to the next argument:
Keep the Frame-rendering fluidly

Delaying the render code to the next frame helps the Flash Player running more smoothly and fluidly. That is basically true, but in my opinion 90% of the time the Life Cycle is wasting performance. For me it is a bad trade to get maybe at startup time some more fluidly running pre-loader animation but startup time takes much longer.

Why the Life Cycle is wasting Performance?
Because code which normally would be executed in one frame is now executed over 2 frames (or more).

There is another related issue with performance:
Avoid Performance penalty from unintended repeated method (setter) calls

Assume that in a large project it could be hard to control the execution flow so that it could happen that setting a text or layout property to a component is not only applied once but unintended multiple times.
For this scenario the Life Cycle helps because the call to the setter of the property is relatively cheap, so if the setter is called 10 times instead of once it will not hurt much. Then at commitProperties the property is only applied once to the component.
Again some weird scenarios with multiple invocations of commitProperties will not hurt much because the applying of the property to the component should be protected by a “changed” flag (see best practice with the Flex Life Cycle).
Also if you need for layout code some measurements the pattern helps to avoid unnecessary and repeated code executions.
BUT – is poorly written code really the reason why this pattern was introduced? It is true that it gives you some kind of fault tolerance, performance-wise. I guess this argument should not count in professional software development, and in fact it is dangerous because it could hide some deeper problems. If your setters are called more then once, why not look for the reason and clean it up?
I know in complex situations this could be sometimes hard, and under real life circumstances and time pressure you have to deal with something like this. But it should not count as a criteria for such a basic framework design decision.

I made also some measurements to check out the performance penalties for repeatedly called setters:

With 100 000 iterations applying a changing text to a TextField (in a AS3 project) I got these results:

1. Case:
Setting the text property to a variable in a loop and then applying the already stored text to the TextField again in a loop:

[code lang="actionscript3"]setText(): 119ms
applyStoredText(): 481ms
[/code]

In contrast to applying the property directly to the TextField:

[code lang="actionscript3"]
setAndApplyText(): 2879ms
[/code]

So you can see it is much slower in the 2. Case, so the Life Cycle really helps here, because it only applies the last stored property and not the changing values in between. But again – setting multiple times unnecessary property values is another problem.

The same test with setting the x position does not deliver such a big difference, in fact it is nearly the same time consumed (40+52 vs. 114)

[code lang="actionscript3"]setXPos(): 40ms
applyStoredXPos(): 52ms
setAndApplyXPos(): 114ms
[/code]

Let´s continue with the next point:
Pattern for separating different concerns

To have a kind of pattern which separates different concerns is basically a cool thing. So you have your code block for setting properties, another method where the properties are applied to the component, a method where the measurement is defined and another one for the layout code.

I have no really argument against this pattern, but I don´t know why it is necessary to defer some code of these phases to the next Frame. The execution of the Life Cycle methods could have been triggered also at the Render Event, then there would not have been any delay to another frame, even it still would add this nasty asynchrony.

So this pattern could make development easier but introduce asynchronous behavior where we lived in a beautiful synchronous Flash world before. In my opinion: Not a good trade.

What else?
Problems with reading out the measurements of DisplayObjects before they are rendered on screen

Remembering back to some of my Flash projects I have had sometimes strange problems with TextFields and measurement when setting text and using autosize. But I could not reproduce these problems in a test case anymore. So I am not sure if that was caused by some other stuff or maybe by differences in some older Flash Player versions? But at least in my situations these problems could always be solved without deferring code to another Frame. But at this point I am not sure if there are certain use cases where you cannot read out the size of a DisplayObject (TextField) before it is actually rendered to the screen. If there are such cases this would be a valid argument, but then I am wondering why this could not be solved on the Flash Player level instead of solving this problem at a Framework level.

And my last point:
Problems with complex execution flow from auto-layout containers code

I can imagine that complex situations with nested auto layout containers could be sometimes really tricky to handle. To avoid recursions or unnecessary calls for any possible situation in a generic framework is a tough challenge.

But also in complex situations it is a deterministic behavior, so it should be possible to solve this without the Life Cycle pattern as well. From my experience there was no problems with auto layout containers, but of course in normal project development you have limited use cases and we were not forced to deal with all the possible use cases, like Flex has to do as a generic framework.

So finally I don´t have any idea for the real reason why Adobe has introduced the Life Cycle.
Maybe it seemed that it could help solving a lot of tricky problems (auto layout containers, mixing MXML with AS code,…) and was considered as a good pattern to make development easier. Maybe the fact that Flash has a strong support for Event driven programming and the Flash developers are already used to handle this asynchrony, led to this decision?
Maybe is was a strategic decision to make Flex easier for new developers without Flash background, who were not familiar with the Flash Players frame-based execution model?

I don´t know. I really would appreciate if someone from the Flex Team could illuminate this topic.

I just have made the experience that many things where much more transparent, cleaner and faster in pure ActionScript then in Flex, and i think the Life Cycle is one of the reasons for that.
I really like the API of Flex but I am wondering why Adobe don´t give more attention to performance, specially for large scale applications.

Any comments or insights are highly appreciated!

P.S.: Just found an interesting post related to this. I 100% agree what Paul Taylor says about UIComponent, but that is another story. Ever heard about Reflex? Sounds pretty promising!