lowpitch.com

IFlexModuleFactory – create and examine loaded Flex Modules

In an earlier post I described how you can load in Flex modules using the ModuleManager class and the IModuleInfo interface, but I didn’t really mention IFlexModuleFactory which is pretty fundamental to the whole process.

The factory is responsible for knowing how to create an instance of the module, and also provides access to certain properties of the module. It can get a little more complicated as the methods exposed by the factory become available at different stages of the load process, so you have to be careful not to try and retrieve information before it is available.

The factory is retrieved used by accessing the factory property of the IModuleInfo object, returned by ModuleManager.getModule (). For more information on this, see the previous post. The factory will be of type IFlexModuleFactory, which behind the scenes is implemented by mx.managers.SystemManager. You don’t really need to worry about this detail though, it’s enough to know about the two public methods exposed by the factory.

They are:

• IFlexModuleFactory.create – This is really the most important method, and provides the mechanism for creating an instance of your loaded module. When enough of the module has been downloaded for this method to be called, the IModuleInfo object will dispatch a ModuleEvent.READY event, and the public property IModuleInfo.ready will return true. The method allows you to optionally pass in one or more parameters, using the “…rest” mechanism. These parameters are passed to your module’s constructor. Calling this method will create a new instance of your module, and the new instace of the method will be returned. The return type is specified as Object, so you will need to manually cast the returned object to the correct type in order to work with it.
• IFlexModuleFactory.info – This module allows you to find out a bit of information about the module which is being loaded. When enough of the module has been downloaded for this method to be called, the IModuleInfo object will dispatch a ModuleEvent.SETUP event, and the public property IModuleInfo.setup will return true. The method returns an Object, containing a variety of name/value pairs providing bits of information about the module. Examples of the kind of information that can be contained in the object includes width, height, a list of mixins used by the module, a list of RSLs used by the modules, a list of fonts embedded within the module, and information about the modules Main class name. The method can be useful for finding out the module’s layout information before you create an instance of it and add it to the display list.

Just to mention a quick ‘gotcha’ that I encountered when first working with Modules… If you find that the call to IModuleData.factory.create for some reason returns null, or at some point in the process you get an Error #1009, most likely your module is using some classes which for some reason are not accessible once the SWFs have been compiled and optimised. A simple fix for this can be to reference the offending classes in some way in the main application to force them to be compiled. Common offenders are the ‘manager’ classes, for example DragManager, PopupManager and SystemManager.

Tags: Flex, Modules

ModuleManager and IModuleInfo – loading Flex Modules dynamically

When you’re working with Flex Modules, most of the time the ModuleLoader component will be enough to get you up and running. It will quickly and easily let you load your Modules and add them to the display list, it’ll even dispatch an event to let you know when the Module is ready. Lovely stuff. It’s very similar to the SWFLoader component with some added Module-related goodness thrown in.

However, there may be times when the ModuleLoader component may not be appropriate for your needs, and you’ll have to get your hands dirty and get involved with the lower-level ModuleManager class. Some examples of when ModuleLoader might not be suitable include:

• Your Module is entirely non-visual, and therefore shouldn’t be added to the display list
• Performance is really important to your application, and the extra overhead of the ModuleLoader container is something you need to remove to try and speed things up. (ModuleLoader essentially wraps your Module’s content in an extra container, incurring a slight performance hit).
• You need greater control over how and when your modules are loaded and unloaded.

How does ModuleManager work?

ModuleManager maintains a map of modules, indexed by each module’s URL. Information about the module is stored as an object implementing IModuleInfo, and is retrieved by calling the ModuleManager.getModule method, passing in the module’s URL as the method’s only parameter. Once you’ve retrieved the IModuleInfo object, you can call its load method to starting loading in the module. While the module is loading, you can monitor the load progress using a variety of different events (of type ModuleEvent). Finally, when the module is loaded and available, you can create an instance of that module using someModuleInfo.factory.create ().

Continue reading ModuleManager and IModuleInfo – loading Flex Modules dynamically »

Tags: Flex, Modules

XML-RPC in Actionscript 3.0 – couple of gotchas

As part a recent project, I’ve needed to integrate a Flex 3 application with an existing XML-RPC webservice. Over the years I’ve not done a huge amount of webservice integration with Flash. In the past I would typically choose to send data back and forth from the server using the built in XML or LoadVars objects available in Actionscript 2.0. On a couple of projects, I ended up using the Flash Remoting API and AMFPHP to achieve what I wanted and everything turned out pretty well, and once I integrated an application with some .NET SOAP webservices. But XML-RPC was a new one on me.

Anyway, after a bit of research, I was a little surprised to discover that XML-RPC hasn’t already been supported by the Flex framework, but after looking around I came across as3-rpclib, an open-source library that not only supports XML-RPC, but also AMF0 and JSON-RPC (I’ve currently only used these classes with XML-RPC, so can’t comment on the other formats implements).

So far, the classes have worked really well for me. However I did hit a couple of stumbling blocks along the way which I’ll attempt to detail here.

Continue reading XML-RPC in Actionscript 3.0 – couple of gotchas »

Tags: AS 3.0, Bugs, Flash, Flex, XML-RPC

Discovering PureMVC, and scaling the learning curve

Background
A while back I began work on a personal project which would involve me finally getting to grips with Flex, Django and XML-RPC. I’ve been using Actionscript 3.0 for quite a while, but my experience with Flex had been relatively minimal. After getting past the initial “What the hell actually is Flex?” thing I spent some time trying to learn the basics.

I started off by going through the Flex Builder tutorials, built the sample application featured in Flex 3 – Training from the Source , signed up for the Flexcoders mailing list and even built a couple of little apps to help me automate some fairly dull database maintenance I’d been putting off. But at that point I’d never done any real work with Flex, and it quickly became obvious that I wasn’t sure where to begin when it came to structuring a fairly large application.

I’d read a bit about the various frameworks available for Flash and Flex, but I’d always kind of written them off as not applicable for me. I had my own way of doing things which, up until now, had always worked well for me and I saw no reason to change. This time, things were a little different,  and I decided that it might be time to revisit them.

Continue reading Discovering PureMVC, and scaling the learning curve »

Tags: Flex, Frameworks, PureMVC