While the exact syntax above would not be possible, closures are in any case the way to go. I explained him how I’d do it and I forgot about the topic until today.

Today while waiting for a long compilation process to complete I’ve came up with an idea on how to improve code readability on cases similar to this. Here’s the cleaneast syntax I’ve came up with (ideas are more than welcome to improve it):

Does it look too verbose? I guess it will highly depend on the exact use case where this is used. But under some circumstances I think the readability can be substantially improved.

createListenerAdapterBasedOn is a package level method. I could have used a utility static method like FunctionUtils.createListenerAdapter. But instead I’ve used a package function because I can reduce the length of the Class + method name (or use the same number of characters to add verbosity and clarity). On the other hand it’s unlikely that this utility class would have more methods.

Documenting functions

This is a concept I’ve never read about or used before, but I think I’ll start using in different places. withParameters method is a completely dummy method that simply returns the parameters it gets but giving them a semantic and contextual meaning. The solely purpose of this method is to improve the readability by converting the method invocation in a Fluent API that can be read as natural language. The method is simply documenting the usage of the call. Putting this together with the Builder pattern and named parameters I discussed a while ago it gives us an incredible weapon to create self-documented code that doesn’t need most-of-the-times useless, needless and confusing ASDoc or inline comments.

If necessary when you have a method accepting several parameters of the same type and that can be confusing to read you could used Documenting functions to create kind of named-parameters:

Here are the details of the implementation in case you are interested in seeing the internal details and some of the tests.

createListenerAdapterBasedOn.as

withParameters.as

createListenerAdapterBasedOnTest.as

This is a feature widely used in FlexUnit but that can be used in lots of other circumstances to reduce the amount of code and reduce its verbosity.

The mechanism to create a package level function is pretty simple. Here are the steps required to create a custom package function:

• You create a class where the function will be defined. i.e: your/package/Assert.as
• You declare a public function at the package level. Note that there’s no class definition.
  package my.pack
  {
      public function assert()
      {
      }
  }
• Then you can use it from every where you wish
package
{
    import my.pack.assert;
   
    public class testPackagefunctions
    {
        public function testPackagefunctions()
        {
            assert();
        }
    }
}

When creating package level functions, the only restriction to bear in mind, is that the function name exposed must be the same name as the name of the file that contains it. i.e. If I expose the assert function, the filename that defines it must be assert.as. This implies that there can only be one function definition per file. If you need more you can create as many files as you need.

Package level functions in AS3 are directly comparable to static imports in Java. In java we can write code like:

By using an static import in Java, static methods defined in the Assert class (in the example above) are made available directly so there’s no need to write Assert.assert. Again this is a feature used a lot in jUnit, Hamcrest or lamdaj libraries.

Autocompletion in Java in regards to static imports is not automatic. If you want to have autocompletion with static imports you can use Preferences > Java > Editor > Favorites and add there the Types or classes you want to use static imports for.

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.

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.

The higher number of arguments a method accepts the harder it’ll be to read, understand and test.

When a method needs too much arguments, it is normally a sign of:

1. Poor encapsulation
2. The method is doing more than one thing, breaking the Single Responsibility principle. The arguments define what the method will do, they define and change the method execution path. (i.e. flag methods)
3. Method signatures are harder to read and it’s easier to introduce errors by swapping the order of parameters (specially if they are of the same type). (link to FB issue to highlight parameters. i.e. assertEquals();)
4. Method parameters are all part of the same concept and could be encapsulated in an object with its own type.
5. Arguments belong to different levels of abstraction and are harder to understand.

To reduce the number of arguments in class methods you can consider different techniques depending on what the exact problem is in each case:

1. Create specialised objects that wrap several parameters. i.e. x, y could be a Point instance.
2. Transform method arguments into class properties so that they don’t need to be passed between methods.
3. Create different methods or strategies to fork the behaviour instead of using flag parameters
4. Use factory methods and builders.

All points above can even get worse when overusing optional parameters, which lot of people use to alleviate the lack of method and constructor overloading in ActionScript3 instead of using Builders, Factories of creating different named methods.

If we focus on constructors I think they should only accept:

1. Required parameters for the object to be properly initialised.
2. Optional invariant parameters. Parameters that can’t be changed during the life of the object and that thus need to be specified during born.

Let’s consider the typical Person object with a name, surname, age and a unique invariant Id. We define a constructor with 1 required argument and 3 optional ones:

You could create different instances like:

The code above will compile fine, the compiler won’t complain at all since all declarations are right, but there’re several data integrity errors here, errors that are normally very hard to find and isolate. i.e. p3 is setting the address as the surname. p4 is swapping the surname and the address.

