Auto Localizer blog post

Auto Localizer on the Adobe AIR marketplace

Auto Localizer blog post

Auto Localizer on the Adobe AIR marketplace

I did not spend a whole lot of time polishing the UI for this application as it is really just a utility for developers. I already know of a few places that can use some more development to increase usability, so I went ahead and used the AIR update APIs to check for and install any updates I make to this application. Feel free to let me know what you think and what improvements can be made. Of course I cannot improve the quality of the translations that come from the Google Translate service, but everything else is fair game.

Install the Auto Localizer application.

Instructions on using the Auto Localizer application.

The answer is Interfaces. By defining a common interface for our modules and using it in both our application and our module we can easily allow our application to use any module methods exposed by the interface and avoid tight coupling.

Once again I will borrow from my previous post and add an interface to my FirstTry Application. Below is the interface I will be using (filename “IModule.as”):
package modules
{
import flash.events.IEventDispatcher;
public interface IModule extends IEventDispatcher
{
//expand the app (same as mouse over)
function expand():void;
//collapse the app
function collapse():void;
//click CRT button
function showCRT():void;
//click Flat panel button
function showFlatPanel():void;
//click Rear Proj button
function showRearProjection():void;
//click Front Proj button
function showFrontProjection():void;
//Pass in a yes/no question for the module to ask with an Alert.
//The alert will call back into your provided function
function askQuestion(question:String, alertCloseListener:Function):void;
}
}

In the module we need to implement this interface. To do that we add an implements tag at the top of the module like so:
<mx:Module xmlns:mx=”http://www.adobe.com/2006/mxml”
implements=”modules.IModule” >
</mx:Module>

At this point you would get compile errors telling you that the functions in the IModule interface do not have implementation methods. I won’t go into the individual method implementations here but you can refer to the complete source to see them in the sample project below.

Once the IModule implementation methods are done we are finished with the module and can move on to the Application that will be calling into the module.

In your application you first need to import the IModule interface:
import modules.IModule;

Once you have your module loaded you can test to see if it implements the module interface:
module = info.factory.create() as UIComponent;
if (module != null) {
//If the loaded module implements the known interface we can make calls into this module.
if (module is IModule) {
IModule(module).expand();
}
}

As you can see using interfaces with modules is pretty simple once you understand how it works. I’ll leave it to you to browse the source to see the various interface calls in action. Below is the updated Module Loader application with source enabled.

Now change the two instances of “mx:Application” to “mx:Module” like so:

<mx:Module xmlns:mx="http://www.adobe.com/2006/mxml" >
</mx:Module>


Recompile your project. You are done! You now have a module SWF file. Much simpler than the title implied right? Well stopping here wouldn’t be much of a post, but don’t worry I have something more interesting to add.

A large part of the enterprise project I’ve been working on for the past two years has been dealing with modules. In this post I’ll show how to load and unload your newly compiled module dynamically into another Flex application with a progress bar.

You cannot tell the difference between an application SWF and a module SWF just by looking at the file. If you try to run a module SWF as you would a application SWF you will just get a blank screen with the default flex background. Compiled Flex modules can only be used by loading them into a Flex application.

Borrowing from a previous post, I’ve recompiled my FirstTry application into a module and will use it in an application to demonstrate loading and unloading modules.

There are two ways to load modules, using mx:ModuleLoader and using mx:ModuleManager. ModuleLoader is easier and quicker, but ModuleManager provides greater control over your module loading.

Loading a module with ModuleLoader can be as simple as adding this mxml line to your application:
<mx:ModuleLoader id="myModule" url="MyModule.swf" />
This loads, instantiates, and adds the module to your UI all in one step. It is used in your mxml just like any other component tag (such as mx:VBox, mx:Canvas, etc.).

My sample project will concentrate on using the more flexible mx:ModuleManager. With ModuleManager you can download the module without immediately adding it to the UI. You can also instantiate multiple instances of a module if you have the need. There is only one method of interest for us on ModuleManager called “getModule” that returns an mx.modules.IModuleInfo object.
var info:IModuleInfo = ModuleManager.getModule(moduleURL);

This call does not actually load the module yet. The IModuleInfo object is what we will use to load and instantiate the module and track the loading progress.

You can very easily show loading progress using a mx.controls.ProgressBar. All you need to do is set the source of the progressbar to be the IModuleInfo object like this:
var pb:ProgressBar = new ProgressBar();
pb.source = info;
Now the progressbar control will dynamically update with the loading progress of the module.

To actually start the loading of the module we need to call “load” on the IModuleInfo object. We need to add a couple of event listeners for listen for complete and possible error events.
info.addEventListener(ModuleEvent.READY, modEventHandler);
info.addEventListener(ModuleEvent.ERROR, modErrorHandler);
info.load();

Once we get our READY event we still need to create an instance of the module and add it to our UI. We create an instance by using the factory in the IModuleInfo object. After that we merely need to add it to the UI.
var module:UIComponent = info.factory.create() as UIComponent;
moduleContainer.addChild(module);

We create it as a UIComponent so that our application does not need to know exactly what the module is to use it. In future post I will show how you can create and implement Interfaces that allow two way interaction between the module and the container application.

If your application ever decides it is finished with a module it can unload it. Using the same IModuleInfo object you can call “unload” and listen for the UNLOAD complete event for any cleanup.
info.addEventListener(ModuleEvent.UNLOAD, unloadEventHandler);
info.unload();

In future posts I will also go into how you can reduce the compiled size of your module SWF files when you know they will always be loaded by a specific application.

Below I have included a sample application that loads and unloads my FirstTryModule. The application itself only has two buttons: a load button and an unload button. Clicking the load button will load the module while displaying a progressbar and then add it to the UI. Source is enabled on this project so take look to see how all the code snippets above fit together.

Details Here

This is a limited time offer good between February 9, 2009 through March 2, 2009.
Could be a good time to buy if you have been sitting on the fence.

Adobe AIR 1.5

Let me first give credit to the reflection component (Reflection.as) and the moving tooltip (FXCTooltip.as). The reflection component was written by Ben Stucki and the tooltip component was written by Maikel Sibbald.

Looking at the code you can see my first application didn’t produce the cleanest code as I was learning and hacking around anything I didn’t quite understand yet. You’ll notice the door transition is not really a true reusable effect. Instead it is a set of two containers with images that I manually slide open and closed with parallel effects.

One interesting revelation in writing this application was that there is no animated GIF support built into Flex. At the time I was a little annoyed having been used to it being available in Java for years. That broke my idea of using an animated GIF for the little moving gears on the left sliding door. I now know you typically embed a Flash SWF animation for situations like this, but I don’t have Flash Professional so converting my animated GIF was not an option.

My hack solution is found in “components/AnimateImage.mxml”. Basically I extended mx:Canvas and stacked all the frames of my animated GIF in separate mx:Image components. At any given render only one of these images is “visible”. This animation is achieved by flipping through the frames forwards or backwards depending on what direction I want the gears to turn. The tricky part was figuring out how to get the gears to animate in sync with the sliding door container. What I discovered was that each component on the DisplayList will get a render event each time a render occurs. So what I did was add an event listener for this render event to one of the image controls like so:

i1.addEventListener(Event.RENDER, eventHandler);

Each render even will call the eventHandler function that will flip the displayed image to the next image in the animation. This works perfectly to keep the gears moving at the same speed as the sliding door. As each door render will cause the render event to fire on the image. This basically means that any easing function I place on the sliding door movement will also effect the gear animation. As the door accelerates or decelerated the gears speed up or slow down in sync.

One pitfall of using the render event is that it fires anytime anything causes the Flash player to render to the screen. This means that you must remove this even handler when you want the gear animation to stop. In this case the event listener is added when I start moving the door, and removed when the door is finished moving.

Feel free to post questions about the code or even suggestions on how to fix some of the poor code. I’ve learned a lot since I wrote this first application but, while I know how I personally would clean up some of this code, I know that there is always someone that can always teach me new tricks.

Here is the recompiled application with view source enabled:

I finally broke down and bought the book Adobe Flex 2: Training from the Source. I spent a week following the books examples before I couldn’t contain myself and started my own test project. In my spare time spread out in a week I threw in every transition and effect I could discover into this test project. The code is not pretty and I know now that much of what I did is completely wrong causing me much more work than what was necessary. Yet the result was amazing. Here was a relatively clean application (albet with little real purpose) written in one week by a complete Flex neophyte that would have taken me a month in Java SWING (taking into account the animations, reflections, etc). I have experience writing my own real time animation rendering engine in Java, but in Flex it is virtually free.

Here is that first Flex project:

You can see it is nothing spectacular and it isn’t polished enough for a paying customer (the sounds I scrounged being particularly awful), but it speaks to how easily someone coming from event driven Java SWING can jump right in and work in Flex. This first two weeks of delving into Flex had gotten me hooked. If you know Java and have been hesitating on trying Flex, don’t wait. Give Flex a try. I still use Java all the time, but generally it is on the back end. The ability to seamlessly transfer Java objects and AS3 object over the network is wonderful, but that is a whole other discussion.

Since switching to Flex I’ve been lucky enough to lead a large team developing enterprise software using Flex to create custom components and also making extensive use of modules. In my spare time, I now tinker with AIR projects. If you ask me what I at work now, I’ll say I’m an RIA Flex developer.

I do apologize for not having included the source of this demo project. This SWF was built on Flex 2, and I have not yet recompiled it for Flex 3 with source included. I plan on doing just that in a future post. I’ll also dissect some of the code and explain how I got certain interesting parts working.