Recently as I continued my miserable everyday struggle with Flex and it’s incredibly slow IDE Flex Builder, I have made yet another discovery that of course is not documented about Flex. I am involved in building high end flash sites everyday and thus far on all of them I have created them as modular style Flex applications using Flash to provide some very crafty assets. On one of the most recent sites I was working on I eventually ran into a huge problem.

The Problem:

The site had a major memory link throughout the modules. I had ultimately determined that this leak was caused by Flex’s mx.controls.VideoDisplay class since I use it in the majority of the modules of the site. The overall problem is that I couldn’t force the unloading of the modules while using the ModuleLoader class. Now this wouldn’t be that big of a deal because I could just not unload each module and instead let the ModuleLoader class retain each module’s instance in memory for later use when loaded again. Well here is where the next big problem came into play, for reasons I still haven’t pen pointed while sorting through the module system’s source code, the ModuleLoader class creates a new instance out of the loaded module every time you call it to be loaded and it does this with the assumption that the old module would always successfully unload first. This assumption has rendered the ModuleLoader class useless when you are experiencing a memory leak within a module that you cannot get rid of. What the result of this problem was is a high end flash site that perpetually grows in memory every time you visit a section of the website, regardless if you have already loaded it once. After browsing this site and hitting random sections for about 10 minutes this would bump Internet Explorer’s running RAM usage up to about 350 to 400 mbs which was clearly unacceptable for it would have kept climbing if I didn’t stop. Also to mention the many other problems this caused with reference less modules floating around in memory still doing their “own damn thing” as they please because they were attached to some globally controlled events.

The Solution:

As this major problem needed a solution and a solution quick I took full and manual control of the loading and handling of the modules by dropping the ModuleLoader class and using the ModuleManager class instead. This nifty class allows to you directly work with the IModuleInfo interface’s that handle the loading and creation of each module used. What I did with this was store a reference to the IModuleInfo instance for each module I loaded in an object using the module’s url as a key/value pair map. This way I could check the status of each module I was trying to load and create one and one instance only of each when it was loaded which I then stored the actual display objects generated from the IModuleInfo in a map of their own allowing me to call them up at anytime I needed to. My ending result was a website that took no more than 150 mbs in RAM once all the modules have been loaded once. Not to mention the performance increase as well when you aren’t recreating a new instance of a module every time you want to use it.

I found myself asking the same question over and over lately as I get in to doing more full flash sites. Why is it that there has to be so many differences in the way that Flex and Flash operate and operate together at that. At the moment I will always choose Flex before flash for building full flash sites because of the ease of use it provides when it comes to fluid layouts and other such handy containers and controls. If things like the Box class which is a super class to the HBox and VBox classes were available for use in Flash CS3 then the layout of Flash sites would not be near as difficult.

Like a few other people I found myself dealing with the headache of transition to Flash CS3 applications from Flex every now and again and the one thing that gives me the most trouble is not having the same ActionScript 3 wrappers in Flash CS3 that I do in Flex such as the RemoteObject class for server remoting. There have been a few semi easy frameworks created out there for enabling this type of functionality in Flash CS3 but they just didn’t meet my standards so I wrote one that mirrors the functionality of the RemoteObject class in Flex to a basic level. It is a basic and easy to use wrapper for the NetConnection class in ActionScript 3. You may use the documentation provided by Adobe for Flex 3 Language Reference for the RemoteObject class to better understand this wrapper.

You may download this package here.