Enigmatic Thought » 360Flex

Bug hunting in the Flex SDK (part 1)

Matt C — Mon, 27 Jul 2009 16:42:53 +0000

At the 360|Flex BugQuash, I discovered that killing bugs in the Flex framework can actually be easier that trying to decipher some bugs in my own code. How is that possible? Thanks to Adobe’s bug system, some problems are already solved for you, it’s just a matter of initiative to submit the fix to Adobe. Of course it’s not just that easy because there are a few hoops to jump through, but they’re not flaming, and are at ground level. The BugQuash even has a Pre-Event Kit that gets you ready as well. Since Flex 4 is about to go through another cycle, it’s a great time to either fix a nagging bug in Flex 3 (and let it merge down to Flex 4) or, if your feeling feisty, jump into the Flex 4 world. I’m going to put this out in multiple parts so I can hit the details.

The first step is to get familiar with the Flex SDK. If you’re a Flex developer, you’re likely already there, but you haven’t gotten your hands dirty inside the SDK code. Maybe you’ve monkey patched a flex bug. Regardless, working with the SDK is key to the bug fix.

I’m working on a windows client, so I am going to talk windows on the SDK setup. Fortunately, it’s easier to get up and running on OS X thanks to it’s Unix roots.

Download the Source Code. That means getting into the subversion database itself and checking out the latest code there.
1. Install TortiseSVN, a tool that uses windows explorer as the window to the source control world.
2. Create a directory (I used C:\osFlexSDK) to svn the source code to.
3. Download Adobe’s Flex project skeleton and unzip it to the directory. This will give you the trunk, branches, & tags directories
4. (for Flex 4 work) navigate to the flex\sdk folder and right click on the trunk. Select “SVN Update”
5. (for Flex 3 work) right click on the branches directory and hover over “Tortoise SVN” and select repo-browser. right click on the 3.x folder and select checkout. Click “OK”.
Now that we have the source, it’s time to make sure we can build it. This is where I tripped up and saw some others tripped up at the BugQuash. Building should be a simple affair, especially since it’s just running ant from the command line. I’m using Adobe’s Setup on Windows guide as a baseline.
1. Install Cygwin. The key is on the screen where you select the directory. On the bottom right of the screen there is a selection for Default Text File Type. You must select DOS/text.
2. Install the proper Java SDK for your build 2.4.2_14 into C:\j2sdk1.4.2_14 for Flex 3 and 5.0_13 into C:\Program Files\Java\jdk1.5.0_13 for Flex 4
3. Install Ant (a straight unzip) for your build 1.6.2 unzipped into C:/apache-ant-1.6.2/ for Flex 3 and 1.7.0 unzipped into C:/apache-ant-1.7.0/ for Flex 4
Now rig up the flash player for development use.
1. Create the mm.cfg file in the C:\Documents and Settings\
  directory if needed and add the following lines to it:
  ^?Download mm.cfg
  ErrorReportingEnable=1 TraceOutputFileEnable=1
2. navigate to the C:\WINDOWS\system32\Macromed\Flash directory. Create a FlashPlayerTrust directory is there isn’t one there already and create a FlexSDK.cfg file with the following line:
  ^?Download FlexSDK.cfg
  C:\
  You can change drives or even directories if you aren’t using the C drive for development, or even have multiple drives. Adobe suggests being as restrictive as possible for security reasons.
Test your setup. This is the “easiest” part since it’s pretty much a pass/fail.
1. Run cygwin shell and navigate to the folder you want to build. Note: All drives are under /cygdrive so c:\osFlexSDK\flex\sdk\trunk is /cygdrive/c/osFlexSDK/flex/sdk/trunk.
2. Type “source setup.sh’ to set up the environment variables
3. Test Java by typing “java -version” and make sure you’re on the right version for your build. If it reports and error, make sure you installed Java in the correct directory.
4. Test ant by typing “ant-version” and make sure you’re on the right version for your build. If it reports and error, make sure you unzipped ant in the correct directory.
5. If everything checks out, type “ant” and let the build happen
You should now have a built Flex SDK in the bin directory. Congratulations!

This is continued in part 2

Flash Builder 4 delay doesn’t impact Catalyst

Matt C — Tue, 21 Jul 2009 15:27:13 +0000

With the news that the Flex 4 beta is going to have a sequal which will delay Flex 4 & Flash Builder 4 until 2010 you may wonder about Catalyst. Since the fancy demo at 360, I’m looking forward to playing with it. Especially since Matt Chotin promised the code it produced would actually be usable. Well, Simon Bateman mentioned both Flex & Catalyst via Twitter whether the change would impact Catalyst, and Chotin replied Just to clarify, this date change doesn’t affect Catalyst. I assume that means Catalyst wasn’t going to show up until next year anyway since it’s “Based on the open source Flex 4 Framework”.

Cairngorm v. Mate: why can’t we be friends?

Matt C — Fri, 17 Jul 2009 15:06:18 +0000

At Flex Pasta there was an interesting post ( Mate Framework: Should it be the new standard in Flex 4?) about Mate and how it should overtake Cairngorm as the framework of choice for Flex developers. I know it was the choice at the Charity Code Jam at 360|Flex Indy. When talking frameworks no one really wanted to go down the Cairngorm road, primarily due to time constraints. Unfortunately, we ran into a different problem, no one really knew Mate, at least well enough to really drive things until the single “Mate Expert” that had championed the framework returned. I know that has nothing to do with Mate’s feasibility, but it left a somewhat bad taste in my mouth. I still plan to learn about Mate, but it’s not on my rush list.

