Leopard Attacks

I am one of the many, many Flash developers hit by the now infamous Leopard upload bug. I don’t have a complete solution for anyone but I do have a small amount of advice on how you can get your apps to at least fail gracefully when faced with this game breaking bug.

In AS3 you can use the Capabilities class to detect the operating system your user is running. In Leopards case, the Capabilites.os property will have the exact value “Mac OS 10.5.0”. Once you are aware, you can then do whatever it is that might be appropriate for your app.

Hopefully this bug won’t be around long, but until it is fixed, happy cajoling!

-Casey

!super

I recently spent a good deal of time debugging an issue that one of our Flex apps was having with TileList extensions. Eventually I worked it all the way down to the collectionChangeHandler in TileBase. The handler was setting the horizontal scroll position regardless of whether or not the direction of the TileList made it appropriate. On a side note, I also found out later that this bug is now fixed in FB3 Beta2.

Anyway, my problem with this bug was the available options to fix it. My first and most obvious attempt to resolve it was to override the collectionChangeHandeler in my extensions. Unfortunately this failed due to the fact that the code in TileBase is fairly tightly coupled to the code in ListBase, its parent. This meant that if I wanted to override the function in my TileList extension, I had to rely on the super function in ListBase. But there is the catch! It isn’t the super function, it is the super.super function. And guess what, that isn’t supported in AS3. You cannot skip over the implementation of a function in an inherited class if you want an even earlier one. You can only override the previous instance in the chain. If you can’t get around having to write the override you have to then override all the functionality in all the super functions. Major Bummer.

{Confusion}

I’ve been doing more work in Flex recently and I have become increasingly dissatisfied with some of the features. The technology itself isn’t the problem. It’s the design trap that it creates.

Binding makes it seemingly so easy to feed data into your view that you can get very carried away with it. You can end up with mxml components which declare other components and use so many bindings to set various properties that you create an explosion of binding execution at runtime.

At this point I think class based “code behinds” that use property invalidation are much cleaner. You can ease the performance hit of your app by cutting down on the overhead of binding. You can eliminate all the script you would otherwise put in a script node to make your component more readable. You can also avoid actually writing business logic in your bindings. This leaves a very clean mxml component almost entirely dedicated to layout code. It may not be everything that Adobe envisioned but it’s certainly easier to read, understand, and maintain.

-Casey