Just Flex » Flex

unload you module

justversus — Fri, 24 Jul 2009 09:23:34 +0000

If you are using modules in your application sooner or later you will get some nice memory leaks, 100% guarantee. It's "simples", not much effort required, just add TextInput to your module. The FocusManager keeps references to all focusable components in private focusableCandidates property (SDK 3.4.0). When you are trying to unload your module, the FocusManager doesn't revalidate the list of focusable candidates leaving references to one or more components owned by the module. Unless you explicitly set focus to any other TextInput outside the module before actually invoking unload procedure, the module will never get garbage collected introducing some nice source of memory leaks.

The issue has already been reported to Adobe Jira by my colleague from the previous project. The bug exists in Flex SDK 3.4.0 and 4.0.0 as well.

I assume you vote to prioritize this issue as it is very serious bug stopping any developer from utilizing modular infrastructure in flex applications.

name and shame

justversus — Mon, 18 May 2009 14:40:01 +0000

Here we go, Flex Builder has died.

The mistake has been made, we’ve done a step back in RIA wars, 1 point to Microsoft and Silverlight with their consistent tool naming and development concept. Adobe – well done, let’s scare off all the guys from Java, .NET, Ruby and PHP world who had/will have some interest in developing with Flex/ActionScript, with that new ‘ueber-kool’ Flash Builder nonsense.

Big caliber Flash guys like Serge Jespers, Lee Brimelow, Duane Nickull, Mark Doherty, Tim Buntel or Ryan Stewart sing odes to the coolness of new name, but they are all missing one important point – it’s not about developers with flash background anymore. There are too few of us, but millions of Java and .NET developers, and they actually matter. And those developers need to be converted and persuaded to use Flex not vice versa. They could be potentially interested in this new thingy called Flex but that ridiculous new name will just scare them off.

Guys, especially Adobe Evangelists, stop repeating the same old mantra about Flash Platform and Flex SDK and actually name the tools properly from the beginning.

The actual comments that I’ve heard today in the office:

What tool will I need to use if I want to create Flex/ActionScript application? Will it be Flash or Flash Professional, or Flash Catalyst or maybe Flash Builder and why is the word flash everywhere?

Flash is highly associated with animation and stupid banners so for most of new developers (read Java, C# and .NET in general) it sounds as the tool for annoying banners or skip intro productions. And do not tell me that they have no clue about what flash platform actually is and they have to attend ”what is flash” seminars (say hello to Tom Krcha) – this is Adobe's responsibility to name its tools properly and market it reasonably.

The word Flash has really bad historical luggage of being stupid banner/skip intro production tool and just can not be seriously considered in financial/enterprise world. Adobe has to get rid of Flash Player's name and change it to something more serious, e.g. Flash Runtime.

It’s not a big deal after all - it's just a name. But on the other side it’s a huge waste of resources on marketing, rebranding, promoting etc. Those resources could be used to develop IDE that works like Visual Studio or IntelliJ IDEA.

But never mind, maybe in next life there will be some decent quality Flex/ActionScript IDE properly named.

Update: Very interesting post on this topic by Konstantin Kovalev

clean up your garbage

justversus — Sun, 15 Mar 2009 21:35:35 +0000

We don't live in an ideal world where flash player's garbage collector understands our brilliant ideas and our incredibly genius way of coding flex applications.
As you may already know, using weak event listeners with modules and pop-ups often results in memory leaks. It's really painful to fully remove modules from memory if in-line styles, effects or focus enabled controls are present in the module.
Unfortunately, it's all up to the individual developer. Here in Lab49 we use IDisposable interface that every disposable domain object, presentation model or view should implement.

 
package com.lab49.core
{
   public interface IDisposable
   {
      function dispose() : void;
   }
}

The main concept is very simple - every parent cleans up itself, its presentation model and calls 'dispose' method on its children if it's applicable.

 
implements="com.lab49.core.IDisposable"
   layout="absolute"
   close="dispose()">;
   [CDATA[
	      import com.lab49.core.IDisposable;
	      import com.lab49.example.model.BasePresentationModel;
 
	      [Bindable]
	      public var model : BasePresentationModel;
 
	      public function dispose() : void
	      {
	         //remove all event listeners here, stop all effects, clean up model
	         if ( model )
	         {
	            model.dispose();
	         }
	         //Clean up children
	         var children : Array = getChildren();
	         for each( var child : DisplayObject in children )
	         {
	            if ( child is IDisposable )
	               IDisposable( child ).dispose();
	         }
	      }
   ]]>