The article summarizes a set of best practices to configure your projects on Flash Builder and Eclipse in general for maximum efficiency and reduced maintenance effort.

As a software engineer joining a new project, I want to be able to get the code quickly, build it, and then run the application. I don’t want to have to work through a complex set up procedure, read countless how-to documents, or learn the detailed ins-and-outs of the application to simply get started.

You can read the article on Devnet.

Do you follow any other best practices? any tips?

The [Mixin] metadata tag is extensively used in the Flex automation API and it basically gives you a very interesting hook. The static init method of any class marked as a [Mixin] will be invoked at a very early point during the application initialization phase by the SystemManager class or FlexModuleFactory. The Mixins are executed before the preInitialize event is triggered on the main Application. The parameter that the init method receives is a reference to the related SystemManager so you can mark the parameter as an ISystemManager, InteractiveObject or whatever better fits your needs. You can read about another interesting use of the [Mixin] on the Global Exception Handler post .

By adding a Mixin class in a library and linking the library to an Application what you effectively get is a hook where the library can initialize itself and release the developer from manually initializing it.

Let’s see some real world examples.

Libraries like fxSpy, deMonsterDebugger, KaptInspect or mrdoob are extremely easy to use but on each project you end up doing some repetitive steps or adding conditionally compiled code to your Main application class.

I’ll focus on a sample with fxSpy where you can launch it from a contextual option when you right click on the application and see mrdoob memory monitor. The only step required to integrate this will is adding the following compiler option:

And this is the library initializer, which basically adds a ContextMenuItem to the contextMenu of the systemManager. Note that we have to wait for the APPLICATION_COMPLETE event, otherwise the Flex SDK will override our contextMenu (it happens on the pre-initialize phase).

In the Initializer you could also intialize the fps and memory monitor provided by mrdoob by simply adding a new instance to the DisplayList.

These are the benefits I see on this approach:

• You won’t have to reapeat yourself in different projects initializing the same libraries always in the same way.
• Your main file won’t be cluttered with infrastructure and glue code to configure your libraries.
• You won’t need to use conditional compilation for this initializations. You can enable or disable all at once by removing the compiler option. Going an step further you could have diferent compiler profiles / environments on your ant tasks or maven builds or even use the -load-config compiler option to externalize your configurations to an xml file.

You can downdload a zip with 2 sample projects, one for the library and the other for the application using it.

Shortly I’ll blog about some of the things I have in my toolbox that could be helpful for you too.

Starting on FP 10.1 and AIR 2.0 you can capture unhandled exceptions or errors globally. Although you can use these new APIs you should always take care of the exceptions where they happen and use this technique only as a diagnosing or logging help or for async exceptions that you can’t really control in any other way.

You might also be interested in these 2 other topics:

• Logging and catching (async) exceptions during invalidation in Flex
• Debugging and getting Stack-trace error dialogs with installed AIR applications

The new API works like:

Christian Cantrell explains some more details on the APIs. You can find further information in the documentation as well.

When working with Flex, and adding the UncaughtErrorEvent.UNCAUGHT_ERROR listener to the loaderInfo object make sure you do it after FlexEvent.APPLICATION_COMPLETE event has been triggered, otherwise you’ll get an “Error #1009: Cannot access a property or method of a null object reference”

To prevent all this required glue code and avoid unnecessary configuration code (that ends up cluttering the main application Class) I’ve created a GlobalExceptionHandler component that abstracts developers a little bit from these sort of problems. The implementation isn’t tighted to the APPLICATION_COMPLETE event, instead it uses the [Mixin] metadata tag. On top of that you can use it declaratively:

You can download the code along with a sample project here. The code for GlobalExceptionHandler:

The code for LogHandlerAction:

One of the things I like a lot about Parsley are all its extenstion points and available hooks to extends its native functionalities or default behaviours. In these regards a very useful extension point is, Tom explained a while ago, the different configuration mechanisms.

As explained in the documentation you can use a combined configuration mechanism to separate more dynamic or change-prone definitions from the more static ones. You could use an XML-based context defintion for the former and an MXML-based context definition for the latter.

While the XML-based context definition might work in most of the cases it might not be the best solution in some scenarios due to its verbosity.

Imagine I have an AIR2 based application which creates an HTTPServer instance. The server instance is created an managed by a Parsley Context:

The second constructor parameter, 5000, is the port the server will be listening to and the third-one, 0.0.0.0, is the network interface where the server will be binded to.
These 2 parameters are potentially prone to change whereas the rest of the definition will be very static and rarely change. In my case these parameters should be configurable and maintained by IT administrators or even final users.

Moving this definition to a runtime configuration mechanism seems like the right thing. The main problem of moving this into an XML-based context is that it’d be too verbose and meaningless to the the targeted users who should maitain and drive the changes, thus making the configuration system of the application too weak and error-prone while exposing things that shouldn’t be changed (at least by these users).

What I would like to do is define in a more static way the server creation instance, making it safer to undesired configurations, but make more dynamic some of its arguments:

Then we could define the port and host parameters using any other mechanism.

My approach has been to create a properties file based configuation. I create config.properties like:

And then the following combined configuration mechanism:

This way the Parsley Context is built using an standard mxml approach together with a properties file based configuation. The PropertiesConfig implementation uses ContextBuilderProcessor and AsyncConfigurationProcessor extensions, load and parse the specified properties file and inject the property definitions into the context as simple strings. These definitions can then be used elsewhere normally.

You can find attached the entire implementation. Note that I implemented this against trunk (v.2.3.M1-snapshot) so it might not work out-of-the-box for other versions.

