James Ward already had a little writeup about Mint.com using Flex for some of their spending habit charting stuff, but what’s even cooler to me is that they’re using a few FlexLib components on the site. I got an email from Jason Putorti, a Flex dev with Mint, letting me know that he’s using the DraggableSlider component, and I took a look and also saw that they’re using the ScrollableArrowMenu. Here’s a screenshot of both the components in use:

The menu showing the list of cities there is the ScrollableArrowMenu and above that there’s the DraggableSlider that lets you select the date range you’re using for the chart. Sweet!

Yesterday I made some updates to FlexLib, mostly to sort out some bugs, a few of which I inadvertently created with the previous release. Here’s the list of issues addressed:

• Issue 71: Drop-down tab-list fails to activate when using states with constant names
• Issue 72: SuperTabNavigator -Close Tab-
• Issue 76: Make TabReorderEvent Cancelable/Hookable in SuperTabNavigator
• Issue 77: Tabbar title change does not resize Tabbar
• Issue 78: getChildren in ButtonScrollingCanvas

The first four issues are fixes for SuperTabNavigator issues. #71 and #72 were new bugs I introduced with the .2.2 release without realizing it. My bad. This is what happens when the FlexLib QA team consists of me after about 5 beers. #76 is an added feature for the SuperTabNavigator. #77 is a bug fix for a SuperTabBar bug, and #78 is a fix for ButtonScrollingCanvas for what I guess has been a bug since that component was added.

I also managed to put a up a version .2.3 briefly that had an even better bug with ButtonScrollingCanvas that rendered that component and the SuperTabNavigator inoperable. Woopsies again. I updated the release and the current version (.2.3.1) should have things all sorted out. There were around 250 downloads of the .2.2 release (jesus you people move fast), so if you downloaded that one, make sure to get the latest and update, that .2.3 release is whack.

There’s also a new component dropped into FlexLib, but I’ll blog about that one tomorrow since I haven’t done the writeups for the component description on the wiki pages yet. But it’s in there.

w00t. Keep reporting bugs.

Today I was looking over the details of the eBay Flash/Flex widget contest and thought maybe I’d whip something together and enter. I figured I could probably throw together some eye-candy nonsense using PaperVision, Box2D, fire effects, etc etc and make something that looked impressive. Might be worth a shot at a cool $10k. Then I read the details a little closer and found this clause:

• Widget may not incorporate any open source code except for Adobe Flex under the MPL license;

Fuck that. I use open-source projects in nearly everything I do. Literally everything. This becomes an issue when dealing with consulting work for clients, and I bring this question up right away and ask what kind of restrictions the client wants to place on the use of open source code. On one hand, the client usually wants 100% of the code to belong to them, they want the IP, and using any open-source code in the project is frowned upon. On the other hand I explain the cost of having to build from scratch all the stuff that I can get for free from these open-source projects, and when it starts being thought of in dollars then we usually arrive at an agreement to allow open-source code. Note that this only applies to MIT and other completely open licenses, if it’s not MIT I usually won’t touch it with a ten foot pole.

So eBay wants to run a contest where you can’t use open source code. That means no 3D engines, no physics engines, no custom component libraries. If you wanted 3D you’d have to build your own custom 3D engine. Umm, no thanks. It’s funny because they make the explicit exception for the Flex framework, since if they didn’t do that you wouldn’t be able to make any Flex app at all.

Hell, if you take that clause strictly, you probably can’t even use eBay’s own Flex Toolkit, which is licensed under the Common Development and Distribution License, which is an “open source license based on the Mozilla Public License.” I hope every entry in the contest gets disqualified Come on guys, the Flex SDK is about to be open source, your developer toolkit is open source, and yet you want to say we can’t use open source code?

I want to start off with a quick recap of the current status of the bug I wrote about a few days ago. The Flex 3 Panel bug that resulted in the content of a Panel overlapping the title bar of the Panel has been fixed. The fix will be in the final Flex 3 release. The bug report that shows this status is here: Issue 11279, which is now marked as a resolved bug. I want to point out that I was told (with proof) that Adobe recently started re-investigating this bug on their own about a week before I posted my rant (although that was never exlained in the bug database).

