lowpitch.com

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

Flash plays certain MP3s back at double speed – why?

A colleague and I recently found some odd things happening with dynamically loaded audio in an elearning application we have been working on. The external MP3s seemed to be playing back at double speed, and as a result the audio was a hideously high-pitched mess. The weird thing was, this wasn’t happening on every machine. Some computers, including mine, would play the audio back fine but a couple of other people were reporting the same problem so we had to look into it. Bah.

After much fiddling, we reached the following conclusions:

• Flash seems unable to handle MP3s encoded with a variable bit rate (VBR)
• Flash seems unable to reliably handle MP3s which have a sample rate which is not 44,100 Hz, 22,050 Hz or 11,025 Hz.
• Additionally, it seems possible that there are certain bit rates which are also not handled well by Flash. We’ve tested files successfully at 40kbps, 80kps, 120kbps (and many other multiples of 40).

(Note: This was happening in an application built with Actionscript 2.0 for Flash Player 8. I haven’t had a chance as yet to see if the same problem occurs in SWFs running in AVM2)

While the problem of the audio playing at double speed did seem fairly hard to recreate, we did find another way of highlighting the problem. The JW Media Player is a popular, open-source MP3/FLV Player and can see be seen in-use all over the internet. From our tests, ‘incorrectly’ encoded MP3 files can also create a problem when played as part of a playlist in the JW Media Player. If the user is listening to one of these MP3s, and moves the seek bar somewhere between half-way and the end of the file, the Media Player incorrectly decides that the MP3 has finished, and automatically moves to the next item in the playlist. Without looking into the code in more detail, this kind of assumes that the information Flash is broadcasting about the MP3 (for example sample length, or current position.) is incorrect, which is causes the MP3 to finish prematurely. Re-encoding the audio to match the criteria listed above will always fix this problem.

(Note: Current versions of the free Audio editing software Audacity, used in tandem with the LAME MP3 encoder, do not allow you to choose the bitrate of the exported MP3. However, the Beta version of Audacity 1.3 does offer that functionality via the Options button in the Export Dialog. The Beta version of this software can currently be downloaded from http://audacity.sourceforge.net/download/.)

Tags: AS 2.0, Audio, Bugs, Flash