BeauScott.com

Ted Patrick has some highly suspect blogging going on, posting what would appear to be the splash from the final build of Flex 3! He doesn’t say what this means, but one can make assumptions Very exciting stuff here!

I’ve seen a few people ask on the flexcoders mailing list about different methods of loading applications at run time based on a user’s login without navigating to a different URL. There are several ways of doing this using a ViewStack or view states to toggle between application views, using a SWFLoader to load in separate standalone SWF movies at runtime, or using a ModuleLoader to load in Flex modules at runtime, each based on a user’s access rights.

Using a ViewStack/states to accomplish this is probably the least desirable method, especially if your application is even mildly complex. In essence you’re just toggling which view is visible, but each view exists statically in the application at all times. This can cause your application’s file size to be quite large, and can lead to messy event registration and clean up and really complex view clean up logic.

Using a SWFLoader is a bit better with memory clean up and event management, but still isn’t the optimal solution as each of the modules that you download will generally be larger than they need to be because they’re standalone applications and include the overhead of classes already included in the loading application (frameworks, dependent libs, etc.). This will result in a smaller loading application, but when you factor in the size of each subsequent SWF loaded, the total application file size is substantially higher. It also can be a bit complex to manage the applications being loaded in.

Using a ModuleLoader (or ModuleManager) to load Flex modules into the application at run time is very similar to using a SWFLoader: you’re still loading SWF files into the application at runtime, but the difference is the size of the loaded files. Flex Modules are based on either mx:Module if it’s a component that interacts with the framework (view components generally) or mx:ModuleBase if it’s a component that doesn’t need to add things to the display list. This cuts out a lot of overhead as it doesn’t have to include all the application-related objects. Flex Builder also has a built-in tool to help define these modules for your project, making managing them very easy. (See Project Properties -> Flex Modules)

I put together a simplified example using this approach. It’s really just an example and doesn’t have much real-world implementation code, but it does show how to use runtime data to define your application’s behavior while keeping memory and download sizes at a minimum.

My approach involves using a component that consists of a ModuleLoader to load modules in by their package name (eg: “com.beauscott.examples.modules.Module1″), a global UserManager object that handles all login/logout event dispatching and related model information, and a series of 4 modules that are loaded per each users’ module access rights. Each user defined can have one or more modules permitted for their use. If only one is defined, the module loader automatically loads it. If more than one are defined, it will prompt you with a list of available modules to choose from (double-click).

It’s very rough and there may be better methods out there, but I hope this helps as a starting point.  I’d love some suggestions and feedback as usual

Click here to download the project and source code

Click here to see the live demo (you can right-click to see the source here, too)

I’m a little late in reporting on this, but Adobe released BlazeDS RC1 on Feb. 1st.

For those of you who don’t know what BlazeDS is, it’s a soon-to-be open-source subset of Adobe’s expensive LiveCycle Enterprise Data Services Suite. It’s more or less an AMF (pdf) service gateway for your Java application, with other features like http polling for messaging. In the past, if you wanted the speed benefits of AMF with your large-scale java application you had to use a third-party solution like GraniteDS.

Sujit Reddy G has put together a good side-by-side comparison of the two.

I’ve been working a lot in Flex 2/3 and Adobe Integrated Runtime over the past year (which is why my blog has been so neglected), and finally got around to making an example application that shows off some of the capabilities of Adobe AIR. I’d like to introduce Cheapo!, an AIR-based deal-site monitoring application. It runs in your system tray (yeah… windows systems are currently the only supported. It does run on a mac, but there are some glitches with menus — I’m fixing these shortly) and alerts you once an update has been posted to one of several deal sites. In reality, it’s nothing more than a glorified RSS reader with some customized styling. In it’s current release, it’s a closed source application because it’s a customized list of deal sites and I’m offering it as a companion application on a few other sites. However, I will be releasing the RSS reader/alerter part of it as open source shortly which will allow you to build your own RSS feed alerting application.

Currently, the featured deal-sites are Woot (with support for Woot-offs), Gottadeal, Passwird, Slick Deals, Buy.com and Amazon’s Gold Box. If you have any other deal-site suggestions, please let me know.

To run this application, you’ll need the latest Adobe Integrated Runtime (currently Beta 3).

Once you have installed the runtime, click this link and select “Run from current location” (or whatever the equivelant is in your browser)

As always, please send me feedback and bug issues and I’ll do by best to release a fix for whatever issue you might be having as soon as possible.

7:27 PM PST here and yet another Adobe Labs jump here. You can download Adobe Flex Builder 3 Beta 3 from labs. You’ll need an Adobe ID first… I’m currently downloading these now and will have an update for what the changes are soon.

According to the Labs site, this is the FINAL public beta of Flex Builder 3.

Adobe Labs Flex Builder 3 Download link