I also want to take a second to address what was seen as me being an asshole with what Matt Chotin called my “strongly worded criticism.” I also received another email from a Flex team member with a similar sentiment letting me know that I may have been a bit harsh and that I need to remember that the engineers working on the framework are good guys trying to do the best job they can for us (the customers). I’ve met Matt personally a few times, and I deeply respect him and all the Adobe engineers working on Flex. I didn’t mean my little rant to come off as a personal attack on anyone, although I realize that since I was targeting a very specific bug that that means it falls under the responsibility of a few individuals. My harshness was a result of frustration and a misunderstanding of Adobe’s perspective, there was never meant to be any direct blame placed on individual engineers. And so with that, here’s my olive branch:

Dear Flex team, I love you all. Your work is greatly appreciated. You make it possible for me and many other people to do work that we love. You’ve delivered a fantastic product and the overall intelligence of the team shows through in the great code base of the Flex SDK. Keep doing your jobs. Even though I may criticize, I mean it with love and respect.

OK, everyone feeling all warm and fuzzy inside? Cool, let’s all get back to work.

Matt Chotin addresses what to do if you run into similar issues like this Panel bug, where you don’t feel the Flex team addressed the issue adequately. He mentions that you will be able to vote on closed bugs in the future, so once that is in place you can still vote on a bug even if it has been marked as NAB, and the Flex team will be able to see which ones have the most community involvement. Until then your options seem to be leaving comments on the closed bug (which in this case meant 4 or 5 independent bug reports of the same issue) and emailing the Flex team, which I think means email Matt, since I can imagine that they don’t want all the engineers dealing with trivial requests from the community all day long.

That said, I’m not sure if I had dealt with the bug differently (ie simply posted a comment and emailed Matt) that it would have gotten fixed so immediately. While I understand that internally Adobe was re-investigating this bug, my hunch is that without the public bitching there would not have been a fix committed for the final Flex 3 release (feel free to correct me if I’m wrong). A single comment on a bug report and an email to Matt likely would have gotten it on the radar (although it already was), but I’m guessing we wouldn’t have seen such immediate action. So perhaps I should have phrased my previous post in a better way, and simply called attention to the bug to try to get others to comment on it so they would reopen. But I think there is certainly a place for publicly posting issues like this, since it’s an effective way to rally the troops and clearly articulate the issue (what was I going to do, write a 2,000 word comment in the bug database?). So in the future I’ll try to be a tiny bit more diplomatic with how I write posts like that.

So thank you Adobe for the quick action in response to this issue.

When Flex 3 was first released in beta you may have noticed a bug having to do with the Panel component when you set borderStyle to anything other than “default” (which funny enough, isn’t even a code-hinted option in Flex Builder). The issue was that the Flex 3 SDK laid out the Panel contents on top of the title bar, so the content ended up overlaid on the title and it would generally look like total crap. Basically if you had a Flex application that used the solid (or inset or outset) borderStyle on Panel to style your application, suddenly when you upgraded to Flex 3 your app looked really bad. Since Alert and TitleWindow extend Panel this affects those components too. You may have seen things in your app that looked like this:

Yeah, that sucks.

So I figured this was one of those bugs that would get reported quickly (it did) and fixed quickly (it did not and will not). There are 4 duplicate reports of this issue in Adobe’s bug tracking system, the first one was reported June 13, 2007. Here are the 4 issue reports:

• Issue 11279
• Issue 12215
• Issue 12872
• Issue 13012

They’re all the same thing, and they each have example screenshots or SWF files that show how bad the resulting bug looks.

The bugs have all been marked as Not a Bug. And this is the explanation for this resolution:

After some back and forth discussion, Glenn and I have decided that Panel will no longer support any borderStyle besides “default”. The reason is that in order to support the other borderStyles, we would have to put in the hacks that were in Panel back in. This would make it more difficult to skin Panel using graphical skins.

Panel will support other borderStyles when using the backwards compatibility flag. In addition, it will be possible to use a combination of explicit heights/widths and absolute positioning to replicate most of the old behavior for alternate borderStyles.

PanelSkin’s implementation of alternate borderStyles will be mostly working, but won’t layout the header and control bar in the correct locations, nor will it size the Panel to be large enough. We need to document these issues.

In the release notes there will be a line that reads:

Release Note: Panel only officially supports the “default” borderStyle. If you use an unsupported borderStyle, use padding values or absolute positioning to place your content in the correct place.

I call bullshit. This is not an acceptable resolution.

Why bullshit? Let me count the ways.

