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 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.

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?

The stacktrace of these exceptiosn, normally, looks like the lines below:

Today, snooping around the UIComponent class, I’ve found a nice unexpected thing. Basically the invalidation pattern in the SDK is built around the LayoutManager and the UIComponent classes. The callLater method is the responsible to delay the execution of certain functionalities to the next frame. callLater implementation relies on the RENDER and ENTER_FRAME frames. The handler for these events is the method callLaterDispatcher.

Here’s the surprise. If UIComponentGlobals.catchCallLaterExceptions is true, the execution of the validation cycle will be wrapped with a try..catch and a DynamicEvent will be dispatched through the systemManager with information about the error.

This opens the doors for at least catch the error and log it. In some cases, depending on the severity of the error and if the application is not too corrupted, we’ll even be able to display a message to the user notifying him the error. This is not a fix to FP-1499 nor FP-444 but under some circumstances it can be really helpful if combined with great logging practices as explained by Tom.

I’ve created a simple class that hooks into the systemManager, listens for the callLaterError event and logs it using the standard SDK logging mechanism. The AsyncErrorLogger is MXML friendly so that it can be instantiated in the root application. It provides an enable property to switch the behavior on and off. Additionally the property redispatchErrorEvent, which by default is false, redispatches the error causing the traditional flash player error dialog to appear (in debugger player versions) and not fail silently.

Here’s an example on how to use it:

Here’s the code. You can download the class from here as well.