Børre Wessel mentions this approach in his Flex in the enterprise talk and his proposed solution of having a separate set of models handling the communication with the server and storing the retrieved data is great. We use this approach on my current project and it has made our architecture better and more robust for changes in the UI. It also makes the Presentation Model classes easier to understand as they end up having just one responsibility: handling the state of UI components.

In my current application the Server Model classes get composed with classes extending Remote Object which makes the class responsible for retrieval and storage of server data. The Server Model classes end up looking a lot like Data Access Objects, in the sense that they have methods for retrieval of data and handle all communication with the data source.

This post is also available as a Adobe Cookbook recipe

Maintaining your rule set is easy with the Adobe FlexPMD Ruleset creator which provides a nice view for enabling / disabling rules for your project. After all, it is not all rules which are just as important to everyone and having an application which makes this easier.

The Flex PMD Eclipse plugin enables you to introduce quality control as a natural part of your work flow. It can be run as part of your build process or as a separate command later. You can identify code smells or potential duplication of code due to cutting and pasting of code blocks using FlexCPD. FlexPMD is not for Eclipse only, but can be executed from Ant, Maven, TextMate, Flash Develop.

You can also use FlexPMD as part of you continuous integration process and the wiki shows samples of how it can be used with the Java CI server Hudson.

Props goes out to Adobe for giving this project attention and hopefully it will help the Flex community to deliver code of even better quality than before.

Flash Player Debug version

I don’t know why this is so damn hard, but for me (and according to Google quite a few other people as well) this was a hard job. First off you need to download the debug version. Then some posts say that all you need is to override the libflashplayer.so file in ~/mozilla/plugins/. For me however this only resulted in the debug version being there the first time I launch my Flex app, but only once. After the first launch it was back to the standard version. Not beeing to keen on figuring why this funky behaviour happened I took the bull by the horn and ran a grep for all occurences of libflashplayer.so and replaced it with the debug version. Now I have the debug version every time

No events? No import flash.*?

When setting up a project you may get some issues with classes from the flash.* packages. Resulting in the inability to say stuff like addEventListener, which is something you really want to be able to do. You can Google for the topic and find some interesting posts. To get around it you just remove the one set up by the SDK and find the version you need in the SDK. In my case this was verison 10. Having done this all my code completion stuff worked.

I know there where a few other issues related to installing FB, but I’ve put them so far in the back of my mind that I can no longer reach them. I hope this might help some of you having problems with Flex on Linux.

The tool

Equipped with the basic shell commands available in Linux I set out creating a simple shell script which works through the workspace directory of our CI server Hudson. The script runs each night and produce a report XML which gets aggregated using a PHP script to get all the statistics. On top I built a simple Flex dashboard which visualize the findings for the script.

The script counts the number of source files for MXML and ActionScript and also counts the number of code lines in each of them. During the work with this script an issue with build time surfaced, so we decided to add a tracking for that as well. The build time and SWF-file size parameters gets read from the Hudson status XML files.

The findings

Having run the script for a couple of months I have some data show how our application is growing and at what pace. The end of the graphs shows how Norwegian summer vacation effects the amount of code produced (number of developers is reduced with about 90%).

The most worrying graph right now is the number of code lines in our MXML files. Looking at the graph for code lines and number of files you will notice that we have a considerable larger amount of AS files than MXML files. However the number of code lines are not that far apart, which could lead to one of the following inclusion:

1. MXML files are bloated and need to be trimmed down
2. AS files are naturally smaller and there is no need to worry

Looking in detail at the code we’re closer to the first conclusion than the second and this is useful. Another interesting finding is that we’re not doing a good job of managing our assets as the file size just keeps growing. This told me that we needed to ensure that all developers understood the impact of embedding images in the application and that this is something which must be taken into considered when adding new images.

Anyway, I just found it interesting to see how the application will continue to evolve. We’re not to complete the project for another couple of years so it would be interesting to see what these graphs looks like in 2011. If you have made any similar efforts it would be interesting to hear how other projects evolve.

The dead horse

Israfil is a dead project in my opinion. The main contgributer does not add new features and people tend to just fork it and build their own version without being able/willing to commit it back to the project.

The "new " kid on the block

At first glance Flex Mojos looks like the right tool for the job, however after using it for some time I think it’s not worth the trouble and I will try to explain why.
It is a bad idea (and maybe not legal) to have the Flex SDK as a dependency in you POM. §Using the compiler Java API is also a bad idea as you get situations where your code builds just fine in FB and breaks when using Flex Mojos. This is extremely annoying and you have to spend a lot of time on something which is a waste of time.

Maven is just too strict

