Monthly Archives: December 2003

Central _root & _level0 workaround…

Within Central apps you can’t use _root and _level0 in your code as they refer to different things within the Central Player. Here is a simple workaround that solves many of problems your will encounter working without root.

1. Create a _global object for your apps variables, props, methods, classes:

_global.icon04 = {}

2. Create a property called “root” within the object with a reference to the main timeline:

_global.icon04.root = this

*I am not sure if a common _global is accessible from pods and agents as well. Although these other SWF files can carve out their own root reference for data storage etc.

3. Simply use the icon04.root reference and you will always know where the root of your movie is.

4. If you are comfortable with _parent use it, but be careful as you just might be moving the MovieClip holding your SWF. I think about the execution of my application as if it were loaded via loadMovie to a nested MovieClip.

5. When your app finishes execution, clean up _global:

delete _global.icon04



Central Components via attachMovie

In working with Central Components, I found it very effective to use attachMovie with the components. There are some tricks to making this work effectively.

Central components are RSLs (Runtime Shared Libraries) and observe all the same quirks as with the Flash Player only in this case the components are already on the local machine via the central local file system.

Rule 1:

First you need to present one component on stage to import the Central Component RSL into your application. Once a single component has been presented on stage you can use attachMovie to create any component instance in your application. I add an MIconButton to the left of 0,0 on _level0 of my apps. This keeps it out of view, but imports the RSL for attachMovie use.

It seems that createObject doesn’t exist in the Central Player. I recommend using createObject in all areas other than the Central 1 player as it doesn’t work.

Rule 2:

The names of the component in the RSL are different than the formal Central names. Simply add “Symbol” to the end of the formal name to get the movieClip instance in the RSL. Here are the component names:
































Also here are the properties set by the DesignTime components. Using these properties within attachMovie via the InitObj allows you to properly instantiate the Central components as needed.

Central Component Props

3. There are additional components/symbols/classes within the RSL. Here is a list of the export linkages in the RSL.

Central RSL Linkage Ids

There is some interesting stuff in here! Especially the ActionScript versions of Robert Penner’s Easing Equations and Ric Ewings’s Drawing Methods. Hope they got a credit for the code! Once the RSL is added to your app within Central at runtime, check the Math Object as easing equations are added within.



Central SDK HTML Docs == Amazing!

It is not often that I comment about a help system but the HTML documentation within the Central SDK is simply fantastic!

Kudos to the team on this one as this has dramatically accelerated Central development for us. Working with the Beta PDF Documentation was driving me crazy! The TOC, index, and search make working with Central classes and components easy as they contain clear ActionScript examples.

I was initially frustrated as the Central components feel like you are driving blind being shared libraries. The docs make this problem much smaller as it becomes very clear how to access and control all the Central goodness.

From “View Source” it looks like the HTML Docs were generated using WebWorks Publisher.

What a great resource. I only wish the Flash MX 2004 docs were republished in this format!😉



Central – A Usability Problem

Central has a usability problem in that it forces a new use pattern on the end user that is counter to how desktop applications work on the native operating system.

In writing my first few Central applications, I discovered some usability problems with the Central model and wanted to shared my experience. Central has a usability problem in that the platform forces users into thinking in terms of a single application execution. In several cases, end users could not tell a Central application from a desktop app. The end user would wrongly assume that Central applications used the same paradigm as is standard on Windows and Mac as follows:

1. I select an application to launch.

2. The platform launches an application instance into a separate window.

3. I use the application as needed

4. I close the application when I am done.

Central doesn’t work this way and in several cases confuses the end user to the point of having a bad experience especially in regard to loss of application state.

In Central the primary navigation sits atop every application instance. This would be equivalent of an instance of the OSX Dock or Windows Start menu sitting on top of every running application. This only serves to confuse the end user as if they click on another application, the current application is replaced within the same window. Also management of multiple windows is poor in that if an application does not have an instance running, the top application window gets overwritten. This forces applications to be written in a fundamentally different manner in terms of application state. Developers are forced to write applications that constantly maintain state as at any moment another application can overwrite your application instance.

If the end user were performing a sophisticated task like writing a blog entry or editing a website, their work could be instantly lost due to another applications execution. These errors seemed to be compounded by notifications and pods, as apps are overwritten when action is taken on these items unless an instance of the other application is active. As we see more data interaction within Central, this will most likely compound the problem even further.

This presents developers with a problem as depending on how you maintain state in your application (if at all), this can ruin your end users experience as state is wiped clean during the execution of another app whether intended or unintended.

Say I were to make a Business Card RIA for Central where you can make your own business cards, order them, and physical cards come via mail. In the card design process, my application would save state with every single end user change. As a developer, I should be constantly saving state as should an instant message or a tornado warning appear, my application state is toast. In this regard, it is the app developers responsibility to save the users work, not end users. Currently there is not a way to present a dialog and stall the overwriting of an application instance or force an application into a new window. This will simply limit the range of applications we will see on Central.