1. You should never be able to make a Panel that has the content overlaid on top of the title bar. That is fundamentally against the definition of what a Panel is. A Panel has a title bar ABOVE the content area. ALWAYS. If the content area overlaps on top of the title bar then something is wrong. If the answer is that Panel will not layout the contents correctly unless the borderStyle is default, then you should not be able to set it to anything other than default (which is not a good resolution either, but at least it wouldn’t produce such crappy looking Panels).
2. This worked very well before, was there ever a single person who complained that the Panel didn’t lay out its contents correctly? It did exactly what it was supposed to do, which is to lay out the content below the title bar.
3. The default Panel skin gets old quickly, and we want to change up the look of the Panel. Used to be that you could just set borderStyle to solid and make some nice looking Panels that didn’t have that same opaque content area with semi-transparent border look. Now those decent looking Panels you styled in your old app are harder to make.
4. I don’t buy the argument that “The reason is that in order to support the other borderStyles, we would have to put in the hacks that were in Panel back in. This would make it more difficult to skin Panel using graphical skins.” I guess the issue is with graphical skins as opposed to programmatic skins. PanelSkin returns border metrics that are used to layout the Panel’s contents (ie place them below the title bar by checking the headerHeight of the Panel). That code seems kinda hacky to me already, it means that the layout of the children in Panel is determined by a programmatic skin. But if PanelSkin is returning the border metrics used in Panel to layout the children then it could easily do so for the other border styles too. This would at least solve the problem when using the default PanelSkin (which must be the bulk of what people do). Maybe I don’t understand the issue with graphical skins, but let’s say you’re using some graphical skin to skin Panel, when would you ever want your Panel to have the content area overlap the title bar? Never. I just don’t get it.
5. The “solution” for people that want to use the “unsupported” border styles is to set the paddingTop style to be the same or greater than your headerHeight, which will force the content to be placed below the header. But wtf kind of solution is that? We have headerHeight for a reason, and that reason is so the content gets placed below headerHeight pixels from the top. This just sounds like an answer of “well, you can hack your way around it, so that’s good enough.”

So basically I’m just bitching, because this bug will likely just stay “resolved” and be released in Flex 3 when it ships with a little release note to warn people to not do what they will invariably try to do. I don’t know if there is a formal thing I should do to try to get someone at Adobe to reconsider, the bug was filed 4 times and all are marked resolved. I assume if I submit a new one it will be marked as a duplicate and resolved. Sigh.

Oh, and Flex for Dummies will have a sentence similar to this:

WARNING: If you set a Panel’s borderStyle style to anything other than default then you must also set the paddingTop style to at least be as many pixels high as your title bar. The default implementation of Panel with borderStyle set to anything other than default sucks.

As I’m doing some writing for the Flex for Dummies book I was digging into the source code for Panel and the other containers. I was writing about how Panel allows you to set the layout property to either absolute, vertical, or horizontal, just like LayoutContainer (or Application, which extends LayoutContainer). My initial thought was that Panel probably just extends LayoutContainer and that’s where we get the layout property from. But then digging in I saw that both LayoutContainer and Panel independently implement the layout property (in basically a cut and paste exact same way). Unless I’m missing something there’s no reason why Panel shouldn’t just extend LayoutContainer. (BTW, for a recent writeup of the LayoutContainer class see Ben Clinkinbeard’s post here).

If you look at the setter for the layout property it’s almost identical in both Panel and LayoutContainer. And take a look in measure() and updateDisplayList() and you’ll see the same calls to layoutObject.measure() and layoutObject.updateDisplayList().

So I dunno, just thought it was interesting. Really I’m just procrastinating while I’m supposed to be writing. OK, back to work…

Ely Greenfield presented some cool ideas about the future of the Flex framework during his presentation at MAX in Chicago last year. The core idea is that they’re considering drastic changes to really apply an MVC approach to the full component set, which would mean the core components themselves would be viewless controls, allowing you to easily apply custom skins and have complete control over the look of each component. I wrote up more about Ely’s session here. The future of these changes is still unknown, I think we’re all hoping that stuff becomes the Flex 4 framework whenever that gets released.

But the Flex community isn’t waiting. There are a number of people working on similar concepts outside of Adobe. A recent post by P.J. Onori triggered this blog post. I’ve noticed a few others working on very similar ideas, so I just wanted to point this out, and make a note that it’s worth keeping tabs on these guys/projects because there’s going to be some seriously cool shit that’s going to be possible.

