The application I have been working on for the last month and a half finally hit the Comcast Interactive Media (CIM) Labs page. You can launch the application from here.This should still be considered alpha since this is one state of the completed application. Once completed, the application will include the Circular view of the fan that is the traditional view of the Fan, with the ability to switch between the views. I thought I would quickly write some notes on the experience of writing the application that will be in front of a LOT of people very soon.
Why Flex ?
We have some of the best Flash developers here at CIM working in a very traditional software development method. All of our code is written in reusable classes with modularity and startup speed as the primary focus. So to use Flex, something new to a lot of the team, instead of Flash was not a decision taken lightly. The biggest objection was always the size of the swf file generated. However, looking at the design we saw that almost every Flex component was used in the final version of the application. Since new components add only a marginal size to the swf once you have accepted the framework, it seemed to be a good case for using Flex. I would also like to dispel a myth at this point: Filesize does not slow down an application as much as network latency does. If your application pings a server multiple times to get startup data, its going to be much slower than one that loads in all the data at once. So we tried to keep startup calls to a minimum. The Fan also serves only the Comcast high speed cable internet subscribers so we were guaranteed the high speed connection. Moreover, its easy to write a component that does most things right but people tend to forget the small nuances. For example, if you write a drop down box, do you check to see that you may be on the edge of the Flash canvas and may need to drop up to render properly? Most people forget the small things that kill the experience.
Flex Skinning:
We had heard a lot of scary stories on how difficult it is to skin Flex. I think the core reasons people dont skin Flex applications is because the default look seems fine when you start the development (maybe adobe did too good a job on the default look 😉 ). I would like to say, skinning Flex isnt that hard, especially using graphic assets from a swf or something. Skinning in code is a lot more involved and needs a deeper knowledge of the framework. We started with simple symbols-in-a-swf method and later moved to code based skinning. I did run into a few issues with some components where designers wanted the tabs to bleed into the browse-area but Flex kept clipping my skin. We’ll revisit that and I’ll update everyone once I have an answer. But besides that skinning flex wasnt that difficult.
CSS and Runtime style changes:
This was another reason Flex won over a simple AS3 implementation. There were designs around differently skinned instanced of the application and even though we did have a home-grown skinning framework, the one that Flex offers was much more mature. I already have a few prototypes for skinned instances and they work pretty well. The only thing we needed to learn was how to switch graphical assets at runtime since thats a little more work but at the end it was easy to implement.
Custom components, renderers and AS3 wrappers:
There are a couple of custom components in this application but without styling, the application is just a custom video-player, a panel containing a list and a canvas with a tilelist and tab-bar. All the list elements have custom renderers that represent the data. There are some interesting features to note here:
1) The numbered playlist renderer has the number value bound to its index in the list using the itemRendererToIndex property
2) The tilelist renderers have a start animation delayed by a multiple of their row index making the startup animation a lot more interesting.
3) The color of the playlist renderer changes based on if the video is playing or not. This is via the dataBinding classes. I actually have a function bound to the setter of the ‘isVideoPlaying’ property. Again, this required some learning on my part.
The video player itself was written in raw AS3 since we will embed videos at other places outside the Flex environment. So we wrote an AS3 wrapper that listens to Flex events and then calls resize, play pause events on the player. The player talks to Flex via the wrapper as well. Buttons/scrubbers , input boxes etc inside the player were custom classes written in AS3 in the spirit of Flex but not within the framework.
Reverse migration to 9,0,16,0:
This was something that came up that had me stumped for a while. The application worked on a bunch of computers and then wouldnt on others. It was only later I realized that I was using events exposed in the 9,0,28,0 release and since I had Flex 2.01, my code complete suggestions would expose those events and I would use them and it would work great. 9,0,28,0 has api extensions to the player not available in 9,0,16,0. I was using the addedToStage event and that was crashing the app on others machines. And since they didnt have the debug versions, I couldnt view the stack traces. Now like any good developer, I have my debug player set to 9,0,16,0. If you are developing a Flex app that doesnt use fullScreen (or even if it does) make sure it is 9,0,16,0 friendly. You can use the flash.system.Capabilities to check the users Flash player version.
So how was the experience?
The new features in AS3 are just amazing to work with and Flex is just the icing on top! The feature I loved most is the new E4X XML parsing. There are elements in the application that do some non trivial XML parsing and it could all be handled so easy using E4X. At one point I wrote a code that ran through XML, created objects and stuffed them in an array to use later (a-la AS2) and then refactored all the code to just store the XML as a variable and run through it as I would an array. AWESOME !
Custom events rock and stack traces are beautiful to see (umm..not really but you know what I mean).
The other cool thing was the decoupling of UI symbols and the ability to instantiate them in code. All assets are referenced through an AssetManager (Singleton) class that holds the references of the images. These can be swapped easily even at runtime.
Custom namespaces gives us an easy way to grant limited access to properties rather than making them public.
Issues?
No onReleaseOutside event. We went around this by listening to release events on the stage. Every DisplayObject has a reference to the stage so that wasnt too crazy, but seems hack-ish.
Flex builder really needs to know the targeted version for the application and surface events only available on that. Would have saved a lot of time on the backward migration to 9,0,16,0
Lack of private constructors kill the Singleton pattern although there are implementations that do the job, but again: hack-ish.
Depth management is tricky since you cannot allocate a number value to the depth. For an AS3 implementation for buttons, I would have loved to have created the icon on depth 500 and do all the sprite swapping under it. Since rollover, rollout sprites arent created until the event, you have to add them to the depth of the icon making it move up.Not too bad but it gets complicated if you are adding/removing children often.
All in all, phase 1 was really fun (and fast). I have 2 tips for anyone looking into Flex for hardcore development.
1) Know the properties and events available. A lot of properties exist in the framework that I had never used before. Case in point: We were HRule objects or some graphical UIComponent to separate a list from the lower content via a blue line. Turns out Lists have the border style where you can create borders around any or all the sides. All we ended up doing is just creating a pixel border at the bottom. Saved us some memory.
2)Understand data binding. While using the [Bindable] meta tag is convenient, it isnt a panacea. It took me a while to figure out how to use the ChangeWatcher and the BindingUtil class to conditionally bind to different objects (since item renderers are reused in the list as you scroll and you may need a very granular level of control). Maybe I can post something on that later unless someone has seen a good resource on that (please leave a link if you have).
Drop me a comment and let me know what you think so far.
As always, we are still looking for talented Flex / Flash developers so drop me a line at arpit_mathur [at] comcast.net if you wanna be part of the team.
update:
Fan 4 on the blogs (not all flattering of course 😉 )
Mike Potter on Riapedia
Ryan Stewart on ZDNet
Ryan Stewart’s blog
Pete Cashmore on Mashable
Riability
Shelly Powers on burningbird
Cable 360 article: ‘ Comcast Expands Web Video In “Convergence Revolution” ‘
The fan is also featured on scalenine.com
Code Zen 