Monthly Archives: November 2007

The ABC’s of AMF

The AMF file format is a binary file format representing a serialized ActionScript object. This file type is used in many places within the Flash Player and AIR for data storage and data exchange. In Flash Player 9 and AIR, the flash.utils.ByteArray class is the primary way AMF is handled. Let’s look at some examples:

//create some AMF within a ByteArray

import flash.utils.ByteArray;

//create a bytearray
var bytes:ByteArray = new ByteArray();

//write an object into the bytearray
      { myString:”Hello World” , myNumber:21 , myBool:true }

When you write an object into a ByteArray it serializes the object into aa array of bytes using the AMF file format. You can then transfer this file over a network or save it to a file system to be deserialized later. Let’s deserialize AMF:

//create an object and deserialize an object from a bytearray
var myObject:Object = bytes.readObject();

//trace a property
trace( myObject.myString ) // Hello World

In this case the myObject variable looks exactly like the object that was originally put into the ByteArray. Once the AMF data is transformed into a real object again, we can use it in ActionScript identically as before.

In Flash Player AMF is used in SharedObject, RemoteObject, LocalConnection, ByteArray, RTMP (all variants) and all RPC remoting operations. The benefits of AMF are actually really misunderstood, so lets take a quick look:

1. File Size – AMF objects are very small and are compressed using zlib.

2. Fast Serialization/Deserialization – AMF is transformed using native C code in the player so it is blazing fast. The AMF format was designed to serialize and deserialize quickly under low memory and slower CPU conditions. As the AMF data is parsed directly to objects, there is no lag for interpretation or parsing of AMF and creation of objects is done on a single pass.

3. Native Types and Custom classes supported
– You can serialize any object in Flash Player with the only exception being displayObjects. You can also map serialized objects back to custom class instances provided the custom class is in the Flash Player when things are deserialized.

I hear many folks talk about remoting with Flash Player but there is a lower level to remoting in using AMF directly. What is cool here is that you are not limited to traditional RPC using HTTP/HTTPS as Flash Player 9 supports binary sockets in the class and stream loading of AMF using class. Better still, you can use AMF to store data on the server side without the server needing to know anything about the objects themselves. It is an ideal way to exchange data and persist objects to disk or to the network.

I would encourage you to take a deeper look at AMF. There are some low level benefits to using it that are hard to beat. With all distributed computing systems, serialized object formats are essential and AMF is the native format for Flash Player.

There is some big AMF news coming in December….🙂



URL Matters

I view the URL/URI to be one of the most essential but often overlooked aspect of a website. I wanted to look at the good/bad uses of URLs within web pages and web applications. Let’s take a look at a few:

Readable – I really like it when a URL is readable and easy to understand. When I read a URL I want to be able to guess at what the page will contain. .

CNET: Does a great job organizing content into directories.

News/Blogs: These sites have clean URLs with hints about the content
<a href="
<a href="

I would also bet that SEO crawlers leverage keywords within the URL itself. If I were a robot, I would rank the words within the URLs above higher in my search listings than those below.

These URLs leave a bit to be desired.
<a href="

State – I like it when the URL stays in sync with the state of the page/application. I think does a great job of this. The site is an RIA and the URL is in constant sync with the application. It leverages the anchor # symbol yet provides clean URL paths. You can bookmark any part of the site and return to the state of the application/site at any time. Although this looks easy, it is really hard to do well.

Programmatic – I really like it when the developer takes the time to make the URL programatic. It is very subtle but I often return when I can go directly to things via the URL.{FlickrID}{tag}{ ID}


I really dislike query string variables in a URL. In many ways it provides a poor interface to a website and adds a ton of gunk to what could be a clean programmatic URL.

Here are a few URLs that could be improved:



//Grip – I look up stocks all the time. Yahoo and Google make the URL easy to change directly.


I am also a fan of organizing APIs using method+arguments syntax. It makes it easy to see what you are calling as a developer and to allow others to integrate against the API by discovery. Here is an example:

