Monthly Archives: January 2008

Flowcharting Flex style at

The team over at is doing some amazing work with Flex. Watching the video below left me speachless as the application is far easier to use than MS Visio. I really like the workflow for creating diagrams and links between elements. Yet another great Flex application!

var so = new SWFObject( ‘’, ‘csSWF’, ‘350’, ‘280’, ‘9’, ‘#1a1a1a’);so.addParam( ‘quality’, ‘best’ );so.addParam( ‘allowFullScreen’, ‘true’ );so.addParam( ‘scale’, ‘showall’ );so.addParam( ‘allowScriptAccess’, ‘always’ );so.addVariable( ‘autostart’, ‘false’ );so.write(‘media’);


Application Output:

Looks like Adobe Flex is close to being the foundation to a suite of applications!



Adobe Flex, Super Bowl XLII, and

It seems that is hosting an Adobe Flex application that will showcase a majority of the upcoming Super Bowl XLII advertisements using Flash Player and HD Video. The site allows you to watch all the videos end to end by brand using a great UI. The application is a great RIA and makes it easy to re-watch any of the commercials that you might miss during Super Bowl.

Looks like a great use of Adobe Flex!

Go Adobe Flex!
Go Adobe Flash Player!



Generic Components and Services

I moved this weekend and as I was boxing up all my stuff, I thought about generic components and services. Tape, cardboard, moving wrap, and a rental truck are all simple things but when you put them together they become something far more valuable. It seems simple to combine tape and cardboard, but when combined, they make another powerful component (box) and make a larger service possible (moving). During this strange line of thinking, I tried to find the characteristics that made the most sense when creating generic components and services, here are a few that came to mind:

Can I use this component over and over?

Can I use the same box N times? (box has some wear and tear but can be used N times)
Can I use a piece of tape N times? (tape is more single use, it gets unsticky)

How easily can this component be combined with itself or another component?

Tape + Tape + Cardboard = Box
Ink + Quill = Pen
((Box + stuff) * 35) + Truck + 9 hours = Move across town

Are there side effects when I combine components? The fewer side effect, the easier things can be combined.

Example: Does the steering wheel (component) affect the gas peddle (component)? Say I turn right, does the car speed up? Say I turn left does the car slow down? Not good.

Can I make a component do something it wasn’t intended to do. Can I stretch it, bend it to make what I need?
Example: Splice two boxes to hold something unique in size/shape

How many different ways can I use a generic components or service?
Example: Tape and cardboard are used for many different things.

Runtime Assembly
Can you assemble new components at runtime? Can you combine components and make new components here and now without a recompile?

Example: HTML has a beautiful set of generic components that can be reassembled into billions of different configurations. Instead of sending down components, you send the recipe assuming all the generic elements are present.

During the move I found the most useful generic component to be moving wrap. This stuff is magic as it adds a little layer of plastic around things and sticks to itself. In packing up the kitchen I wrapped everything breakable in this stuff to protect it and bundle things together. It allowed me to take a stack of glasses and make them virtually unbreakable and one solid element. During the move not a single item broke or scratched and it was largely do to this wrap. It was a simple generic component that really improved my move.

I am looking to build IFBIN 2.0 atop generic components and services that can be reused in other applications. In designing out the component/services it is useful to explore how other applications might use these. As you think about building components and services for use within the applications you build, take a look at what can be made generic and reusable.

I am glad I am all moved!


Flex 3 Framework Caching

One of the new features in Flex 3 and Flash Player (MovieStar) is support for framework caching. Framework caching provides 2 things:

1. Separate the Flex framework from application code via Runtime Shared Libraries (RSL).
2. Installing a secure (signed) Flex framework RSL into Flash Player 9 release 3 (MovieStar)

When you separate the Flex framework into an RSL your application then depends on that RSL and it must be loaded when your app starts up. The RSL contains a specific version of the Flex Framework depending on Flex SDK you use. All sub-versions of Flash Player 9 support RSL but in last release (release 3) Adobe added support for caching a signed (.SWZ) version of the Flex framework. The caching logic installs the signed RSL into the player so that it can be used by Flex app on any domain. This basically allows the RSL to extend the Flash Player so that the Flex Framework version is never downloaded again. The first time a Flex application is used, the caching will occur, the N+1 time the user on any domain will only download the application logic.

Here are two example projects:

Framework cache disabled (default)
Properties/Flex Build Path/Library Path/Framework Linkage/ Merged into code

AC_OETags.js – ( JS Player detection )
playerProductInstall.swf ( Player upgrade SWF )
SampleProject.html ( Base HTML )
SampleProject.swf ( Application SWF file )

Framework cache enabled
Properties/Flex Build Path/Library Path/Framework Linkage/Runtime Shared Library (RSL)

AC_OETags.js – ( JS Player detection )
playerProductInstall.swf ( Player upgrade SWF )
SampleProject.html ( Base HTML )
SampleProject.swf ( Application SWF file )
framework_3.0.189825.swf ( Flex Framework RSL – Loaded for FP9r1 & FP9r2 players )
framework_3.0.189825.swz ( Signed Flex Framework RSL – Loaded for FP9r3+ )

Q: How will this work when a new SDK is released?

The key is that your app is dependent on a specific version of the Flex framework and the caching mechanism supports this. If you run into 2 apps built with different version of the Flex framework, say release and hotfix 1, both frameworks will get cached. This avoids the DLL hell issue typically in deploying windows applications. As the runtime manages caching and supports multiple version of the framework, it just works.

Q: How much smaller?

The signed Flex framework RSL (.SWZ) is 535KB and includes all base components and libraries in Flex. Even if your app uses just a button, the same SDK will get cached. A simple hello world application is 50KB vs the typical 350Kb. Size of your base application will vary depending on the components used as all skinning, style, assets, and custom code will be compiled into this base SWF file.

Q: Does this work with all Flash Players?

YES! Applications where framework caching are turned on will work in all release versions of Flash Player independent of the caching feature. Caching will occur automatically if Flash Player 9 release 3 or higher is installed.

Q: Can I cache custom code in the framework cache?

NO. Only signed Adobe components can be added into the Flex caching feature at this time due to data security. As the cached code is cross-domain enabled, anything in the RSL is added into the security domain of the running application.

Take a deeper look at Flex framework caching it is a great new feature in Flex 3. It will make your applications smaller and they will instantiate faster.



Minimalist Approach to Flash/Flex/AIR Development

When I create software that runs on Flash Player I take a minimalist approach during development. Flash Player has a limited amount of code execution capacity, rendering capacity, and memory storage capacity at any moment in time. Ideally your application never pushes the player to its limits at any single moment in time and thus will run as fast as possible. Should you hit these limits, the player will simply slow down until all the work you are asking it to do is complete. Over time these facts have forced me to think in terms of programming in a minimalist fashion.

The Flash Player uses a logical unit of work called a frame which consists of 2 phases which occur one after another in a loop:

1. Process ActionScript
2. Render Graphics
3. GOTO 1

After each of these phases is a buffer to handle delays ( say you render to much or loop over a ton of data ). When both of these phases have completed we call that a frame. Each SWF file you create has a framerate (frames/second) which represents the fastest rate that the Flash Player will loop over these phases. When Flash Player encounters delays in processing either phase it will elongate the time to process the frame and thus your framerate will slow but will never exceed the framerate set in the SWF file.

Ideally your application never renders or executes too much at a single moment in time. There are several ways to handle this:

1. Minimalism – Never attempt to do too much at one time.
2. Process data across frames ( callLater() ).
3. Time Animation – Use time to animate/render ( flash.utils.getTimer() ).
4. Frameworks optimized for Flash Player (Flex).

Flex was built to handle application behavior in a minimalist fashion if used properly. I continue to see developers execute to much ActionScript on a single event and not think in terms of processing data across frames. Using events properly is a great place to start. Make sure you know how long and how often methods are being called from events. I had a case recently where a developer was using the flash.utils.Timer class and firing tick events every millisecond. Even with the simplest of methods subscribed to this event, it would bring Flash Player to its knees. To help visualize how your application works take a look at the memory and performance profiling in Flex Builder 3 Professional. This toolset was built to let you see what your application is doing at runtime and easily locate performance areas within your application. Better still the profiler allows you to locate performance issues late so you can avoid early optimization and save a ton of development time. I prefer to take a more balanced approach and architect things taking advantage of processing over time and using events carefully. Another big issue is the use of bindings as these generate events when data changes. As they are so easy to create, you can force the player to be processing nearly non-stop with the smallest of data changes. They are very powerful but it is easy to abuse.

To more fully understand this approach I would encourage you to explore and experiment with Flash Player and the Flex 3 Profiler. Once you understand how the player internals work and can see the effect of the code you write, you will understand the benefits of being being a minimalist. Just remember, I am not asking you to give up your worldly possessions but rather think in terms of doing the least to achieve your goals with Flash Player or AIR.



Command Proxy – IFBIN 1.0 used it with Python

Mike Chambers posted on using Command Proxy with AIR for .NET integration but having actually deployed a rich client solution cross-platform with IFBIN using this same pattern, I thought I would chime in. First off it works and by works I mean that I successfully built and deployed IFBIN 1.0 on MAC and PC using Flash Player, Flex 1.5, and Python. Here is the architecture atop Mike’s diagram.

The reason I chose Python is that it ran cross-platform so porting between operating systems was not as hard ( can’t say trivial but 90% of the code worked ) and leveraging Flash Player allowed for a rich UI. When IFBIN 1.0 shipped in 2005, we had no AIR runtime and using Central 1.5 was problematic given the lack of a really solid FileIO feature set. The IFBIN architecture ran a local http/socket server and launched a browser when started. The browser then loaded a SWF file created with Flex 1.5 and opened an XMLSocket connection to the locally running Python server. The Python server in this case handled all DRM, FileIO, Downloading, and Licensing of the files on a per installed basis and the local server had a simple API for executing any feature that Flash Player did not support.

In regards to security, the architecture in IFBIN 1.0 limited client/API access via a secure token and only clients with that token could connect to the locally running service and call the API itself. It also helped because the local connection from ClientUI to local server was a persistant TCP/IP Socket so once authenticated all commands over the socket were denoted as secure. I also made some security enhancements to limit the FileIO to a single directory and thus writing and deleting files was limited to the service and managed.

I personally would avoid building an local .NET dependency into your application as this just limits compatibility. When we write software we want to reach the largest market possible without having to do unique things on a per platform basis. With IFBIN 2.0 (yes it is in development) I am using AIR 1.0 with no external dependencies. This choice makes development cross-platform ideal as I get 3 platforms for free without any additional work.

My take is that the key value of AIR is writing software for 3 platforms (MAC/WIN/LIN) with a single codebase. Anything that forces me to do something unique per platform and fork the codebase is a really bad thing.

To Mike’s defense the Command Proxy architecture works well but I would personally never do it again with IFBIN. AIR 1.0 handles all the requirements to deliver IFBIN without a local server/service running.

My 2 cents,