One thing which all Maven plug-ins have in common is that they enforce you to structure your Flex projects to suite Maven’s needs instead of what make sense. The concept of one artifact for each project does not work well with the Modules feature in the Flex framework. Nor does it provide an easy way to compile CSS-files to SWF-files without creating a new project. The Maven requirement makes you have to add a lot of complexity to your project as you need to create a lot of modules and projects just because of a requirement which makes no sense in Flex development.

What’s a girl to do?

What do I recommend? I recommend using the Flex Ant Tasks that ships with the SDK and use the Maven Ant Runner plug-in. This solves the problems mentioned related to Flex Mojos and it allows you to benefit from all latest innovations in the SDK right off the bat. With the plug-ins you have to wait for any new feature to be implemented.

Disclaimer

I do not write this to piss off the authors of the plug-ins mentioned as they are all doing a great job. I really hope you get the plug-ins right so that I do not have to maintain Ant build scripts, so the best of luck to you. However I just felt that I should come clean and say what is my preferred way of building Flex applications.

You should upgrade now!

There is no reason why you should not upgrade today. FlexUnit 4 is backwards compatible and you can migrate each unit test whenever you would like. With the introduction of Fluint and it’s support for Sequences it is possible to unit test user interface interactions without having to write tons of code to accomplish it. You get to write less code and another very important aspect is that you can actually understand what your tests do some time later because of the simpler syntax of testing.

FlexUnit 4 is a huge step from the old versions and it is now on the same level as JUnit and other test frameworks. Especially with the easier configuration of test runners, unit testing and continuous integration will be so much easier in the future. I am also over the moon about the FlexUnit plug-in which is coming to Flash Builder.

Upgrading to FlexUnit4

I have a few projects with unit tests using FlexUnit 0.9 and upgrading to FlexUnit 4 is very simple. All your tests can still be reused and all that is required is that you change the way you setup the test runner.
Here is how little I had to change in one of my projects:

private function onCreationComplete():void {
       testRunner.test = createSuite();
       testRunner.startTest();
}
private function createSuite():TestSuite {
       var testSuite:TestSuite = new TestSuite();
       testSuite.addTestSuite(SomeModelClassTest);
       testSuite.addTestSuite(SomeUIComponentTest);
       return testSuite;
}
....
<flexUnitUIRunner:TestRunnerBase id="testRunner"/>

With FlexUnit 4 this is actually made simpler, just have a look:

private var core:FlexUnitCore;
private function onCreationComplete():void {
       core = new FlexUnitCore();
       core.addListener(new UIListener(testRunner));
       core.run(SomeModelClassTest, SomeUIComponentTest);
}
....
<flexUnitUIRunner:TestRunnerBase id="testRunner"/>

What else is new?

I assume you have read the post FlexUnit 4 feature overview which gives a hint at what you can expect. Besides this one page the documentation is pretty much non-existing, but you can have a look in the source tree in the branch 4.x for samples of how to use the new features.
One would expect that it would be possible to see all the new features documented as unit tests, however it does not seem as if the FlexUnit team believe in dog food as the unit tests are far and few between.

Go download the FlexUnit 4 Beta 1 now!

Most of the current Flex/ActionScript frameworks tend to have the same problem, that they don’t focus upon developer productivity. They guys and girls at SpringSource have a great track record when it comes to creating developer friendly frameworks, so this is great news for those of us who’s batteled with Cairngorm and other MVC frameworks for some time.

This is great news as the people of SpringSource tend to have a much better focus than Adobe on developer productivity and easy of use. You can say alot of good things about BlazeDS, but it’s very much an outdated piece of software and it really needs to take the next step.

Read the press release from SpringSource

The session is an informal gathering and a great oportunity to have all your questions answered by a real life RIA Cowboy:

September 18th, 18:00
Peppes Pizza, Stortingsgaten

Hold up just a god damn minute here. First of all JSF probably is the framework with the highest learning curve I have ever laid my hands on. Because it is based ideas from all the horrible UI frameworks (AWT, Swing, etc) it is of course over engineered, utterly complex and not very well suited for UI development . The only reason people use JSF is because software vendors (IBM, Sun, BEA, etc) keeps showing it down their throat.

Secondly Flex is dead simple. If you are not able to learn to create a Flex application in one week you should probably change profession. I have personally experienced this with several Java developers who have learned Flex in one week without any prior knowledge of Flex or UI programming.

Anyone with their brain plugged in when reading about a framework and see the phrase “completely abstracted from its technology” know that it is absolute nonsense. If you think for one second that you can write Java code and not have a need to understand the technology it abstracts you should, once again, change your profession.  If you actualy belive the above statement you should read Joel Spolsky’s article The Law Of Leaky Abstraction.

What is depressing is that the people behind the JSF Flex Project probably have spent time on this utterly stoopid project.  I am sorry that you have wasted time on this and I am sorry that I have to tell you that you have wasted your time.