Showing posts with label Flex. Show all posts
Showing posts with label Flex. Show all posts

Friday, April 3, 2009

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).

Saturday, March 14, 2009

Feed your inner ninja!

Have you registered yet for the Flex SDK Bug Quash on Saturday March 28th? That's just 2 weeks away.

The Vancouver Flash platform user's group is taking a road trip down to Seattle, so we can pwn in person!

You don't have to show up in person, you can also register online. Regardless, once you register, make sure you download the pre-event kit (link sent once you register) so that you are fully prepared and good-to-go when the event starts.


Looking forward to meeting more geeks and squashing some annoying bugs. Oh, and likely consuming a beverage or two.

More info available at http://www.bugquash.com/

Monday, December 8, 2008

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.

Monday, April 28, 2008

C U @ PV3D Vancouver this weekend!

I'm excited to get some Papervision3D training this weekend from John Grden. We might decide to make him an honourary Canadian and buy him an extra vowel or two for his last name.

Obviously, the appropriate Canadian letter would be a 'U', since we have so many of them lying around these days. "Color?" Never heard of it. "Colour?" Yeah, baby. That's more like it!

Anyway, if you're from out-of-town and want to blend in, the correct pronounciation is "Vang-couver". Yup, us locals add a nearly silent "g" into the city's name.

I hope to see you there.

Thursday, January 31, 2008

Pixton revealed at Vancouver Flex/AIR tour


The fine folks at Business Objects hosted the the recent Vancouver stop of the Flex3/AIR Prerelease Tour. Local Adobe Evangelist Duane Nickull was bravely demoing a 4-hour-old build of Flex Builder, showing off the new features to a crowd of of about 60+ developers / designers. About half were new to the Flash platform (welcome to the party!).

Duane's quote of the night came at the Yaletown Brew Pub afterwards: After telling him that I think that Flex is the crack-cocaine of programming languages, Duane quipped "Adobe considers Flex to be the gateway-drug to AIR". Brilliant.

Star of the evening - Pixton

Local developer Clive Goodinson demoed a new online comic site called Pixton. This super awesome site was created by Clive in just two months, and includes a Flash CS3 front end married to a PHP back end. Pixton is incredibly visually appealing, plus it has very immerisive and intuitive editing capabilities. Drag a character's arm to reposition it, and the joints all move correspondingly, in a very natural manner.

You can also remix the content of other Pixton comics, if the original author permits. Duane has already used Pixton to mock co-worker Ted Patrick. Most excellent.

Sunday, August 19, 2007

Using SWFObject and the AIR install badge for easy deployment

One of the topics I spoke on at 360|Flex was how to add an "Install Now" button to a page, using the AIR install badge from Adobe. This is very easy to do, even though this post is long-ish. Explaining what is happening takes longer than the dozen lines of JavaScript required to get this to work.

I have an example "Install Now" button for DryerFox in the blog sidebar. This button will provide a one-click install experience for your users.

Quick-n-dirty summary for adding an "Install Now" button.

Copy foo.air to your web folder. This is your app's AIR application bundle.

Create a 215 x 100 image of your app, and save it as foo_badge.jpg in your web folder.

Copy swfobject.js to your web folder. Thanks to Geoff Stearns for the fabulous SWFObject.

Copy badge.swf to your web folder.

Add the following HTML snippet to your page:

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

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

<script type="text/javascript">
var so = new SWFObject("badge.swf", "badge", "217", "180", "6.0.65", "#FFFFFF");
so.addVariable( "appname", "Foo" );
so.addVariable( "appurl", "foo.air" );
so.addVariable( "imageurl", "foo_badge.jpg" );
so.addVariable( "airversion", "1.0.M4" );
so.addVariable( "buttoncolor", "008811" );
so.addVariable( "messagecolor", "000000" );
so.write("foo_flashcontent");
</script>

Details - Under the hood

The SWFObject script will replace the <div> section labeled "foo_flashcontent" with the badge SWF, and populate its required Flashvars with your apps resources. Note that it is important to include some sort of fallback text in the <div> in case no Flash player is found.












Flashvar nameDescription
appnameThe name of your app. This name will be displayed by the badge in various messages below the "Install Now" button. Messages like "In order to install FooApp, the AIR runtime will also be installed".
appurlThe URL of your app's AIR bundle. The URL can be relative to the same folder as the page, or can be an absolute URL pointing to some other domain.
imageurlThe URL of the 215 x 100 image (JPG/PNG) to display inside the badge. As with the app URL, this URL can be relative or absolute.
airversionThe version of the AIR runtime required by your app, as specified in Foo-app.xml. For Moxie beta 1, this is "1.0.M4".
buttoncolorThe color of the "Install Now" text in hex RRGGBB format.
messagecolorThe hex RRGGBB color of the message text displayed below the badge.


Clicking the badge will do the following:

Auto-update the Flash player. The user's current Flash player version is examined and the script will update to the latest Flash Player if required. This bootstrap works as far back as Flash player 6.0.65 (released in December 2002), so that gives pretty good coverage. Will a 2002-era computer run a useful AIR app? Hmm. Probably not.

Auto-install the AIR runtime. Verify that the AIR runtime required by your app is installed, and auto-install it when missing. Each AIR app is tied to a specific runtime release, and the install badge knows how to deal with this correctly.

Auto-install your AIR app. This is, of course, what you really wanted to do in the first place.

Security Issues

Just to be clear, all of the above installation operations take place in the context of the active operating system user account. No OS security restrictions are bypassed, so the user will need admin or install privileges to succeed. This is a good thing.

Churn, Churn, Churn

The badge.swf example was added to the Flex SDK as part of the Flex 3 (Moxie) public prerelease, but that version of badge.swf was rather buggy. Adobe quickly released a patch and you will need to use the patch and avoid the one included in the SDK. I'm sure this will be fixed in the next public code drop. For now, avoid the code in INSTALLROOT/sdks/moxie/samples/badge.

Update:
Also make sure your web server is configured to know the mime-type of .air files. (*.air=application/vnd.adobe.apollo-application-installer-package+zip) More detail on the mime type is found in Mike Chamber's post here.

Resources:

Tom Cornilliac's excellent post on the AIR install badge. (It is just missing the SWFObject example)