This is probably old news by now, but I just found out you can implement an interface in an MXML component. In the past I’ve always made a base class that implemented the interface and had the MXML inherit from that. A big waste of time for small components.
-
<?xml version="1.0" encoding="utf-8"?>
-
<mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml"
-
implements="com.roguedevelopment.schedule.ui.ApplicationView">
-
…
-
</mx:Canvas>
You just need to add an “implements” attribute to your root tag and specify the full class name. I’ll stick to the base class for large components, but this is the way to go for small, quick things.
I’ve been learning some Flex 4 stuff over the past week. One word… wow. Even without Catalyst, this is going to speed up my development a lot. Things like skinning a button with a complex code generated skin is now easy. I’ve been working on a site for my Wife’s budding photography business over at: Jessica Hughes Photography
It’s still a rough site, but I figure Flex 4 took me about the same amount of time to make it as it would have in Flex 3, but that includes learning about all these new features.
Today, I happened to have Activity Monitor open while I was working on AgileAgenda and noticed something peculiar. It was sucking up 200% of CPU time (multiple cores…)
So I fired up the application in the Flex profiler. Let it sit for a minute, clicked the “Reset Performance Data” button, waited another few seconds, and then clicked the “Capture Performance Data” button. The result was odd.
Nothing was actually in code I could touch and didn’t explain why it was happening. There had to be something going on to peg out the CPU like that. So I hit up the Flex preferences panel and found something I had forgotten about.
By default, the profiler excludes a whole bunch of flex and flash related classes from the profiler. So I removed those exclusions and unchecked the box. Went back to my profile window and low and behold, this is what I saw:
So now I had an idea of what was happening. It looks like that indeterminate progress bar (which wasn’t on the screen anymore by that point) was sucking up some render time.
So I peeked at the ProgressBar flex code. They’ve got a timer in there that gets started, and is stopped when the progress bar is set to invisible. But that doesn’t end up accounting for cases where we just bump to a different parent object in a view stack. So that timer sits there, happily spinning and consuming resources.
I added some code in to manually set the visiblity of the 2 indeterminate progress bars I had and ran. Bamn, success.
So I learned (or re-learned?) two things today.
- When profiling, if you don’t see anything happening check your filters.
- Be very careful with indeterminate progress bars in flex.
Note: I got similar results both in the debugger (ADL) and when running the application stand-alone as a bundled application.