Essentially this would call a method like so: (the 3 is the API version#)
search.resultByKeyword( ‘Flex’ , ‘Adobe’ , ‘AMF’ );

Short – The shorter the URL the better in my book. I am always amazed at how long URLs can get. I view shorter URLs are just plain better. It almost makes sense for every site to have a tinyurl service within them so that each complex URL can be made simple. At Adobe the go URLs have been very popular as they allow a short programmatic URLs to various parts of the site.

Technology Neutral – I prefer when developers hide the technology in use. Long term this provides the ability to switch between technologies on the server-side. The end user doesn’t care what technology you use, so why let anyone know? In this case I think less is more. If the URL is free of technology, I think it elevates the service in my eyes. Hide the technology you use, it will make you look smart and provide you greater range of options long term. Also once you get into search engines, the URLs are there to stay and you will need to support the URLs presented to your servers.

Outside of Apache/mod_rewrite and Tomcat, there are very few options for simplifying the URL’s a server presents. I have standardized on using Apache/mod_rewrite because it works well and is simple to implement. I would encourage you to take a look at mode_rewrite to simplify the URLs within your application. I need to make better use of this on my site and eliminate the php from my URLs site wide.



Want to work with Flex on the Adobe Media Player team?

I rarely post Adobe job descriptions but this is an amazing job for a leading Flex developer. Here is the job posting:

Adobe is seeking a Senior Computer Scientist with strong Flex or Flash application development experience to join the Adobe Media Player team. The position will be responsible for development of the new Adobe Media Player that will feature Flash Video delivered via the new Apollo runtime still under development.

Key Responsibilities include, but are not limited to:

· Code features with great quality, meeting the agreed upon schedule.

· Advise other engineers of Flex/Flash development techniques and issues.

· Work with QE to resolve bugs and issues to meet agreed quality standards

· Write functional specifications.

· Gather and incorporate specification feedback from QE, engineering, marketing, and other departments.

· Develop task lists and schedules based on completed specifications.

· Engage with customers to resolve bugs and issues in pre-release.

· Interact with product management and team leads to refine feature requirements.

· Works closely with teammates to solve problems, transfer knowledge, and develop over all product architecture.

· Committed to the highest levels of quality; demonstrates accuracy and thoroughness.


· Bachelor’s degree in Computer Science or equivalent experience

· Experienced in Flash ActionScript application development

· Experienced in Flex application development

· Typically requires a minimum 5 years of application development experience, with technologies such as Java or Flex

· Experienced in J2EE development or similar technology

· Experience with Object Oriented Design.

· Experience creating Web Service APIs.

· Experience developing automatable test suites as part of development.

· Excellent written and verbal communication skills.

Interested candidates should send their resume to



MAX 2007, Done. MAX 2008, Coming Soon!

I started working on MAX 6 months ago and I have to say it was a blast to contribute to the events in Chicago, Barcelona, and Japan. Overall 2007 marked a great change for MAX as we focused on the community and scaled up the MAX conference in size. Worldwide we reached over 7,000 customers at the 3 events. MAX was great this year because of the community participation and the amazing sessions provided by MAX speakers, for this I need to thank everyone who attended and contributed to MAX. It was a real pleasure to join the MAX team as there are some amazing people who worked really hard to make MAX great. I am looking forward to working on MAX 2008 and I am sure it is going to be a great year.

Over the past month since MAX Chicago we have been compiling a ton of feedback about the events. One of the real problem areas for MAX was the unions in Chicago. There are many complaints about the lack of staff and technical issues and most if not all of these fall into the union management of McCormick place. I wish the situation was different but we couldn’t even plug in a power cord without an electrician and union rep. These issues were non-existant in Barcelona and Tokyo and it was very frustrating to me to see work politics derail well laid plans.

Even with these side efects MAX was still the best event that Adobe/Macromedia has ever had with record attendance and community participation. I am very proud of the results and what we accomplished in a very short time. We have some great changes in store for MAX 2008. I look forward to seeing you in San Francisco and other parts of the globe, Amsterdam or Bangalore sound interesting?

Thanks for your attendance!
Thanks for your participation!
Thanks for all the hard work!
MAX 2007 was a blast!

Time for some much needed diving!


Managing UI Development Expectations with Flex

The default skin in Flex is pretty nice and I have regularly seen this cause problems with consulting projects. The issue is that when you mock up a user interface it looks good by default and the client thinks that development progress is much farther along than it really is. While I was consulting I used a default skin to remove the shine from the Flex UI allowing me to better manage client expectations.

Clients want to see a steady progression of development and if you show them shiny polished ui very early in the development process it can lead to confusion. Clients rarely realize how much work it takes to wire up a UI but they can see visual improvements. My recommendation is to use a plain CSS skin for Flex and dial the chrome down to black and white. It allows you to focus on control layout in prototypes vs having the chrome distract your client.

Here is a simple test. Which UI is more complete?

See my point. To the non-developer manager the first UI looks much better and more complete. The key is to show them the plain one, then later in development work on the custom skin and reveal your development progress later. You will get some strange looks from other developers but your client will have a better set of expectations and the plain skin helps you explain the progress of their application.



Here is a sample project that contains the plain css style. Feel free to use it to manage your clients expectations.