Quietly Scheming

Since I posted the Flex DisplayShelf component, I’ve had a number of people ask me how I got the 3D tilting effect in the decidedly-non-3D Flash player. So today I posted an interactive sample that shows how the tilting effect is achieved. Check it out here:

Updated DisplayShelf page with interactive walkthrough

Since I posted the DisplayShelf component, I’ve had a number of people ask me how I got the 3D tilting effect in the decidedly-non-3D Flash player. So today I posted an interactive sample that shows how the tilting effect is achieved. Check it out here:

Updated DisplayShelf page with interactive walkthrough

I know there’s a bunch of people who read this blog looking for flex components and sample code, and tend to ignore the longer more considered monlogues I post (I’m not bitter). So in case you’re one of those people, you might have missed the new component I posted last Friday called SuperImage. Read this post to find out more, see the samples, and download the source.

I still can’t get over how cool this is. Eylon Stroh, a member of the extended Flex dev team, has build a napkin theme for flex apps. There’s numerous anecdotes floating around about the benfits of making your wireframe prototypes really feel like wireframe prototypes. And besides, it’s just frickin’ cool.

Eylon’s Napkin Theme Tutorial

In the past week or two I’ve been noticing an uptick in the number of posts on the benefits of Flex vs. HTML threading their way through the blogosphere. Now I don’t really want to get involved too deeply in this discussion — HTML/AJAX and Flex have different design centers, and as a good developer you should be deciding what’s the best technology suited for the task at hand (or, why not use both?). Lots of factors should be affecting your decision — productivity, usability, content type, size of the production team, type and lifetime of the content — and for any given project, those factors might push you in different directions (i.e., some projects types will be more usable implemented in Flex, and some will be more usable implemented in HTML).

But there’ve been a couple of comments I’ve seen that have led me to make this statement: I think it’s a mistake to evaluate Flex purely on the basis of the pros and cons of individual features of the framework. Why? Because unlike HTML, you are not limited to what you can do with the functionality we provide out of the box. Flex was written from day one to be an open, extensible framework…anything we can do in our components you can do too (and we even give you the source code to prove it). Don’t like the way Image behaves? Write your own Image tag! Get enough people doing that, and there’ll soon be a wealth of new and improved frameworks and components out there for everyone to choose from.

Now you can argue that this is possible in HTML as well…witness the multitude of AJAX widgets and frameworks sprouting up all over the web world like weeds in the yard. That’s true, and there really is some quality AJAX content available for developers to take advantage of. But I’ll point out three important things that differentiate Flex’s approach from these AJAX libraries when it comes to customization:

• Integration. Flex was built for extension, while AJAX frameworks are a second class citizen in the HTML world. This is not a fault of the AJAX library developers, but a limitation of the HTML/Javascript world. There’s nothing quite as satisfying as writing a new Whirlygig Flex component and using it in MXML with a simple <my:Whirlygig /> tag.

• Power. Most of the components, tags, and APIs you use in flex are written in actionscript on top of a much lower level API provided by the player. That means that in addition to building up on Flex, you can build down as well — as I said, if you don’t like the Image component, go under the covers and build a better one.

• Coherence. Because we exposed the underlying infrastructure from day one, there’s one accepted component framework in Flex that everyone is using/extending. That means lots of components available, lots of help and knowledge transfer available, and a large market for any useful extensions you write. The Ajax framework landscape is craggy and fragmented. That will likely change over time, but it’s not going to be an easy road to get there. (How about all those other component frameworks Macromedia came out with, you ask? Touche, I would respond (if I knew how to type an accent egue in HTML) Touche. Let’s just say we’re learning our lesson the hard way).

Putting my Money Where my Mouth Is

Rather than blathering on, I’m going to go ahead and kick off some improvements myself. Since before Flex 1.0 shipped, there’s been three things that bug the hell out of me about our Image component: In rough order from most to least annoying:

• Funky aspect ratio behavior. The Image component will guarantee it renders images at the correct aspect ratio, but how that relates to the amount of space it actually takes up on screen at anything other than its natural size is bizarre, to put it midly.

• reload behavior in a list. A number of people have blogged about this annoying behavior recently, and they’re generally right. Because of some of the details of the Flash Player’s networking layer, there is always a delay of at least a frame between when you request an image url, and when it is actually loaded. That causes ugly flickering in a list (although I will say that if you gave me a list with 10,000 items in it, I’ll take Flex’s flickering-but-fast-virtual-list over HTML’s giant slow loading page, or next 10 items - next 10 items - next 10 items - hell any day of the week).

• no border. It drives me crazy that it’s hard to put a border on an image. You can wrap a container around it, but that’s a bit of a sledgehammer, don’t you think?

I’m tired of working around these issues, so I’m going to do something about it. So last night I went ahead and wrote myself a SuperImage component, which solves all three problems in a nice tidy package. It caches loaded images to avoid flicker, correctly sizes itself to use up screen space efficiently, and can support all the border options the Flex containers support.

While I was at it, I threw in a couple of other enhancements as well:

• source can be a full URLRequest, to allow for more complex HTTP requests (POST, extra headers, etc).

• source can be almost anything that can yield an image…url string, URLRequests, a DisplayObject class, a DisplayObject instance, BitmapData, a Bitmap, or any old DisplayObject,

That’s just a start. I’ll probably add to it over time, building up my arsenal of useful features that I’ve always wanted in an Image but previously have been too afraid to ask (ask Flex that is). Sho has already requested a loading animation, and an event to differentiate the first time an image is loaded from the subsequent reloads it goes through in a list.

Here’s two sample apps I’ve been using to test out the functionality.

A SuperImage no-flicker-flickr test.

An Image-SuperImage aspectRatio comparison

The code could use some cleanup, some comments, and a lot more functionality ;) But if you want to get your hands on it before all that happens, here it is:

Download the source

Now I’ve said my piece (peace?), but just to reiterate what I wrote above: Sometimes Flex is the right choice, and sometimes it’s not. Flex and Flash are fantastic technologies, in my opinion, but they are not a panacea. Sometime the RIA model isn’t the right choice. Sometime details of the Flash Player make it the wrong technology. But sometimes you’ll find problems specific to the framework, and for those I say: let us know…write a blog…lament and complain, so we can continue to improve on them with every release. But while you’re waiting for the next release, why not try your hand at improving the framework yourself?