This technique could be used in a wide range of scenarios. You could define RemoteObjects and ChannelSet in an MXML compiled configuration file but inject from a properties file the url of the Channel. i.e.

In the config.properties:

And the declare the ContextBuilder as:

Note, as suggested by Jens, that there might be scenarios where a tag like ObjectRef is not a good fit (like when using some of the built-in Flex tags like mx:RemoteObject). Being able to use a plain Flex binding on a simple MXML attribute might be a nice alternative to having “heavyweight” top-level String objects.
Other very intersting ways to achieve this same behaviour suggested by Jens (all kudos to him):

1. Use XML Configuration declaring strings like:

2. Create a custom tag that does the above in a more concise syntax using the Spicelib XML-Object-Mapper and a Parsley XMLConfigurationNamespace. You can see an example of this approach in Cairngorm3 Module library

3. Use the approach of an Environment class holding these values in the XML file, but use a custom tag in MXML:

The PropertyRef tag would require a bit of work (and it would be different for Parsley 2.2 and 2.3 due to some changes in internal APIs.

Download PropertiesConfig for Parsley..

For simple String concatenation like:

You can alwayus use StringUtil.substitue, which will help you having a wider vision of the message being built:

When creating multi-line Strings, things can easily get uglier:

Not to say that this could get worse. A way to make it a little bit more readable would be using the StringUtil substitution technique:

The problem with this is that there’s still too much infrastructure to create the base template and it’s difficult, at first sight, to see where are the substitution tokens. On the other hand, the templated text by itself might not have that much relevance in the code and might distract developers from other imporntant things.

A nice way to achieve the same result consists in externalizing the template to a text file and get some help from the compiler:

Where yourTemplate.txt is a simple text file with the template itself:

Note that using the [Embed] metadata instructs the compiler to link the file content at compile time, making our code completely synchronous.

Also note that we’re substituting the parameters using the order, it’d would fairly easy to do a named-parameter subsitution instead (i.e. using tokens like ${var1})

Finally, in MXML you can use this other technique to compile an external text file:

One way to implement it, would be as an extended concept of a template component as explained in my previous post. It would basically be a template component with 2 customizable areas: the frontView and the backView. As a developer I’d then use it like:

The interesting thing about this component is that there’re a bunch of different ways to present 2 panels and to transition between them i.e. flip, wipe, zoom, etc. If we encapsulate the logic of having 2 areas or content holders we can extract the presentation or view customizations into skins.

See sample fullScreen
Browse code.

The component is implemented using states, although it could be implemented without using states to prevent the views to be mutually exclusive, the base idea would be essentially the same: define contentHolders where we addElements set in certain properties.

A very interesting feature we still to add is deferred instantiation of the frontView and backView. By typing frontView and backView as IDeferredInstance will prevent the application from paying the cost of initializing the views until the user actually wants to see them. This means that if the user doesn’t click on the button the back view won’t be instantiated.

See sample fullScreen
Browse code.

If you use this component make sure you grab the one with deferred instantiation.

This is just a proof of concept and the code might have some problems. You can use it at your own risk.

In Flex3 you could use the technique explained in the Flex documentation in combination with [DefaultProperty] metadata. The technique basically consists in creating a subclass of a Container component who defines properties with a general data type that lets the component user specify an object of a concrete data type and then reparents it.

Flex4 Skins, by definition, serve the purpose of a templating system. If you consider the example of a s:Panel you have the PanelSkin where you can really easily change and adapt the template and where and how the provided / customizable content will be placed.

If you have to create a templated component with just one customizable area, maybe the best approach to create it would be to use an s:SkinnableComponent. In the following example I’ve created a very simple template that places a header an a footer around a given component.

Where TemplateSkin1 is:

The SkinnableContainer base class provides a series of functionalities like creationPolicy and layout property proxying or deferred instantiation that makes very easy the task of creating templated components.

See sample fullScreen
Browse code.

In more complex scenarios where the template has more than one customizable area SkinnableContainer might not be the best choice. You can find further information about this scenario in the DualPanel component post.

If you want you can disable or enable selectively the Bindings in an mxml document using the BindingManager:

You could enable or disable the bindings according to the visibility of the document.

I think this layout would be nice for Mobile devices to quickly browse content by tapping and dragging. I’ve tested it in different devices and from a usability perspective it’s very nice. I can see a big potential on it.

You can check the code here.

As an exercise to better understand the details of the new layout mechanism I played a couple of days creating some layouts that I’ll be posting during the next days.

The first layout I created was a Coverflow layout. There already exist several implementations out there for Flash and even Flex. The biggest difference in this implementation is that it’s using standard 2.5D APIs and the standard Flex4 layout mechanism. This translates in a 200 lines of code and quite good performance.

Bear in mind that:

1. This is not production ready code and might have issues.
2. I haven’t optimised the code at all, it’s almost a first pass code.
3. The layout is not using any virtualization capabilities, which means that won’t perform nicely with big dataproviders. I’ll implement this in the future.
4. I’ve added several configuration parameters and some combinations might not work as good as others.

As an extra, and even though Flex4 is not specifically designed for mobile, see how it works in a Nexus One with FP 10.1 beta. In the video below you can see how the application runs just out of the box, no recompilation, no changes at all. Same content that runs in my laptop runs in Enrique’s phone. The performance is really nice! What the Flash Player team has achieved is amazing!
congratulations guys!!

You can run the application here http://www.rialvalue.com/coverflow
You can get the source code here http://rialvalue.com/coverflow/srcview

Which parameter combination do you like more?