w00t! 2009 World Champion Flex Bug Quasher!

So I "won" the Flex Bug Quash in Seattle last weekend.

Shouldn't Adobe fix their own bugs? Why work for free?

I don't. Adobe doesn't. I get paid to deliver engaging user experiences for our clients, and most of my development work is Flex based. I have benefitted from the great community of Flex developers and it's time to pay it forward a bit.

I use a fair bit of open source software in my work, and I think contributing to the source code base is a good thing. Plus, I also used the opportunity to fix a couple of bugs that had been causing me pain in past projects. So it was self-serving open source work?

Road Trip!

I help organize the monthly Vancouver Flash Platform Meetup with Ross Ladell. During a recent lunch, nay, drink we realized that the Bug Quash event was being hosted in Seattle, rather than in the Bay area like I had assumed. So we declared it road trip worthy, and I rented a van for the day. Well, EffectiveUI rented the van, aren't corporate cards wonderful?

A bunch of us Vancouver geeks drove down to the Adobe Seattle office to represent Canada. It was a pretty quick drive (border hassles not included) and a fun way (what a geek!) to spend a Saturday. Ross met us down there and the folks from The Active Network were also there. So about 10 of the 30-ish bodies in Seattle were from Vancouver. Nice.

I win!!! Umm ... define "win"

All of this hinges on a very loose & liberal definition of what "win" means. I submitted the most patches that day, 5 in total. So given that metric, I won.

A former boss told me to remember that "fair" and "simple" are at opposite ends of the spectrum. Simple systems usually aren't fair, and fair systems usually are complex.

So counting the number of patches submitted was the easiest thing for the Bug Quash organizers to do, they were already doing it so that we could all watch the big numbers go up as patches were submitted throughout the day.

But submitting a bunch of patches doesn't mean that I'm did a lot of work. I don't think I was the most productive quasher there. I'd much rather see a few really hard problems fixed in the SDK than have some submit a bunch of executable semi-colons.

So what did I fix?

But I really couldn't describe my contributions as huge or high visibility. I just stayed focused in one area of the SDK (DateFormatter and some related classes) and knocked out some low hanging fruit.

1) DateFormatter "HH" shows 24 not 00

SDK-16076 - This didn't even require a code change. It wasn't a bug. The "HH" pattern shows hours in 1-24, the "JJ" pattern shows hours in 0-23.

All the comments said "Not a bug. close it". So I submitted an empty patch with a comment of "then CLOSE it already!". My patch was was rejected as a bit of an abuse of patch submission system, but the bug was closed anyway. I wasn't trying to be a jerk, but there wasn't any other clear way to mark/flag the bug for review. I'm not fond of bug lists that contain a lot of noise.

Total bugs quashed: 1
Total lines of code changed: 0

2) Make DateFormatter.parseDateString() a static public method

SDK-16902 - Yup. All this involved was changing "protected" to "public". +2 for me!

Total bugs quashed: 2
Total lines of code changed: 1

3) Fixed CalendarLayoutChangeEvent ctor

SDK-18567 - I hit this bug a couple of weeks ago, while writing a custom calendar control. The constructor for the CalendarLayoutChangeEvent was ignoring some of its parameters (like the new date, ouch!) so the net effect was that you had to set the date property manually, after the event was constructed. This class was only used once inside the SDK and the flow of control through that method meant that the date property was always being set after the event was created. So the SDK was (inadvertently, I think) working around this bug.

In addition to this two line fix, I also reviewed the SDK code for all the other classes in mx.events.*, just to be sure that this pattern wasn't repeated elsewhere. Nope. That was the only gotcha I could find. Which makes sense, since the other event classes are heavily used within the framework and bugs like that would have been caught early on.

Total bugs quashed: 3
Total lines of code changed: 3

4) Fixed parsing of GMT+x date string

SDK-13650 - This one took a bit more digging, and a whole lot more thinking. The patch I submitted on BugQuash day was rightfully rejected the first time. It actually wasn't until I wrote this post that I noticed that my original patch was rejected.

The original test case was using the AdvancedDataGrid class, which is part of the closed-source data visualization library. That meant I couldn't test the fix with the 3.x branch, since there was no 3.x datavisualization.swc to link in.

So I punted and did a HailMary commit. Which broke. Ugh.