If this were the case on OSX or Windows, they would be ineffective as a platform as users would constantly be loosing work. Can you imagine:

I am using Excel working on my annual budget, an instant message appears, I click on it and Excel is replaced with AIM deleting my unsaved work.

Ideally having a Central Menu launch independent application instances would be the best way around the problem. This is especially true if the Central Navigation is removed from every application instance providing less distraction from the end user task at hand. This would allow Central apps to parallel the execution of desktop apps and the end user would not get confused in the process.

Presenting another application paradigm to the end user that is out of sync with the native OS is a mistake in my opinion. Sure Central is different but fighting desktop use patterns will only limit the applications that are built on Central and its success as a platform.



Version Control

We use version control for projects as it allows many developers to work on a single project in parallel without overwriting each others work. It also provides a simple deployment model allowing us to update and publish on demand.

There are many way to version control software and many commercial/non-commercial vendors of version control software. In our consulting practice we use CVS ( Concurrent Versions System ) as it provides high quality, well tested, widely deployed, open source version control system built on open standards. CVS is very inexpensive to implement as most parts are free and the clients are available for all platforms. CVS is a client server system that exchange data over the CVS protocol.

I think about CVS as an online file system. The file system stores data in the file/folder paradigm, yet allows multiple versions to reside within the file/folder hierarchy under a single file. Each version of a file is marked with time submitted, author/submitters, and relevant file data including notes. You can also build collections of files to allow for easy deployment or project grouping. On larger projects version control becomes essential as the potential for loss of work rises exponentially with the number of developers working in parallel.

The first thing you need to use CVS is a client. We use TortoiseCVS as a client on Windows as it integrates into the file system easily. With TortoiseCVS, you simply create a folder, Right-Click > CVS Checkout, Enter URL & path to CVS Server, Press Enter. The client then syncs the current distribution version of the servers file system. (Try testing this out on the many public CVS servers for open source projects or via a free CVS server.) You now have a local copy of everything on the server for local work. You can then edit files and commit your changes back to the server, assuming you have access to commit. Other developers working on the same system can obtain your changes after you commit. This simple shared file system allows many people to work in parallel, yet not overwrite each others work. Ideally CVS gives you a perfect historical record of software development, so long as everyone commits their changes.

Version control is very handy for deployment. We often install a CVS client on deployment and staging servers allowing the team to deploy a version via CVS at any time to any location. The key is that CVS allows us to take a snapshot of the repository and recreate that version at any time. Assuming changes to a site are coming up, we make the changes in CVS, test the updates on a staging server, then deploy a version to production when the time is right. CVS provides us some flexibility in this regard as it works into our development process without to much hassle.

As far as CVS servers, I would highly recommend working online. CVS can be difficult to work with as a server and when the repository gets big, you will need a specialist to work with your files. We chose to work online because it provides a simple offsite backup of all our work and security is as good as you make it (SSH, Encryption, Firewall port blocking per IP). So long as we can access the Internet, we can work effectively. I can easily say that I sleep better at night knowing that our project files are safe in a CVS repository. Should we loose the online version we have 2 nightly mirrored back-ups (via CVS clients), should we loose a client machine, the repository is still available. When we do loose work (local delete, coffee in your keyboard, dog ate my homework), we only loose the uncommitted portion of a project exposed to a single user. Typically this strategy limits loss to less than 1 day of work.

Below are a list of links regarding CVS.

CVS hosting – *****

CVS Dude – Free Hosting with upgrades – ****

Commercial SourceForge

Commercial CVS Support

Ximbot CVS Support – Local hosting Help

Google CVS Links

Articles of Merit

Intro to CVC ( from the MotherShip)

CVS for New Users

CVS Server Versions

Command Line Tutorial

CVS for Web Development – ****

Books of Merit

Pragmatic Version Control – ***** Excellent Read for CVS and Project workflow!

Essential CVS – Oreilly – ***** All the details

Clients of Merit

Tortoise CVS


Mozilla Bonsai Web View/Client



SmartCVS – Code Compare, Diffs Management- Commercial Excellent!!!

Nice CVS Management / Reporting Tools

Concurrent Versions System



Flash MX 2004 > Save And Compact

I loved this feature during my Authorware days, nothing like purging all the extra bits out of your source files.

This is a great feature as over time your FLA can get bloated with changes, etc. Simply hit “Save and Compact” and you can often reduce the size of your FLA by 100% or more on disk.

As we use version control (CVS), it keeps our repository as small as possible. Also when we package up a ZIP file of project work they are much smaller.

Check out “Save and Compact” when you get a chance and kiss those extra bits goodbye!