I was playing around with Flash Builder 4 & Flex 4 after the public beta was announced, and decided to whip up a quick, very simple AIR client for Basecamp.  It's pretty straight forward and there's not much code, but if you're having trouble getting started with AIR, Flex 4, or Gumbo, perhaps it will help.  

Basecamp provides a very simple REST-based API, which is documented at http://developer.37signals.com/basecamp/. I just used URLLoader and URLRequest to pull the data, with authentication turned on. When authentication is turned on, your OS will handle username and password requests.

I ended up using anchor-based layouts because I couldn't figure out, with the spark components, how to center my screens.  Maybe this is the way you're supposed to do it...I'm not sure.  If anyone has any input as to best practices for the new layout mechanisms in Flex 4, I'd love to hear about them.

Beyond that, there's not much to the application...just a sample.  Maybe I'll flush this thing out as I continue to play with Flash Builder 4.  All in all, in regards to my feelings about Flash Builder 4 and Flex 4, I am going to reserver judgement until I have a larger data set to work with.  Building this sample was very easy, but I don't think I accessed enough of the new features to cast judgement yet.

Download source as a Flash Builder 4 Project Here!

A project we're working on requires third parties to be able to load SWFs of their own design into an overall "shell" that we're building. So far, so good - particularly with the new unloadAndStop method that's part of Flash Player 10. That means I can fully unload the SWFs no matter where they managed to sink their teeth/event listeners.

Then I started to think about a weird edge case... what if the creators of these SWFs accidentally does something spectacularly bad like get stuck in an infinite loop? I had a few ideas for a solution, and so I decided to spike them and see if any of them worked (The link explains what spiking is - but in a nutshell it's a quick-and-dirty end-to-end solution that tests out an idea).

To test my solutions I made two SWFs - one with a simple spinning animation (spinner.swf) and another that, with the push of a button, would lock up for 5 seconds (greedy.swf). My first idea was to put the SWFs on the same HTML page and have them talk via LocalConnection. The spinner would monitor the greedy SWF (when ever the greedy one started, it would tell the spinner) and if the greedy SWF went on too long the spinner would talk back out to Javascript and tell it to replace the Flash Player instance.

That didn't work in the slightest.

As soon as the greedy SWF started getting greedy, the spinner would lock up too. I even tried putting the SWFs in separate HTML files and loading in one via an iframe - same result.

The next solution was to have Javascript do the monitoring. So now the greedy SWF would call out to Javascript before it started getting greedy and the Javascript would then start a timer. If that timer wasn't reset by the greedy SWF finishing it would unload the Flash Player running the greedy SWF. Pretty decent idea, yeah? Nope.

It seems like (at least in the browsers I tested, Safari and Firefox), when Flash is locked up the rest of the browser, including JS is locked up too. The timer would only first AFTER the greedy SWF stopped on it's own accord.

So where does that bring us? Well, these solutions or something like that may work in IE, particularly since it's running on a whole different plugin architecture. It may also work in Chrome since it's whole architecture is based on isolating processes. That being said, a real cross-browser solution remains elusive. I guess I'll just have to hope the 3rd party SWFs don't suck and maybe do a bit of testing on them before I roll them out to the public.