• P.J. Onori released a set of layout managers. These layout managers are very lightweight, are not tied the Flex framework, and in fact aren’t really even tied to the display of the components. They handle different algorithms for laying out objects, ie in a grid, in a circle, etc etc.
• Stephen Downs (aka Tink) is working on some layout algorithms for use within a ViewStack. The basic idea is very similar, create a set of layout algorithms that determine how the children get placed, but make those algorithms independent of the actual visual component. Tink’s stuff hasn’t been released just yet, but keep an eye out for it soon.
• Ben Stucki is working on an ambitious project he’s calling OpenFlux to create a complete framework for containers, layout algorithms, and component creation techniques. At a minimal level this will allow you to do similar stuff like P.J. Onori’s layout algorithms. But then Ben is going to be combining his stuff with 3D and we’re going to have flexible 3D containers with complex custom layouts (ie you could build CoverFlow using these base classes in a matter of minutes). Ben is calling the OpenFlux + 3D stuff PlexiGlass. In case you saw the session list for 360 Flex in Atlanta and wondered what the hell Ben’s topic meant His session is definitely going to be one to watch at the conference.
• Degrafa has just been released, which allows you to write complex graphics tags using MXML. A core piece of Ely’s presentation relied on the new mx:Graphics tags that are going to be in Flex 4. The Degrafa team has basically done the same thing, but you can use it now instead of waiting for the next Flex release. What this means is that if you have a set of core components without specific visual designs, you can easily create skins using Degrafa in MXML. This idea of MXML skinning and skin-less base components is crucial to what Thermo is going to allow you to do.

So we’re not quite there yet, but we’re getting close. What I’m seeing is that gradually we’re moving toward a highly-customizable, display-agnostic full component set for Flex, coupled with some advanced display options (using both 2D via Degrafa and 3D via PlexiGlass). What would that let you do? You could define a base data-driven list. Then you could choose to render that list as custom 2D graphics using Degrafa, or you could choose to render it as 3D components using PlexiGlass. The underlying component is the same base list component that has a list of data, selectedIndex, etc. But you could swap the rendering at runtime, letting you toggle between 2D and 3D views, or fluidly switch between different 3D layout algorithms, etc.

Some of the stuff I mentioned is released now, some is coming in the next few months. But keep an eye on these projects, they signal a shift in the Flex framework. I suspect that shift will officially come from within Adobe eventually with a future release of the Flex SDK, but it will come from within the community sooner. It’s gonna be fun

As part of my non-existent New Year’s resolutions, I’ve gone through and made a series of bugfixes to FlexLib and released an updated version .2.2. You can download the distribution zip file here or checkout the project from SVN.

What was fixed
Here are the list of issues that I fixed. If you find out that something I think I fixed is still broken then let me know.

How you can help

1. There are still open issues that have not been fixed. If you take a look at the list and know how to fix something listed there, submit a patch by emailing it to the FlexLib discussion group and we’ll add it in.
2. Report more bugs using the issue tracking system. It’s MUCH easier to keep track of bugs people have found if they log them in the issue tracking system. I tried to go back over emails to the flexlib discussion group where people reported bugs, and I got some of them, but I likely missed some there. If you previously emailed the list (or me directly) with bug reports but did not log it in the issue tracking system then it might have gotten lost. If it’s logged in the system then even if it takes me a while to get to it, at least I have all the issues in one nice list to review. I also fixed a few small bugs that were emailed to the list without filing them as issues, and now I forget what they were, so if you sent me an email with a bug you might want to check the latest release to make sure it’s still an issue (and then file a report).
3. There are two issues I can’t reproduce or need more clarification on. Check out these two reports and see if you can reproduce either one. If so, write up a more detailed description of the problem and maybe I can figure it out.

Thank you
Thanks to everyone who has reported bugs, keep it up. Special thanks go to Hob Spillane, Kevin Fauth and Andrew Westberg, who all submitted patches to fix a few of these issues (if I forgot anyone who submitted accepted patches I apologize, you can send me an email to bitch at me if you want).

What’s Next for FlexLib
So near the end of last year FlexLib was fairly stagnant, there were no updates since September sometime. We’re all super busy, and I simply didn’t have the time to devote to bugfixes, etc. I’m hoping to stay on top of my shit a bit more this year (which I estimate will last for a solid few weeks). We’ve got to figure out the best way to allow new contributions without compromising the quality of the components. I’m aware that there have been submissions that have taken a long time to get in, or are still sitting in moderation limbo. I don’t have a good answer as to the best way to open up a bit more while keeping quality high enough, if anyone who is wiser than I am has suggestions on ways to run open source projects like this then feel free to contact me with your advice.