Thankfully, Alex posted a much simpler test case, one that didn't require the closed-source SWC, so I quickly fixed my fix (I had neglected to escape the plus-sign in a regular expression) and submitted a new patch.

Total bugs quashed: 4
Total lines of code changed: 4 (see the method to my madness yet?)

5) Programatic HTML markup of Labels gets lost when truncateToFit() triggers

SDK-14982 - This is a bug I hit and reported about a year ago. When I reported the bug, I also included a fix. If you've set any markup via the htmlText property and the label needs to be truncated, all the formatting gets lost. The fix still isn't 100% but it is better than before and it is not any slower in the success case.

Total bugs quashed: 5
Total lines of code changed: 19

Did I deserve to win? Don't get me wrong. I like trophies!

Oh, I'm keeping the title belt. I'm claiming the (self-assigned) title of "2009 World Champion Flex Bug Quasher", at least until someone else comes along to push me off the top of the hill, attention-whore that I am.

Thanks to all the little people!

Thanks to Adobe for putting on the event.
Thanks to all the fun folks we got to hang out with at the Seattle offices.
Thanks to the Vancouver devs for kicking ass and claiming "first blood" (way to go Myo!).
Thanks to Karl for helping me setup my dev environment so I could finally build the SDK properly.
Thanks to the US Border Patrol officers who joined in our let's-bash-MSoft-fest at the border (nice to get the lads with the sense of humor for a change).

Free Flex and AIR resources? We can haz!

Free AIR and Flex training. Bring it on!