In this case, the Person type and the data might be self explanatory, but there are a bunch of other cases that are not. Having cluttered constructors with lots of optional parameters is quite common when dealing with Custom Events.

What would be interesting is to be able to pass the optional parameters in a named way, removing the order constraint while making the solution more readable, developer friendly and robust to changes:

This solution is a kind of Buider pattern implemented in a fluent way, a train wreck. It’s also somehow mimicking named parameters in other languages. The nice things I really like about this syntax is:

1. It’s a compact expression. It can be written in just one line.
2. The order of the optional parameters is not important anymore.
3. It’s easy to read and prevents parameter swapping. In some cases it can also be read as a natural language phrase.
4. In case of invariant optional parameters the builder can hide the implementation in the build method.
5. It doesn’t break Demeter’s law. Although implemented as a train wreck, each method is applied on the same object.

As mentioned above a common scenario where you could apply this technique is when dealing with custom events. Imagine you want to implement CRUD operations in terms of Persons. You could have:

This implementation would allow you to reuse the same PersonEvent for the different operations without cluttering the constructor with all the different permutations of optional and required parameters in a scalable way. Another option in this case would be using static factory methods (but this won’t solve the optional parameters mess).

The goal was to be able to consume, from the new application, the exact same Java Services that the Flex application was consuming through RemoteObjects without modifying the Java code or the server gateway at all.

This scenario could be a very common scenario in the near future when porting, adapting or extending existing applications to different devices targetting Flash Player 10.1.

BlazeDS uses some kind of handshake between the client and the server as well as control messages that were not obvious to replicate in a custom implementation using a plain NetConnection object. Also I wanted to make use of the several more complicated features that Flex rpc implementation brings.

Basically the problem became to “How could I use the entire component set from rpc.swc distributed with Flex SDK in a Flash or AS3-only project?”

This excercise is also applicable to WebService, HttpService, Consumer or Producer (messaging) classes.

Step 1.

Add rpc.swc from {FLEX_HOME}/framework/libs to your project or .fla classpath

Step 2

Compile some simple code using RemoteObjects:

Compiling this code throws several different errors due to unsatisfied or missing dependencies:

mx.logging.ILogger
mx.rpc.IResponder

These 2 classes are in framework.swc Copying the swc from the FlexSDK into your classpath will fix the issues.

Step 3

After that you’ll get errors due to missing resource bundles like:
“Unable to resolve resource bundle ‘collections’ for locale ‘en_US’”

Copying to the classpath the required resource bundles from {FLEX_SDK}/frameworks/locale/ will fix the problem. You’ll only need to copy rpc_rb.swc and framework_rb.swc

You will receive this error only if compiling the project using the Flex compiler. You won’t get this error if you compile your application in Flash.

Step 4

When the application finally compiles you’ll always get FaultEvents with not too much information.

faultCode: “Client.Error.MessageSend”
faultDetail: “Channel.Connect.Failed error null url: ‘null’”

Using Charles I realized that the request was not even sent, something was going wrong.

Step 5

All RPC classes use the Flex logging API so enabling it in the Flash project could be helpful. To enable it we only need to add:

Step 6

After a couple of hours of debugging I discovered that RPC library to properly work needs to be initialized in the following way:

Where loaderInfo is the loaderInfo object of the root Sprite of your application.

After adding the initialization code you will see the request going through in Charles.

Step 7

There’s still one last problem to solve:

“TypeError: Error #1034: Type Coercion failed: cannot convert Object@20612a79 to mx.messaging.messages.ErrorMessage.”

The error means that somewhere an ErrorMessage object was expected but instead an object of type Object is received. We need to register several types. This will happen with several different types of ojects. To solve it:

After properly registering these classes everything should work as expected (the list of required registrations might not be complete, if you find a TypeCoercion error consider registering the object).

The entire code you need:

Pros and cons of the solution

• ~100Kb footprint
• You can focus on adding value and not building the infrastructure.
• Faster time to market
• Solid market solution

Improvement points

Using the above solution you’ll have to work with ArrayCollection instead of Arrays which in certain situations might not be necessary, might have a performance impact as well as increase the number of class dependencies and file size.

One possible way to get rid of ArrayCollection and all its dependencies (i.e. ListCollectionView, Cursor, SystemManager, etc.) would be to create your own map. Instead of using:

You could use:

Where your class would implement IExternalizable. This class could be completely light and would mean a considerable improvement in terms of dependencies and lighter implementation.