So, while Brian is gung-ho about Mate, I’m much more hesitant. I know Cairngorm and all my current projects use it. The conversion from Cairngorm to Mate may be impossible (or at least overwhelmingly difficult) in my current work environment. There’s also the barrier to knowledge of the team, having to change mindsets from the singleton pattern to an injection pattern. However, for new projects what is the choice?

His biggest pro-Mate point seemed to be a point for Cairngorm in my book. Mate has had 17 releases in the past year, while there are no Cairngorm releases and only 15 commits to its subversion repository. That tells me Cairngorm is either dead, stable, or both. Since I’m sitting next to a Book (Professional Adobe Flex 3) published in the last month with a 4 chapter section on Cairngorm, I’m pretty sure it’s not dead. Brian also says the code is quite stable but there isn’t a 1.0 release. I think 17 releases and “hundreds of commits” tells another story. Those commits are either bug fixes or features but it’s obvious they’re still working on the code. Nothing wrong with that, Rome wasn’t built in a day.

Interestingly, he talks about Cairngorm as if it’s the default Flex framework. However, this article on choosing a framework, hosted on Adobe’s Developer Connect site, talks about 4 frameworks (Cairngorm, Mate, PureMVC, & Swiz) with pros and cons of each. Of the four, I’ve only dealt with Cairngorm enough to use it effectively. Other than my Mate experience at 360|Flex, I haven’t really done anything with it. I’d used PureMVC in a little learning side project but only succeeded in confusing myself until I “got” it and realized that I was doing a lot of things wrong. Rather than rework something I didn’t have any real need for I just let it slide.

I think the idea of Cairngorm being the “Adobe Framework” has more to do with it’s pervasive nature across projects due to the “first out of the gate” status and being hosted on Adobe’s servers. There’s nothing that forces Cairngorm on people, it’s just a result of the age. If Mate’s future is as bright as it looked at 360|Flex I’m sure we’ll see someone blogging about Mate being “old and dusty” in the future while some hot new framework is breaking ground somewhere else. Just don’t complain when Mate is stable and doesn’t need a new release every month.

Back from 360Flex

Matt C — Wed, 27 May 2009 22:27:35 +0000

I highly recommend the 360 Flex conference. Unfortunately there won’t be another one until next year (in the past they’ve been semiannual affairs). My experience was great, with to little sleep and a who lot of Flex. I did some work in the charity code jam and, as you can see in the previous post, quashed some bugs. I’ve got lots of frameworks to check out once my workload lightens up. I came back to a herd of bug reports since we’re in the testing phase of our current product.

Next week is a real vacation, so I know I’m not going to get much done, but I would like to do some write ups on some of the frameworks that intrigued me at 360Flex. Here’s what’s on my plate:

Axiis, a data visualization framework
Structured Log Testing, a logging system allowing external applications to plug in an pull logs.
Degrafa, we already use it, but I really don’t know all the ins and outs
BirdEye, another data visualization framework. Mentioned at the Degrafa talk

That’ll keep me busy, plus I’ve already got a Mashup in mind, so I’ll be digging through Programmable Web at some point as well.

Bug Quash

Matt C — Tue, 19 May 2009 13:34:25 +0000

I participated in the Bug Quash at 360|Flex. Well, technically it was a day before the conference as a pre-conference event. It went really well and I personally killed 3 bugs.

SDK-21202 was the fix to a pet bug of my friend at Flex Ninja which he pretty much assigned to me when he heard I was going. The problem is that event listeners of NavBar children aren’t removed, which means if you change a label or icon or such on a child that was removed, the function will be called but then you’ll get a crash since the child is no longer there. It was easier since the workaround was already there as well.
SDK-21204 was the same bug, only with accordians. Ryan Frishberg actually pointed this out to me, which meant another similar fix. Ryan was at the Quash from adobe to help speed up the patch acceptance process, but he also discovered that a strange guy (me) would be harassing him to look at stuff.
SDK-21211 was an interesting bug to look at. It turns out that there wasn’t a default setting for the border of tooltips. Even better, the border is what triggered the drawing of the background box. That meant if you used any non-standard border, you’d loose the background. The fix was pretty easy, just make the default value for a tooltip border “toolTipBorder” the default all the time, not just when the border is set to “toolTipBorder”.

Final Thoughts? Flex SDK Bugs actually aren’t that bad to fix. You just have to find stuff that’s simple and try not to overthink what’s going on. Then submit a patch and hope it’s accepted. It’s a little overwhelming to look at the entire SDK, but you don’t have to worry about the whole thing, just deal with your little window, monkey patch a fix first in a simple Flex project (some bugs even have test cases you can use) then once the patch works, tie it back into the SDK itself.

I submitted another patch (SDK-21207) which was rejected, but it had some nice feedback. I’ll probably revisit it and try it again sometime in the future.

Enigmatic Thought » 360Flex

Bug hunting in the Flex SDK (part 1)

Related Posts (generated):

Flash Builder 4 delay doesn’t impact Catalyst

Related Posts (generated):

Cairngorm v. Mate: why can’t we be friends?

Related Posts (generated):

Back from 360Flex

Related Posts (generated):

Bug Quash

Related Posts (generated):