Fellow Vancouverite Duane Nickull informed me that the sessions he was running at both MAXen (MAXes? What is that the correct pluralization? Where's RubyOnRails when you need it!) are now available online.

The AIR Boot Camp session is intended to give you an overview of how you can leverage your existing Web developer tools to create desktop apps using the AIR platform, including the recently released AIR 1.5 runtime.

The Building Flex service clients session gives you an overview of consuming web services from a Flex app, with links to preconfigured WAMP and MAMP stacks to test against.

Also, make sure to check out the great Tour De Flex app, available both as a standalone AIR app, and an eclipse/FlexBuilder plugin.

Don't be fooled by the default view in Tour De Flex. At first glance Tour De Flex looks like a less full-featured version of the Flex Style Explorer, but check out that combo box that says "Flex Core Components". Other choices will reveal live apps and sample code for consuming well over a dozen popular clouds APIs like Twitter, Flickr, and Amazon, as well as demos/samples for Google/Yahoo/Mapquest maps.

Got something cool to share? Submit it to the Flex.org form and it may show up in the next publish phase.

Quickly change the font size in Eclipse: Handy for presentations!

The internet fairies were kind to me today.

Over a year ago I whined in this blog about how much time was wasted in conferences / presentations / code walkthroughs while trying to change the font size of the text editor in the IDE so that people at the back could see.

And last night, out of the blue (the interwebs are blue, right?), I received an email from Adrian Kuhn in Switzerland saying "Wish granted!"

Download the jar Adrian has posted here and copy it to your Eclipse/FlexBuilder plugins folder and restart your IDE.

Ta-frickin-da!

Now you can quickly increase/decrease the font size of both the editor and the console window without interrupting the flow of a presentation. It's a small thing, for sure, but it's a beautiful small thing.

Apparently this has been tested on Eclipse 3.3+ and Java 1.5+. Works for me!

DryerFox - Moxie Beta 2 Upgrade Completed

This post updates a couple of earlier posts about DryerFox in particular and how to deploy AIR apps with a seamless install from your web page.

Click on the "Install Now" button in the sidebar to get the latest DryerFox executable, or click here for the source.

Updating from AIR Beta 1 to AIR Beta 2

This step was pretty straight forward. The foo-app.xml schema has changed (again!) in FB3B2, so the simplest thing to do (and the sequence recommended in the release notes) was:

1. Create a new AIR project
2. Cut-n-paste the few project descriptors and icon paths from the old project to the new project. The same information exists in both projects, but the location of each XML node has changed.

So far, each public beta of AIR has changed the app.xml schema, so this seems to be an area of churn. Not a biggie though. It took about 3 minutes to do this.

Once DryerFox was compiling in FB3B2, I found that the stage.window property was renamed to stage.nativeWindow, so I have to update the startMove(), minimize(), and close() handlers. That took another 5 minutes, and then DryerFox was up and running again.

Adding UpdateManager

This was quite straightfoward. Kudos to Rich at the EverythingFlex blog for posting this useful class.

1. I copied the com.everythingflex.air.managers.UpdateManager.as class to my project.
2. I created a version.xml that matched the new version in -app.xml
3. Added the following two lines to the onAppInit() method:

import com.everythingflex.air.managers.UpdateManager;
var um:UpdateManager = new UpdateManager("http://www.dryerfox.com/blog/DryerFox/version.xml");

Seamless Installation update (imageurl is gone!)

I followed the instructions in the AIR release notes, and updated my install badge to the latest version bundled in the SDK. This folder can be found at "installRoot/Adobe Flex Builder 3/sdks/3.0.0/samples/badge".
In doing so I found that the new badge.fla no longer attempts to frame a supplied image with the button. I quite liked the embedded, so I just updated my older badge flash project from here, simply replacing older install.as with the newer, more robust version included in FB3B2.

Feel free to steal my backwards-compatible badge.swf if you want something you can just drop in as a replacement. Also note that Adobe now recommends setting Flash 8 as the minimum flash version. Since Flash 9 has well over 90% market penetration, that's a pretty reasonable setting.

SWFObject 2.0

Geoff Stearns and Bobby van der Sluis have been busy improving their individual SWF-hosting efforts into a combined project, just released on Google code. I've updated my "Install Now" button to use the SWFObject 2.0 script, and it seems to be working well. There is a syntax change from the previous use case, but it is still pretty simple to use.

Here's the new syntax:

<script type="text/javascript" src="swfobject.js"/>

<div id="dryerfox_flashcontent">
Whoa. You need to install <a href="http://www.adobe.com/go/flashplayer">Adobe Flash Player</a>.
</div>

<script type="text/javascript">
var flashvars = {
 appname:  "DryerFox",
 appurl:  "DryerFox.air",
 imageurl:  "dryerfox_badge.jpg",
 airversion:  "1.0.M5",
 buttoncolor: "008811",
 messagecolor: "000000"
};
swfobject.embedSWF( "badge.swf", "dryerfox_flashcontent", "217", "180", "8", "expressInstall.swf", flashvars );
</script>

The first two sections are unchanged. Include the swfobject.js script in a <script> tag, and your app's alternate content in a <div> tag. Then use a swfobject.embedSWF() method call to replace the alternate content with your SWF and viola!

DryerFox demoed at Best Buy!

Thanks for reading this far. I just thought I'd send a shout out to the techs at Best Buy (is that still Geek Squad?) for leaving their Vista demo systems wide open. On the weekend I was able to install DryerFox on a sweet HP 19" touchscreen system, and associate DryerFox with the .HTML file extension. Who sets up demo accounts with admin privileges?

Oh well, it was fun to drag the dryer around with my finger.

Wanted: Eclipse IDE widget to quickly change the editor font size

Does anyone know of an existing Eclipse widget / plugin that puts a quick font-size dropdown on the IDE toolbar? If so, please share and the Flex presenter / speaker community will give you a hug.

Can y’all see this in the back?

Changing the font size of the Eclipse text editor is a royal pain. It is a completely undiscoverable feature. It seemed that all the 360 Flex sessions I attended had the same scene:

Presenter: OK, let’s look at some code now. (switches to the IDE, either Flex Builder or full-blown Eclipse)

Guy At The Back Of The Room: Umm. Can you increase the font size so that we can read it back here?

Presenter: Oh, OK, no problem. (fiddles with Eclipse for a few seconds) Umm. Anyone know the secret handshake?

GATBOTR: Preferences —> General —> Appearance —> Color And Fonts —> Text Font —> Change …

Presenter: Whut?

GATBOTR: (louder and more slowly, as if talking to one's great Aunt Ethel) Preferences —> General —> Appearance —> Color And Fonts —> Text Font —> Change …

Presenter: (kinda sorta fiddles some more, and eventually stumbles onto the right path) OK, got it.

GATBOTR: Thanks.

I think the brain is wired to immediately forget such painful experiences. It almost made me long for the intuitiveness of Ctrl-Alt-Delete again. As the conference progressed, some of the presenters got wise early, and had pre-configured their IDE for “presenter mode”, but if they were like me, they still had a hard time finding it buried in the UI. I had to search the Eclipse online help the night before my presentation in order to find the setting.

Turn down the suck

Now, I’m not trying to bash Eclipse here. Really. I like Eclipse. I have all their albums.

I’m just guessing that this UI just sort of grew unwieldy over time, rather than by design. Maybe it is already scheduled to be fixed in the 4.x codebase. But the current experience sucks.

Preferences —> General —> Appearance —> Color And Fonts —> Text Font —> Change …

I'm counting seven clicks (7!!!) until I see a familiar font size selection dialog. There are at least three glaring issues at play:

1. The "Colors and Fonts" category is too long, and by default is clipped to "Colors an". So I can't even just use the tree control to expand and navigate the categories. I have to click each expanded item to see if its full name gives me some clue about what it controls.
   
   
2. Once selected, the "Colors and Fonts" panel displays the list of settings, and the "Text Font" entry is selected (it is highlighted in blue), but there are no obvious controls that suggest "click me to change the font".
   
   
   
3. So now you click the already-selected entry "Text Font" and viola! The "Change" and "Reset" buttons appear like magic.
   
   
4. OK, I know I said 3 issues not 4. I'll concede that this one might just be me. Grouping colors together with fonts doesn't make sense to me. I assume that each language controls its own syntax highlighting, so I just don't expect to be setting colors when I'm setting fonts.

How to help

A savvy Java developer (ie. not me) can probably create a wee widget to sit in the IDE toolbar and add a font size dropdown. No font face changes, no color changes, just make the existing font bigger for the text editor (or better yet, the text editor and any console/output/trace buffer windows).

There now. Assuming this saves 2 minutes of a 60 minute session, the widget you’ve just created has increased the productivity of the presenter by 3%. Not bad! U R AWESOME!!!!

See you at 360|Flex in August

Apparently there is a bit of interest in pointless app development. I'll be presenting DryerFox at the upcoming 360|Flex conference in Seattle.

And while presenting is a nice boost for my ego, what I really hope to accomplish is:

1. Stimulate discussion for the creative use of the WebKit HTML control.


2. Encourage other Flex or Apollo n00bs to give it a try. I wasn't a Flex or Java developer before I started DryerFox, and I had it up and running in a few days. I think that speaks volumes for the short learning curve.


3. Consume some good espresso and good micro-brew (but not at the same time).

I hope to see you there. Drop me a note if you plan on attending.

Technorati Tags: 360|Flex, Apollo, DryerFox, Flex, Browser Hack, WebKit

Inside DryerFox - Part 3: Using WebKit

The DryerFox hack was accomplished by a few basic ActionScript3 stunts.

Get Thee Behind Me, HTML!

When the application starts, it creates an HTML component beneath the image of the drum window, and slightly smaller than the window, so that event when rotated at 45 degrees, no parts of the HTML control "peek out" from behind the graphics.

// Match the size & location of the drum image
html.x = dryerDrumImage.x + 10;
html.y = dryerDrumImage.y - 10;
html.width = dryerDrumImage.width - 20;
html.height = dryerDrumImage.height - 20;

// Now add the html control to the beginning of the display list
application.addChildAt( html, 0 );

Allow mouse events to flow through

Since the dryer frame and the drum window are in front of the HTML control, we need to allow mouse events to flow through to the HTML control. This is done by setting the mouseEnabled and mouseFocusEnabled properties of the mx:Image components to false.

Browser events

Now that the HTML control can respond to mouse and keyboard events, the control can now load web pages and respond to user input. Just to make things fun, I wired up some event handlers to start the drum rotation and sound FX when a page starts loading, plus another handler to stop the drum and sound when the page is fully rendered.

WebKit limitations

The Apollo HTML control is based on the open source WebKit engine. This is the HTML engine used for Apple's Safari browsers, and others too, including the Nokia S60 mobile platform. So yeah, maybe I should have called the app SurfinSafari, but I thought DryerFox was more catchy.

The WebKit control is capable of handling most HTML and JavaScript, but I've found a few things it won't do.

• The mouse cursor doesn't change from an arrow to a hand when you mouse over a hyperlink, nor do the links change color to indicate they can be clicked. Some pages contain JavaScript snippets to perform similar animations (like changing the background color), and those appear to work. Even if the HTML control dispatched some sort of event like ON_LINK_ENTER and ON_LINK_EXIT, then an app could add a bit more affordance that most people expect from a browser.
• There is no control over a right-click menu for the control, again something that most browsers offer.
• Ironically, the WebKit control does not run Flash apps. If a web page attempts to load a .SWF, the page thinks that Flash is not installed. Maybe this is a security sandbox issue, but it doesn't seem to work.
• There are no events raised for page-load timeouts or server-not-found.
  

Maybe these issues will be fixed by the time the Apollo runtime gets out of beta.

Inside DryerFox - Part 2: Web 2.0 is all about transparency

Transparent System Chrome

Yeah, that sounds like something that Scotty might complain about to captain Kirk. "We've run out of transparent system chrome, captain!"

I wanted to make DryerFox run without a normal window frame and live as a dryer/browser mashup floating on the desktop. It just seemed funnier that way.

In Apollo-speak, the outer window that contains the app is called the chrome. The chrome window behaviour is OS dependent, but it usually includes the window title, plus buttons for closing, moving, and minimizing the app.

An Apollo application has a choice of either using the OS chrome (default behaviour), or disabling the system chrome completely. If you disable the system chrome, your app will need to handle window movement, sizing, and closing in some other way.

Thankfully, the Apollo samples include the WeatherStation app as an example of how to do this.

Hidden Gotchas

If you skim the documentation, it seems like all you need to do is tweak the -app.xml file to remove the system chrome, but it is a little more subtle than that.

Here are the steps I used:

1. Create a new Apollo project in the Flex Builder IDE. Let's assume the app is called "NoChrome".
2. Edit the NoChrome-app.xml file generated by the IDE. Change the systemChrome and transparent attributes of the node. should be changed to ="none" transparent="true" ...>.
3. Run the app. Hey! It still has chrome! WTF? (why the frown *cough*)
4. I was stuck at the previous step for about 30 minutes until I read the comments in the -app.xml file and remembered that Mike Chambers had said "now pay attention to this" in one of his ApolloCamp sessions..
5. Change the type of the root application component from to (from which ApolloApplication derives). Then you're good to go.
6. I also duplicated the Application sytle sheet from the WeatherStation app, but I'm not 100% sure if this is required.
   

Application {
/* make app window transparent */
background-color:"";
background-image:"";
padding: 0px;
}

Perhaps later releases of the Flex Builder Apollo extensions will provide an easier way of switching between systemChrome and noChrome modes. For an alpha release, it's still a pretty kick-ass offering.

DryerFox - It's like Firefox, but inside a dryer!

Long-time listener, first-time coder! Here's my first Apollo app ...

I was lucky enough to attend the original ApolloCamp event in March, and I've been spending the last while learning the Flex & Apollo environments.

One of the cooler things about the Apollo framework is the addition of an HTML control based on the WebKit engine. This is the HTML engine used for Apple's Safari browsers, and others too, including the Nokia S60 mobile platform.


Since the Apollo mx:HTML component is rendered as part of the Flash display list, this allows any Flash effects to be applied to an active web page. Blurs, tweens, rotations, it all works.

Presenting ... DryerFox!
I knew I wanted to do something fun with HTML, but the question was: do what? Inspriration hit las Thursday, and I decided to create DryerFox - A rotating browser window wrapped by a dryer image.

You can type any URL into the app, and the page will be loaded and rendered. As the page is loading, the dryer's drum turns, and therefore so does the page. You can also manually rotate the drum using push buttons. The page remains fully interactive, no matter what the rotation. You can read your webmail, surf the net, or whatever. There is even a button to reset the drum rotation back to normal, so that you don't strain your neck.

Installing the demo

1. Install the Apollo runtime framework on your Mac or PC, if you haven't already done so. It is an alpha release, but still pretty solid.
2. Download the DryerFox demo .AIR file. (.AIR is the extension for Apollo apps, but it is just a ZIP file)
   
3. Double-click the downloaded .AIR file, and the Apollo runtime will lead you through the rest of the installation process.

The source for the hack is available here, in case you want to hack it further yourself. You'll need the Flex development environment to do that.

I'll describe the making of DryerFox in a future post, but I wanted to get this out there for feedback.