I had seen references describing how to do this, but hadn’t seen a complete example, so I whipped this one up for a customer.

Using RemoteClass metadata triggers code gen in in the compilter to ensure that the class is registered with the VM before the application can use it, this includes receiving it from a network request. The only case in which this could be a problem is if it was being used with remoting and there wasn’t a corresponding server class that also implemented the flash.utils.IExternalizable interface.

Externalizable interface doesn’t effect the ability to be serialized in AS3, it just provides customization of what gets serialized. Generally it is only used to serialize private data or hide public data from serialization. Marking the class with [RemoteClass] is what allows the typed serialization of the object (again just mxmlc code gen at the right point using the registerClassAlias() method).

There aren’t any issues, at least none that we have hit, with LSO storage and custom serialization using IExternalizable. As long as the SWF that is retrieving the data from the LSO has the IExternalizable classes linked in and registered (potentially with a “dummy variable”) then I don’t know of any reason why that wouldn’t work.

The real work behind the scenes is done by using flash.net.registerClassAlias() and it is documented (although hard to find) at:
http://livedocs.adobe.com/flex/201/html/lsos_087_3.html

Browse the source of this example.
Download a zipfile containing the source to this sample.

Read the rest of this post»

Grant Skinner has rehashed some of the content from his site into 2 articles on Adobe’s devnet. I think most of the content is the same, just better organized and presented:

http://www.adobe.com/devnet/flashplayer/articles/resource_management.html
http://www.adobe.com/devnet/flashplayer/articles/garbage_collection.html

I have been asked about this from various different angles and responded to it (often with ammo from others) in various different ways. I have decided to compile all info I can as a starting point to address questions hat typically come up from Flex customers regarding Flash Player Memory Management and Flash Player Garbage Collection.

CAVEAT: I am not a Player engineer and haven’t looked at the Flash Player code, but this is my understanding from several discussions with the engineers on the Flash Player and Flex Teams. (Some of this info is taken directly from emails, forum postings and conversations I have had with Alex Harui, Matt Chotin and Gordon Smith.)

Also, Grant Skinner goes into far more detail on his blog about Flash Player Memory management and Garbage Collection.
If you want to know more than the high level that I am going to address here you should check out his blog entries:

http://www.gskinner.com/blog/archives/2006/09/resource_manage.html
http://www.gskinner.com/blog/archives/2006/06/as3_resource_ma.html
http://www.gskinner.com/blog/archives/2006/09/garbage_collect.html

The underlying Flash player is essentially a garbage collection memory model. That means that if nobody has a reference to an object, it will be collected and thrown out eventually. Thus, you never have to delete anything, just make sure all of your references to it are broken by removing objects from the displaylist, removing event listeners or using weak listeners where appropriate.

The Flash Player runs within the browser’s memory space and Firefox or IE give memory to the player. The browsers are then responsible for the memory and will release it to the heap.

Here is a general description of what is generally going onwith memory management as an app runs:

The Flash Player grabs OS memory in large chunks, divides them up into smaller chunks and allocates those small chunks to the application. As the number of small chunks dwindles, the player runs a GC pass to see
if any of those small chunks can be freed before we go to the OS for another big chunk. If the application is idle and nothing is accessing memory, nothing is going to force a GC pass so nothing will ever get freed.

So lets say the Flash Player allocated 40 megs. If the app happened to get to 33 megs there may be no need for the Player to GC. And it could be that in reality the Player could get away with only 20 megs, but it will take that whole 40 b/c the OS is letting it. Still not technically a memory leak, even if you think the Windows Task Manager should show less.

The MemoryMonitor tries to force a GC pass (see the hack comment in the code). It is unclear as to whether the hack works perfectly.

GC is opportunistic. This means it does not run all of the time. It tends to be triggered by allocating memory instead of freeing it, so watching an idle app will almost never result in GC. Because of the fact that GC is more or less “opportunistic”, there is no current way to manually test for memory leaks. I think there are situations where lots of activity forces several large chunks to be acquired from the OS and then, when most of that stuff is freed, each of the large chunks has a few small chunks still in use and so the OS chunks are not released back to the OS because there isn’t enough activity to cause a GC pass. Therefore, the only way we “prove” there is a memory leak issue is to use MemoryMonitor’s callback to repeat a sequence over and over again.

Now, lets look at an example.

Read the rest of this post»

I have been asked this a few time by customers and figured this was worthy of a quick post:

The release and debug player cannot co-exist on a machine.
(You can’t have release and debug activeX or release and debug plugin installed at the same time, but you can have release activeX and debug plugin)

A player (plugin/activeX control) with the same version#, regardless of debug or release type cannot upgrade an installed player with the same version#. You must first uninstall the player then install the other version of the same player# to switch between release and debug player of the same version#.

The debug player is not available to the general public; it is only available within purchase products (like Flash Authoring, Flex Builder, FDS).

A debug swf will run in either player, but only produce trace and throw RTEs in the debug player.

You can determine what version of the player you are running from within a Flex app using the following code:

RSS feeds are a good way to stay on top of news regarding your favorite product.
This is a good way to stay aware of the latest tech notes or new product announcements.
I encourage all my customers to subscribe to Flex, Flex Builder and Flash Player Feeds.
These feeds and others from Adobe can be found here:

http://www.adobe.com/support/rss/

I’ve been asked this by at least 4 customers and provided them with simple samples that set the stage.quality = StageQuality.BEST. This provides smoother image scaling, but at potentially some performance cost. You also have to use the loaded image’s content property, casting it to a bitmap in order to scale it. I don’t recall exactly where I found the info on this, but I Googled and didn’t find a good reference for doing this, so I thought I’d post my own solution.

Check out the code snippet: