Do you use the public Flex bug base?

| 1 Comment | No TrackBacks

If you're not familiar with the Flex Bug and Issue Management System, you need to do yourself a favor and get involved.

As I've spoken about before, when the Open Source Flex initiative was first announced one of the things I was most excited about was the opening of a publicly accessible issue management system. I've touched on a little bit of my reasoning here, but wanted to call attention to how awesome a system like this truly is.

If you use Flex day in and day out like I do, chances are you're going to run into issues or things that you think can be improved. That's just the nature of software development. Having access to the public bugbase allows you to be actively involved in identifying issues and helping to improve the product for other developers. Better yet, when you encounter a problem it allows you to defer the work of fixing or working around the issue to Adobe.

Let me share an example to demonstrate what I mean.

Earlier this summer I ran into a strange issue with the DateChooser component. Code that should have worked was failing for no apparent reason.

I opened up a web browser to the Flex bugbase,, and searched for the issue. There are a lot of search options here, but I just used the "Quick Search" to get started looking, and then narrowed down via the extended options.

After searching for my specific issue, I didn't see anything related to the problem I was having. This meant that Adobe was not aware of a potential issue. So, I created a new issue describing my problem.

The process for creating a new issue is really straightforward. Use the "Create New Issue" link and just describe the problem your encountering. Having sample code to reproduce the problem really helps well. When you're done creating the issue it gets assigned an id.

For my particular issue, it was assigned SDK-12004. Since this issue was affecting my ability to complete some code I was working on, I was really interested to find out what Adobe thought and I wanted to be notified if anything changed on the issue. I clicked the "Watch it" link so that any changes to the issue would be emailed to me.

By watching the issue I was able to see it move through the Adobe QA system. I knew who was looking at it and what their thoughts where. I was emailed anytime someone commented on the issue, and ultimately I knew when it was fixed. In this case, another bug was found that was related to my original report but not quite the same, so SDK-12008 was opened as well. I opted to watch that issue too since it also affected what I was working on at the time.

When I saw that the issue was resolved as fixed, I found the comment with the associated build number of the fix. Here's where things get really interesting. The particular issue was listed as working fine in build 179224. Sweet, but where's the code for that?

Did you know there are nightly builds of the Flex SDK?

Did you know that when an issue in the bug system is fixed, you can grab the code for the fix from the nightly SDK having a build number greater than or equal to the issue's "fixed in build" number? You have to agree to the terms of the early build access license, but once you click the checkbox for that there is a matrix at the bottom of the page that populates with links to download the nightly build. Even better, there's a change log for each version.

I scanned the change logs looking for the change set that related to my SDK-12004 and SDK-12008 issues. When I found it, I made note of the files that were changed. Then, I downloaded that particular nightly build that contained the fix.

I should note here that the nightly builds are actually for the upcoming Flex 3 SDK, but my current project is still using the Flex 2.0.1 hotfix 3 SDK.

I used the "underriding" technique that Doug described here to apply the changes to my current SDK. Essentially, I took the code for the files that have changed and created versions of them in my local project. My project now has an "mx.controls.DateChooser" class defined that contains the code from the nightly build. Because it has the same fully qualified name as the default DateChooser in my Flex 2.0.1 hf 3 SDK, the version in my project takes greater precedence and it is what gets compiled into the ptoject and used.

This allowed me to apply only the the relevant changes from the nightly build without affecting the rest of my installed SDK. It took a little bit of effort to remove some of the "Flex 3" features from the updated code to downgrade it to work with the Flex 2.0.1 hf 3 SDK, but it wasn't a difficult process.

If you're already using Flex 3, it's even easier to apply a nightly build. In fact, you can just add the nightly build as a new installed SDK in FlexBuilder 3 and simply recompile your project with that SDK to incorporate the changes. It was only because I'm using an older SDK that I had to go through the process of manually applying the changes.

To summarize:

1. I ran into a bug
2. I looked to see if it was a known issue or already fixed
3. It wasn't, so I told Adobe about it
4. I watched the bug to keep informed of its progress
5. Adobe developed a fix for me
6. I downloaded the nightly SDK that included the code for the fix
7. I applied the fix in my project
8. All is well

A positive side effect here is that the fix now goes out to all developers who will be using the Flex 3 SDK going forward. By identifying issues and being involved you not only help yourself by getting Adobe to do the work for you, but you also help the entire Flex community by allowing Adobe to continually improve an already amazing product.

This process isn't limited to just bugs. If you think something could be done better, log an issue for it. It will get prioritized, and Adobe might even take your advice and build the enhancement into a future version.

So, if you haven't been using the Flex bug base, isn't it about time you start?

No TrackBacks

TrackBack URL:

1 Comment

Yes, Just yesterday I post a bug related to AMF.

To reproduce this bug you can find the project files here.


Leave a comment

About this Entry

This page contains a single entry by darron published on September 21, 2007 12:30 PM.

On [Transient], ObjectUtil.copy(), and Casting was the previous entry in this blog.

Hooking dispatchEvent for Cairngorm Events is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


OpenID accepted here Learn more about OpenID
Powered by Movable Type 5.02