I also know that the Scheduling Framework in FlexLib is a big area of concern for a lot of people. There are 7 bug reports in the issue tracking system related to the Scheduling Framework. Unfortunately I’ve never used the Scheduling Framework and so have a) no insight into the code and b) no motivation for fixing code I’ve never used. The original creators of the Scheduling Framework are busy as hell like all of us. I think some ideal scenario is that some badass coder comes along who has extensive experience with the Scheduling Framework and wants to be the champion and take care of the code. If that’s you, then shoot me an email and let me know.

FlexLib and Flex 3
One of the bug reports had to do with Flex 3 compatibility. The latest release will compile with the Flex 3 SDK. I have tested many of the components and for the most part things seem to work fine (I had to make a few minor tweaks here and there). That said, some of the FlexLib components have some copy/pasted code from the Flex 2 SDK, and I have not upgraded these to the Flex 3 versions (they still work, but do not benefit from potential bugfixes in the Flex 3 SDK). For the most part I think you can use FlexLib in Flex 3 projects without any problems. But I don’t want to require the Flex 3 SDK just yet, especially since Flex 3 is still in beta. Sometime after the official release of Flex 3 we’ll figure out the best way to move forward. New components that require Flex 3 will likely be created. At some point we may have to freeze the Flex 2 version and continue moving forward and require Flex 3. But for now you can use the current version with Flex 2 or 3.

I’ve made some much needed performance improvements to the Flex CoverFlow component I released a few days ago. I’ve also taken the concept of 3D Flex containers a little further and added a 3D Carousel container and a vertical version of CoverFlow. Source code here.

Check out the performance now and stop whining (oh, and notice that this blog post has 3 of these embedded 3D components):

Performance improvements
When I first released the component I took the shotgun approach to rendering, which meant I rendered the entire scene every frame and all the materials were animated. This is the lazy approach that ensures that the 3D scene always looks right, but it also kills performance. So you poor people out there with computers from the 1980s complained that the component made your browser shoot up to 110% cpu and all that. Instead of telling you to get faster computers I decided to make a few small modifications to speed things up.

First, instead of rendering every frame we’re now rendering only while the animation is happening. This is a sweet improvement that Brock Brinkerhoff suggested in an email he sent me (thanks Brock!). Basically in our enter frame handler we check if Tweener is currently tweening the selected child. If so, we make PaperVision 3D render the scene. If not we just ignore and don’t waste CPU power. This means that once the movement has stopped (ie the selected child comes to rest in the center), the component no longer uses much CPU at all.

The second improvement was to not use animated materials. I added a new material that I called FlexMaterial (and the associated reflected version, ReflectionFlexMaterial). This material is non animated, but listens for FlexEvent.UPDATE_COMPLETE events fired from the child (and all of the child’s children if it has any). Whenever an updateComplete event fires the material re-renders. This ensures that our material is always up-to-date. One note about this: if you have animations in your child components that do not dispatch updateComplete events you’ll have to manually dispatch updateComplete over and over. This is pretty easy, basically what I did for a child that I wanted animated was add the following code in MXML:
enterFrame="event.currentTarget.dispatchEvent(new FlexEvent(FlexEvent.UPDATE_COMPLETE))"
and that ensures that the child will always be updated.

Oh, and while I was at it I made a modification to get around the z-ordering issue. This was a problem when you selected one of the planes that was not directly next to the selected one. When the selected plane moved back into place it would move through the other planes on its way. Now we push the selected plane straight back at a faster rate than it moves sideways, seems to have pretty much fixed the issue (at least good enough for my eyes).

Vertical CoverFlow
I refactored the code a little bit to allow me to easily change the 3D layout. This let me crank out a vertical version of the CoverFlow component in no time, shown here on the right. This is almost all the same code, just tweaked to lay things out vertically instead of horizontally. I figure this can be used for a sidebar widget. I had to remove the sweet web 2.0 reflections cause I didn’t know where they would go. The cool part about the refactored code is that the base component handles all the core stuff (like creating the 3d scene and planes, etc) and then each extension can simply modify the layout method. Sweet.


Carousel Flex Component
And while I was playing I couldn’t help taking some of Lee Brimelow’s code and making a 3D carousel Flex component. Thanks to Lee for doing the math for me. So here’s a Flex container to do that 3D carousel thingy. One sweet thing is that I took the same approach to preserve full interactivity of the child components. When the selected child is rotated to completely face the user the real child is swapped with the 3D plane and you can fully interact with it just like in a normal Flex app.

