:cubicleman.com

Good to see that AIR ‘gets around’. Lifehacker recently listed out 10 apps you should check out.
Top 10 AIR Apps Worth Installing

peas

DK

So, as I continue my trek in Flex Builder Profiler land I discovered a interesting one. Say you have a List used in some component and this List uses a custom itemRenderer and this fancy custom itemRenderer you cooked up uses a inline Style. You crank your application up and with that silly attempt at a sly smile, pat yourself on your back. Then you click that button you have in your app that removes a instance of this component from the display list, yeah, you are working on a pod-like system here, eh? Thinking nothing of it you continue along the trail of happy codeness, that is until you start profiling that app in your most favorite FB Profiler tool. WTF? Your List is never GC’d? I can add 10 of these in the UI as a result of mashing this fancy ‘add new pod’ button and even though that fancy ‘delete me now’ icon, which calls removeChild(), is mashed 10 times, the 10 pods are still hanging out in memory? Yup, shocked me too, actually a good shock as I was falling asleep in front of these memory graphs…hehe.

Assuming my coffee is not laced with the usual ‘make me stupid’ sauce, I filed a bug. Check it out here https://bugs.adobe.com/jira/browse/SDK-15861

peas

DK

I am currently working with a client doing performance profiling and adjustments for a medium sized application. After using the profiler in Flex Builder, a painful experience for me not having worked with such a animal, I found a area that was exhibiting a major memory leak. Well, maybe memory leak is not the correct term, a certain area of the application had a view stack that would add children to it. The user could then remove the children. This removal never released memory. In other words a removeChild() removed the child element, but since the child had some external references to it, this child was never garbage collected.

Now, a few hours digging in the memory profiler didn’t help me find where the nastiness was happening, more on that later maybe. Anyone out there care to shed some tips on this?

Recalling Jun Hieder’s presentation at 360|Flex Atlanta, I started digging into event listener additions, these guys can add a case of the nasties to the situation. That’s when I stumbled upon the use of BindingUtils.bindProperty. The basic approach was that a class A had a property bound to a property in class B using BindingUtils.bindProperty in a util class. This added a hard reference to A in this case, which would keep A from getting GC’d if need be.

This begs the question, why use this? The need here was to inject data into B from A. Probably better to say use A.property = B.property in A or a third party class. If you need it to change at runtime dynamically, have A dispatch a event that can be heard and reacted to, passing the data in the event along the way.

I have attached a sample application that displays the characteristics described above. Use the profiler in Flex Builder to see what happens after manually running a GC. You can grab it here BindingUtils Test

off to refactor!

peas

DK