Silverlight vs Flex (or, Why developers hate flash)

25 05 2008

Now *this* is an argument.

I’ve already seen some great points put out in this debate, although I’ve also seen some very indignant and irrational responses to the argument. Microsoft vs Adobe? or, Why do developers hate Flash?

I guess all those hours of frustration sitting in front of Flash (insert version number here) trying to figure out the most inane bug has caused most developers to cast Flash out. (I know I did).

And that by seeing Microsoft’s rather successful business plan of watching and waiting for fantastic ideas to come along before improving them and labelling their own, causes others to vent in hostility  (thanks Apple for Windows, Java for C# & .NET, Adobe for the Expression tools and Silverlight, Google least of all for Maps, etc.)

But if we look at this argument rationally, it’s clear that we developers will benefit from this contest.

Developers should, by their nature, be adaptable.

Instead of jumping the gun to defend our current choice of RIA software, we need to investigate the technologies as they appear and as they are improved. So that when it comes to making the perfect product, we choose the right tools for the job.

Blog Directory - Blogged

Flex/AIR Memory Profiling

15 05 2008

I’m entering the final stages of testing of my most recent Flex app and decided to start profiling this week. Everything I have since read on it suggests: Profile early, Profile often.


Well, apart from spending almost two days pondering memory usage graphs (my major problem were significant memory leaks), I managed to get there and fix my major memory issues.

As it turns out, my major issues came from strong event listeners between static classes (my Remote Object services) and my modules. Garbage collecting modules is like components, you still have to ensure no other living parts of your application reference anything you’ve destroyed.

Stupidly, I spent a fair deal of time focusing on components that were added by my modules and were taking the most memory, instead of concentrating why the module itself was still residing in memory after i’d destroyed it. (The memory graph was nasty, lemme tell you).

One thing that I discovered after all that pondering, is that I would hope Adobe could clear up which references are strong and which aren’t. Looking through tens to hundreds of references

I am curious in the Silverlight vs Flex debate how well MS’s solution handles memory leaks and what options are available for profiling. I’m also interested to see how Adobe improves the Flash player now that they’ve created such a better model for developing Flash content: developers working in Flex/AIR, with the designers in Flash.

Flex/AIR, event listeners, weak references and memory leaks

12 05 2008

I’ve just been reading a book on Flex and came across a great point in the memory management department. That I think everyone should be aware of.

The book is Adobe® Flex™ 3: Training from the Source.

The great point is on memory leaks with event listeners.

Essentially, by creating a generic event listener on some object causes it to continually be referenced even when it is no longer used and therefore the memory is not reused by the Flash Garbage Collector.

Of course you can use the removeEventListener() method, but the point here was that you could also use weak references. Weak references are those that do not cause the GarbageCollector to bypass the memory. Essentially, without a strong reference to an object, the Garbage Collector can reuse that portion of memory next time you request some in Flex by instancing a new object.

You use weak references by calling addEventListener() with extra arguments. For example, if you wanted to handle the Complete event with a weak reference, you’d use:

addEventListener(Event.COMPLETE, onComplete, false, 0, true)

Just use the default values for the 3rd and 4th parameters – useCapture and priority – but use true for weakReferences.

Reading David Coletta’s blog, a very important note is NOT to add a weak reference to an anonymous listener.

Eg. the following code will not work as the anonymous function will be removed because it doesn’t have a strong reference and will go out of scope.

someObj.addEventListener(Event.COMPLETE, function(evt:Event):void{'Complete');}, false, 0, true); //doesn't work!

Another great point is that, in general, member variables do not require attached listeners to be weakly referenced.

This means you don’t have to go out and remove all of those click events on your Buttons declared in MXML, replacing them with ActionScript addEventListener calls because if the listener lives inside the same class, then they both die together.

In other words, if you’re application or component has a child that attaches a listener declared in the same class, then the strong reference won’t inhibit Garbage Collection if that containing instance is removed.

For example: Say I have some component I call MyControl.mxml




private function doThis(evt:Event):void






<mx:Button click=”doThis(event)” />


Then I use it in my application thusly: (Application.mxml)

<mx:Application creationComplete=”onCrtComplete(event)”>



import com.justinjmoses.examples.weakreferencing.MyControl;

private var myCtrl:MyControl;

private function onCrtComplete(evt:Event):void


myCtrl = MyControl(this.addChild(new MyControl()));


private function removeIt():void



//now the entire control is available for Garbage Collection




</mx:Application> >

Now, when removeIt() is called, the component, MyControl, along with the Button and the listener inside, have their references removed, and are candidates for Garbage Collection.

Adobe AIR and the iPhone

11 05 2008

Recently I was at an Adobe conference in Sydney. The conference was aimed at media professionals and was all about the Flash Media Server. I felt like a fish at a fashion parade with all the video-editing talk, but there were some very juicy titbits dropped along the way.

During the conference, the news bomb was dropped that Adobe had removed licensing from their SWF and FLV formats. This is under their new “Open Screen Project” which is aimed at getting Adobe Flash content out there on all screens, without manufacturers having to pay licensing fees.

When I asked about the iPhone and AIR, I was told by a Senior Consultant at Adobe that their hope with the OSP was that companies such as Apple would now consider deploying the Flash Player (or Flash Player Lite) onto their devices. He finished by adding that who knows, maybe even Microsoft would develop their own Flash player (with his tongue firmly planted in his cheek). From a managed-code development point of view (Java/C#/AS3 in the MX framework), this is exciting stuff. Fingers crossed, we can develop our AIR apps to work in the iPhone as well.

Of course, in the iPhone’s case, Apple has opened the SDK for developers (currently with a $100 price tag and a US only limitation – boo.) But what developer, settled into OO principals and managed-code, wants to go back to C++ style coding with Objective-C? OK, I’m sure there’s a few of you out there, but personally, it feels like going backwards.


I’ve got pages of questions for Adobe when I hit their AIR conference next month (also the month that we all suspect the iPhone to be released in Australia), so hopefully i’ve have more answers then.