MAX Unawards: Behind the scenes (part 3)

Posted by Serge Jespers on Sep 7, 2010 in Flash Platform, MAX2010 | 3 comments

In part 1 of this series I talked a little bit about how we recorded the footage for the MAX Unawards application and how After Effects CS5 and Premiere Pro CS5 really helped me save tons of time. Part 2 explained how the personalized video segments were done with the help of cue points. Today I’m going to explain how it was all put together in Flex and why I actually chose Flex for this application.

Why Flex?
Let’s start with that question first. As I already explained I needed/wanted to build this application with a minimum amount of resources and time. I knew that if I went the Flash CS5 route I would have to write all my preloaders, form validators, components, and more and soon realized that that would just take too much time. Sure… a lot of this stuff is available from the community but it is also available out of the box in Flex. I also took lots of time thinking about the file size. Last year’s MAX widget was pretty big (close to 1 MB) and that was one of my major concerns when I picked Flex. There’s no denying that the Flex framework does add some weight to your application but you get a lot in return! I chose to enable the RSL (runtime shared library) feature for this application. It is actually switched on by default if you use the Flex 4 framework.

When you enable the RSL, the Flex framework does not get compiled in to your application. The RSL also gets cached on the user’s machine. A lot of Flex apps already use the RSL feature and therefore a lot of users (especially in our community) won’t need to download the framework because they already have a cached version. That was also the reason why I chose the Flex 4 framework and not the recently updated 4.1 framework. I’m also using two modules that only get loaded when they’re actually needed. I have one module for the actual player and one for creating and recording your own MAX Unaward. By using the RSL feature and the modules I was able to keep the file size for the main application as low as possible. The main application file is now 370 KB, which I think is more than acceptable (especially compared to last year’s widget). If the modules were part of the application they would have added 800KB to the initial load.

So… Why Flex? Well… To save time. I didn’t have to worry about writing preloaders for the modules since that is all built into Flex. I didn’t have to write my own components, validators, server connections, etc… You get the idea.

Putting it all together
When you first load the main application it will check if there is a video ID specified in the embed code. When a video is approved the user gets an email with a direct link to his video. That way he can send his award to his friends or embed it on his blog or social network pages. If no video ID is specified or the video ID is invalid the application will load a random video from the database. On the back end I’m using ColdFusion 9 and a MySQL database. Flex and ColdFusion are a match made in heaven. It is incredibly easy to set up the connection and communication between them and therefore another great timesaver. The entire backend code is just 50 lines of easy to read code. In the Flex frontend it’s just as simple. Once you have set up the RemoteObject it just takes one line of code to invoke a ColdFusion function. The main application is less than 500 lines of code (about 300 for AS3, 100 for transitions and effects and 100 for MXML).

From the amount of code I have for transitions and effects I’m sure you can tell that I heavily used the new states model in Flex 4. Every Flex component has a showEffect and hideEffect property, which I also used a lot in this application. Whenever you set a component’s visible property to true or false the showEffect or hideEffect are triggered. That makes it incredibly easy to make a button fade out or have a panel slide in to frame.

Flex modules make it very easy to load external SWFs. The moduleLoader component also has progress and ready events that tell you exactly how many bytes are loaded from your module and when it’s ready to go. Adding a preloader is as easy as pie thanks to those events. When the user clicks on the “Play” button the application loads the actual player module while showing a nice preloader and the same goes for the record button. In tomorrow’s post I’ll explain how those are put together. In the mean time go and give yourself a MAX Unaward!