Take it further
So if you take a look at the source code you’ll see that I’ve created a BasePV3DContainer, which extends ViewStack and creates 3D planes for each child in the container. The idea here is that you can create an extension of this class and implement the layoutChildren() method and make up your own 3D container component. I wouldn’t say the base class I’ve provided is perfect, there’s certainly some code that should get moved around or done differently, but you can figure it out (hell, it’s only 300 some lines of code with comments). If you make any other 3D container Flex components then either post a comment here or drop me an email: doug.

Get the source
(Note that this source package include the CoverFlow, Vertical CoverFlow, and Carousel components, as well as an example showing using the CoverFlow component with Flex controls. This does not include the iTunes examples in this post. I’m too lazy to clean that code up well enough to give out.)

Here’s a Flex component (with source) that does that sweet looking CoverFlow thing (you know, the iTunes/iPhone thing to show cover art). It’s a Flex component, so you can drop it into any Flex app. Just like Lee Brimelow opened the floodgates for a barrage of 3D carousel effects, I hope to see the CoverFlow effect used everywhere. Especially in places where it makes no sense to have this effect whatsoever. Go forth and overuse it and abuse it.

Example
I’ll go ahead and drop an example right away so you don’t have to read the rest of this to get the idea:

• My iTunes
  So Apple provides RSS feeds of your iTunes purchases if you want. So I dropped my iTunes RSS feed in and this is what I got:
  
  This movie requires Flash Player 9.
  
  I’m thinking maybe I’ll put together a widget that you could customize and load in your own RSS feed and maybe change the colors and stuff, then let people embed this on their blogs. I dunno, I’m also kind of over CoverFlow now, so maybe not…

So what is this component?
It’s CoverFlow, duh. It’s a way of viewing stuff and scrolling through a list horizontally. It’s similar to Ely Greenfield’s DisplayShelf component (except this one does it the right way ), and it’s just like what the guys at Blitz did too (in fact, quite similar since they’re using PV3D and Tweener too). Basically you have a bunch of things (ie cover art images) and you want to show them in this eye-candy extreme way.

How it was done
So this is a Flex component, and it extends ViewStack. There’s an obvious question as to why I made it dependent on the Flex framework and not just straight in AS3 without Flex dependencies. The answer is that it saved me time (and by that I mean I wouldn’t have done it otherwise). By using the ViewStack component as my base I don’t have to deal with all the child management crap. I get all the addChild, removeChild, the use of selectedIndex and selectedChild, and the use of the component in MXML right out of the gate. I’m lazy, so extending ViewStack was the obvious choice.

The component uses two open source libraries: PaperVision 3D and Tweener. Basically when a child is added to the ViewStack the component create a 3D Plane that represents that child. If the reflection is turned on then it creates two 3D Planes for each child, and the reflection Plane is flipped and placed below the first Plane. Yes, this means that showing the reflection doubles the number of polygons PaperVision is rendering. There are other approaches for doing reflection, but this one was easiest for me. Then we use Tweener to lay out the children and tada, we got a nice looking CoverFlow component.

The only sneaky thing that’s done is that we take advantage of the ViewStack control to keep interactivity on the Planes. We do this without using any of the interactive material stuff in PaperVision. Why? Because that stuff makes your app slow as balls. And besides, in this case, the user is only going to interact with a Plane when it is facing directly straight towards the screen. So all we do is wait until the plane is directly facing the user, then we swap in the real child of the ViewStack in its place. This way we get full interactivity, it’s invisible to the user, and we don’t have to slow our app down by using the PV3D interactivity stuff.

Some Other Examples

• Flex Controls
  This example shows using the component with a variety of standard Flex controls. Since this is an extension of ViewStrack you can use the control just like a ViewStack and have children defined in MXML. To keep this blog post from completely destroying your CPU I’ve chosen to only include the iTunes example in the page. This one and the next one you’ve got to click to go see. This app has “view source” enabled, so if you right click on the app you can get he full source code for the CoverFlow component.
  
  View the Example | View the Source
• Amazon Browser
  And here’s what you get if you drop in the Amazon API to do searches:
  
  View the Example

Source Code and Some Notes
The source code for the flex controls example in the list above is available here. That gives you the source code for the CoverFlow component. In that source code package I’ve included the PaperVision SWC and the Tweener SWC. I included those to make sure that people could download the code and test it out, but I encourage you to go get the source code of both of those libraries and compile them yourself. It’s good to know how to do that and that way you know you have the latest versions. A note about PaperVision: I used the Phunky branch of the project, but I don’t think I’m using anything that wouldn’t compile against the 1.5 release, but just in case, that’s the deal.

Sweet, I better see this effect all over the place. im in ur coverz, doin’ ur flow.