Here is a screenshot from Google Analytics showing the main line chart of visitors:

When you rollover one of the points, you get a popup telling you the exact number of visitors on that date. This simple rollover, while cool, is not particularly useful to me. If I wanted to know exact numbers, I’d look at an Excel printout. Thankfully, we can use Axiis to provide something much better.

Column Stack Chart

I’ll use Axiis to show two different visualization options for the same data. I made some artificial visitor data per day. Here it is as a vanilla line chart I grabbed from Excel:

Not very exciting, but the classic weekend lulls make our dataset a little hard to follow. In XML, it looks like this:

<visitors>
    <week label="A">
        <day label="Sun" val="0.2" />
        <day label="Mon" val="1.6" />
        <day label="Tue" val="2.0" />
        <day label="Wed" val="2.4" />
        <day label="Thu" val="1.8" />
        <day label="Fri" val="1.6" />
        <day label="Sat" val="0.4" />
    </week>
    <week label="B">
        <day label="Sun" val="0.3" />
        <day label="Mon" val="1.2" />
        <day label="Tue" val="1.8" />
        ...
    </week>
    ...
</visitors>

Since the data per day is a little annoying, let’s try to smooth it out by collecting up the day data into weeks. This is easy to do in Axiis by using the ColumnStack layout. Recall that Layouts in Axiis specify how incoming data will be rendered to the display. Here’s an abbreviated snippet of code showing the relevant parts:

<axiis:DataCanvas id="dc" ...>
    <axiis:layouts>
        <axiis:HBoxLayout id="myLayout" ...>
 
            <axiis:layouts>
                <axiis:ColumnStack id="myStack" ...
                    dataProvider="{myLayout.currentDatum.day}"
                    dataField="val" />
            </axiis:layouts>
 
            <axiis:drawingGeometries ... />
        </axiis:HBoxLayout>
    </axiis:layouts>
</axiis:DataCanvas>

First, we use an HBoxLayout layout to render our weeks into columns (the dataProvider is the visitors.week array), and inside that we use a ColumnStack layout to render our days stacked one on top of another (the dataProvider is the current week’s day array).

Here is the result (view source enabled):

The column stack chart is nice because it enables us to distinguish the macro trend over the weeks, traffic is obviously dying off from week A to week H. But it does a poor job illuminating intra-week data. For example, it’s hard to tell how Monday of week A compares to Monday of week B.

Interactive Column-in-Column Chart

Another option to visualize our simulated visitor data is empower the user. Start with a super simple column chart of the aggregated week data, and allow the user to drill down into the day data via some interaction. The implementation I’ve chosen below uses an inset column chart to show the day data when the user mouses over a week column.

In order to display week data, we first need to pre-process our day data to aggregate it into weeks. Axiis makes this trivial with DataSet:

var ds:DataSet = new DataSet();
ds.processXmlString(myXML.toXMLString());
ds.aggregateData(ds.data.object.visitors, "week.day", ["val"]);

The aggregateDate() method walks our XML hierarchy and rolls up aggregates of day.val at every level. When processing is complete, visitors has a new aggregates object that contains day_val_sum (and min, max, and average) for all the days in the entire data set. And one level down, week also has a new aggregates object that contains day_val_sum for just the days in that week.

Next, we construct our visualization using a pair of DataCanvas objects and a pair of BaseLayout layouts, one for the main column chart showing aggregated week data, and the other for an inset column chart showing just the current week’s day data. Here I’m using the same column-chart-the-long-way code as I used last post.

<axiis:DataCanvas id="dc" ...>
    <axiis:layouts>
        <axiis:BaseLayout id="myLayout" ...
            itemMouseOver="mouseOverHandler(event)">
 
            <axiis:drawingGeometries>
                <degrafa:RegularRectangle id="myBar" ... />
                <degrafa:RasterText id="myBarLabel"... />
            </axiis:drawingGeometries>
 
            <axiis:referenceRepeater ... />
 
            <axiis:states>
                <axiis:State
                    enterStateEvent="mouseOver"
                    exitStateEvent="mouseOut" ... />
            </axiis:states>
        </axiis:BaseLayout>
    </axiis:layouts>
</axiis:DataCanvas>
 
<axiis:DataCanvas id="dc2" ...>
    <axiis:layouts>
        <axiis:BaseLayout id="myLayout2" ...>
 
            <axiis:drawingGeometries>
                <degrafa:RegularRectangle ... />
                <degrafa:RasterText ... />
            </axiis:drawingGeometries>
 
            <axiis:referenceRepeater ... />
        </axiis:BaseLayout>
    </axiis:layouts>
</axiis:DataCanvas>

The interaction is achieved by the itemMouseOver event on the main column chart’s layout. Note that we are not listening for events on the columns themselves, rather we listen on the parent BaseLayout. The layout is responsible for attaching individual listeners to all of its children as they are rendered to the display. Layouts have events for all possible mouse interactions, including click, double-click, mouse over, mouse out, etc. This is one of the nicest features of Axiis. Since user interaction is managed by the layout and not by the rendered geometry, I change whatever I want about the geometry or how it is rendered and user interactions are preserved. The code is also pleasantly clean.

What’s more, the main column chart uses an Axiis State to create a visual rollover effect on the columns. The State is used to trigger some visual changes (column stroke weight is increased and label font is bolded) on mouseOver and then reverts the changes on mouseOut.

Here is the event handler attached to the itemMouseOver event on the layout:

private function mouseOverHandler(e:LayoutItemEvent):void {
    //change dataset to current mouseOver'd column
    myLayout2.dataProvider = e.item.data.day;
 
    //set color
    var color:uint = myPalette.colors[e.item.index];
    myPalette2.colorFrom = color;
    myPalette2.colorTo = PaletteUtils.darker(PaletteUtils.darker(color));
 
    //hide text
    insetText.visible = false;
}

The LayoutItemEvent event contains all kinds of useful information when it arrives at our handler. First, we set the dataProvider of our inset chart using the day data from the highlighted week column. Next, we use some Degrafa color magic to set the colors of the inset’s columns from the color of the highlighted week column. And finally, we hide the reminder text.

Here is the result (view source enabled):

The end result is a fairly cool visualization that does a good job initially hiding unnecessary information, but later reveals it upon user interaction. For example, toggle back and forth between week B and week C. You can easily see a shift in traffic to the first half of week C compared to week B.

Postscript

I recently discovered another amazing data visualization framework. Protovis is an awesome Javascript library created by some hella smart dudes at Stanford. If I ever needed to do any visualizations on the web, and was banned from using Flex, I’d definitely use Protovis.

Files

• AxiisColumnStack (download)
• AxiisColumnInColumn (download)

Lately, I’ve been working on a project at work that places a real premium on cool. This post has nothing to do with that project, of course. It’s all about the quest for cool and my personal journey with Axiis.

Simple Ass Column Chart

In the beginning, I had a simple data set and just wanted create a basic column chart. I tried to follow the Intro and Tutorial, but I must admit I got a little lost the first time through. Hopefully, this will be an even easier introduction to the Axiis framework.

Here is our data in MXML:

<mx:XML id="myXML">
    <columns>
        <col label="A" val="10" />
        <col label="B" val="9" />
        <col label="C" val="7" />
        <col label="D" val="5.5" />
        <col label="E" val="6" />
        <col label="F" val="3" />
        <col label="G" val="4" />
        <col label="H" val="2.5" />
    </columns>
</mx:XML>

We want to render this data to the screen as a bunch of columns (aka RegularRectangles). So, the next thing that we need to do is process our data and feed it into an Axiis Layout. A Layout is the main element in any Axiis chart; it takes incoming data and renders it to the display.

Here we process our data and set our Layout‘s dataProvider:

private function complete():void {
    var ds:DataSet = new DataSet();
    ds.processXmlString(myXML.toXMLString());
    myLayout.dataProvider = ds.data.object.columns.col;
    dc.invalidateDisplayList();
}

And here is the basic shell of our entire application:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application ...>
    ...
 
    <axiis:LinearScale id="vScale" />
 
    <axiis:DataCanvas id="dc">
        <axiis:layouts>
            <axiis:BaseLayout id="myLayout">
                <axiis:drawingGeometries>
                    <degrafa:RegularRectangle id="myBar"... />
                    <degrafa:RasterText id="myBarLabel" ... />
                </axiis:drawingGeometries>
 
                <axiis:referenceRepeater>
                    <axiis:GeometryRepeater>
                        <axiis:geometry>
                            <degrafa:RegularRectangle ... />
                        </axiis:geometry>
                        <axiis:modifiers>
                            <axiis:PropertyModifier ... />
                        </axiis:modifiers>
                    </axiis:GeometryRepeater>
                </axiis:referenceRepeater>
            </axiis:BaseLayout>
        </axiis:layouts>
 
        <axiis:backgroundGeometries>
            <axiis:VAxis ... />
        </axiis:backgroundGeometries>
    </axiis:DataCanvas>
</mx:Application>

Stepping through the code element by element, we see:

1. LinearScale – We use a LinearScale to convert from data values to screen values (aka pixels). So a data value of 5.5 might translate into 11 pixels, 42 pixels, or 55 pixels depending on the scale.
2. DataCanvas – The DataCanvas contains all Axiis graph elements. This is analogous to Flex 4′s Graphic container for FXG elements, and Degrafa’s Surface container for drawing elements.
3. Layout – BaseLayout is the parent of all layouts and the most flexible.
4. drawingGeometries – We draw each column as a RegularRectangle and each label as a RasterText. Positioning and sizing is guided by the reference geometry created by the referenceRepeater. Column height is computed using the current value of the data from the Layout converted to screen coordinates by the LinearScale.
5. referenceRepeater – The reference geometry and repeated property combine to create a visualization for the data. So, repeating rectangles horizontally gives a column chart, repeating rectangles vertically gives a bar chart, repeating line segments horizontally given a line chart, etc.
6. VAxis – Draw a vertical axis underneath our graph layer by using the backgroundGeometries layer of the DataCanvas. I like to use a negative x value to shift the axis left to get it out from underneath the chart (and compensate by shifting the entire DataCanvas right with a positive x value).

That’s it for the high-level stuff, the dirty little details are in the code. A little trial-and-error went a long way to teach me what the hell each of the various parameters actually did. The Intro and Tutorial article does a good job covering some of the details and tricks like the vertical flip trick, and I also recommend Tom’s session from AdobeMAX.

User Interaction Coolness

Last, we’ll add a little dash of coolness to our application with a simple rollover effect on our columns. Using an Axiis State, we modify a few properties of our drawingGeometries on the mouseOver event to create a rollover effect.

The State code:

<axiis:BaseLayout id="myLayout" ...>
    ...
    <axiis:states>
        <axiis:State enterStateEvent="mouseOver"
                exitStateEvent="mouseOut"
                targets="{[barFill,barStroke,myBarLabel]}"
                properties="{['alpha','weight','fontWeight']}"
                values="{[1,2,'bold']}"/>
    </axiis:states>
</axiis:BaseLayout>

Cool Colors

Using Degrafa geometry to build our chart gives us total control of the shape and design, but if we really want something cool, we need to use color. For our column chart, we’ll use an Axiis LayoutAutoPalette element to create a smooth color gradient for each bar.

Here is the code:

<axiis:LayoutAutoPalette id="myPalette" layout="{myLayout}"
        colorFrom="0xFF99FF"
        colorTo="0x6699FF"/>
 
<degrafa:SolidFill id="barFill" color="{myPalette.currentColor}" />

The LayoutAutoPalette interpolates from a starting color to an ending color for each data value in the Layout. We then feed the palette’s current color into a standard Degrafa SolidFill. Lastly, the fill is applied to the RegularRectangle in the drawingGeometries section of our Layout to create a pretty gradient of bars from left to right. Note that color is not proportional to the data value, but Axiis certainly provides the functionality to make a column chart with bars colored by height.

The Result

Here it is, rollover effect and all (view source enabled):

Files

• AxiisSimpleColumn (download)

Nowadays, I’m finally seeing some SVG in use. It works natively in all the real browsers (obviously not IE, which requires a plugin), and even on some mobile devices. But most importantly to me, I see it in my day-to-day work in Degrafa, and with the beta release of Flex 4, in Catalyst and FXG.

The vast majority of my experience in SVG is with paths (SVG Spec, § 8) and to a lesser extent Transforms (§ 7) and Filters (§ 15). Thankfully, these are some of the most useful and important pieces of SVG, and they all have nice one-to-one mappings to components in Degrafa and FXG.

SVG Path Primer

In SVG, a path is the outline of some object. It is described as a series of segments, where each segment can be different, either a line, curve, or arc. Path data is most often given in shorthand syntax as a series of commands followed by coordinates (we’ll ignore the long form for now). Let’s illuminate the discussion with some examples.

SVG:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
    "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg xmlns="http://www.w3.org/2000/svg" version="1.1"
    width="200" height="200">
  <path d="M 0,0 L 100,0 L 100,100 L 0,100 z"
      fill="#EECCEE"
      stroke="#FF00FF"
      stroke-width="3" />
</svg>

Degrafa in Flex 3:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application
        xmlns:mx="http://www.adobe.com/2006/mxml"
        xmlns:Degrafa="http://www.degrafa.com/2007"
        layout="absolute">
 
    <Degrafa:GeometryComposition graphicsTarget="{[cnv]}">
        <Degrafa:Path data="M 0,0 L 100,0 L 100,100 L 0,100 z">
	        <Degrafa:fill>
	            <Degrafa:SolidFill color="#EECCEE" />
	        </Degrafa:fill>
	        <Degrafa:stroke>
	            <Degrafa:SolidStroke color="#FF00FF" weight="3" />
	        </Degrafa:stroke>
        </Degrafa:Path>
    </Degrafa:GeometryComposition>
 
    <mx:Canvas id="cnv" />
</mx:Application>

MXML Graphics (aka FXG) in Flex 4:

<?xml version="1.0" encoding="utf-8"?>
<s:Application
        xmlns:fx="http://ns.adobe.com/mxml/2009"
        xmlns:s="library://ns.adobe.com/flex/spark"
        xmlns:mx="library://ns.adobe.com/flex/halo">
 
    <s:Graphic>
        <s:Path data="M 0,0 L 100,0 L 100,100 L 0,100 z">
            <s:fill>
                <mx:SolidColor color="#EECCEE" />
            </s:fill>
            <s:stroke>
                <mx:SolidColorStroke color="#FF00FF" weight="3" />
            </s:stroke>
        </s:Path>
    </s:Graphic>
</s:Application>

The examples above use the shorthand path syntax to draw a 100px square that starts at the coordinate origin (0,0), which is the upper left corner in SVG and Flex. Beware the coordinate origin when translating Inkscape SVG to Flex. The other interesting thing to note is the amazing similarity between Degrafa and FXG. Who knew all my time learning Degrafa will instantly translate to Flex 4 and FXG? Awesome!

SVG Path Shorthand

Here’s a quick overview of shorthand syntax for SVG path data:

Alas, the beta version of FXG does not support the Arc segment type, which I suspect is due to lack of support for arbitrary arcs in the underlying Flash Player rendering engine but I don’t know for sure. Thankfully, Degrafa offers full arc support (thanks Greg!). If you really need to draw arcs in FXG, for stuff like pie wedges, and are unafraid of getting into a cage match with your trigonometry textbook, you can do a good job approximating arcs with cubic Bezier curves. Alternately, you can just use Degrafa once it gets ported to Flex 4. Lastly, using uppercase for the segment type specifies absolute coordinates. This is the format commonly used by Illustrator and Inkscape when exporting drawings to SVG. One can easily switch to relative coordinates by just switching the commands to lowercase, but I would try to avoid it if at all possible as it tends to make one’s head hurt.

The Many Shapes of a Square

All of the squares above, use this shorthand data:

M 0,0 L 100,0 L 100,100 L 0,100 z

First, a Move to set the pen at the origin. Then, a Line right to (100,0), followed by a Line down to (100,100), followed by a Line left to (0,100). Then, a close (z) to return to the origin.

I can drop the commas if I want:

M 0 0 L 100 0 L 100 100 L 0 100 z

Or drop all but the first Line to make a polyline:

M 0,0 L 100,0 100,100 0,100 z

Or use Horizontal Line and Vertical Line:

M 0,0 H 100 V 100 H 0 z

Or even use relative coordinate (which makes my head hurt a little):

m 0,0 l 100,0 l 0,100 l -100,0 z

Curves

Straight lines are cool, but the real fun in life lies in the curves. Cubic Bezier curves should be very familiar to anyone who’s used a vector drawing program. Let’s replace the first segment in our square with a cubic Bezier segment. Now, the SVG shorthand becomes:

M 0,0 C 25,-25 50,25 100,0 L 100,100 L 0,100 z

When rendered, we get this:

The shorthand command says curve to (100,0), but start out heading towards control point #1 at (25,-25) and end up coming in from control point #2 at (50,25).

Arcs

Again, let’s replace the first segment in our square with an arc segment. Now, the SVG shorthand becomes:

M 0,0 A 50,25 0 0,1 100,0 L 100,100 L 0,100 z

When rendered, we get this:

The shorthand command says arc to (100,0), with an x-radius of 50 and a y-radius of 25, with a rotation of 0. The large-arc and sweep flags are a little confusing so you’ll want to review the SVG Spec, § 8.3.8 if you need to get down and dirty with arcs.

Conclusion

I’m a firm believer in “right tool for the job.” So, when in comes to getting SVG path data into Flex, I’m definitely going to use Illustrator or Inkscape as much as possible, and in the future I might just use Catalyst for everything. But there are a few important situations where the Flex developer absolutely must know SVG. First, if you want to do any kind of path morphing (like this), you’ll need precision control over your path segments. And second, if you want to do any dynamic path generation (like building a multi-level radial menu on the fly – which sounds like a good topic for a future post), you’ll need to manually construct your SVG paths.

Files

• square-path.svg
• square-curve.svg
• square-arc.svg

But there is one trick for Inkscape: even though the coordinate origin on the Inkscape document is the normal cartesian origin in the bottom left and the y-axis points up, the SVG output always uses the upper left corner of the document as the origin and the y-axis points down (per the SVG Spec, § 7.3).

To demonstrate, I created a new document in Inkscape, set my dimensions to 500 x 500, and placed a simple path (which happens to be a square) in the upper left corner:

You can see by the rulers in Inkscape that the square’s origin is at (0,500).

If we save our square and examine the SVG output, we see:

<svg ...>
  <g ...>
    <path d="M 0,0 L 100,0 L 100,100 L 0,100 L 0,0 z" />
  </g>
</svg>

If we ignore everything in the file except the relevant path data, we can see the very first path command is M 0,0 which is path-speak for move to (0,0). This is exactly as expected from the SVG spec: upper left is the coordinate origin. The cartesian origin in Inkscape is bogus!

Next, we can just copy the path data from the SVG file and paste it into the data attribute of a Degrafa Path component.

<Degrafa:Path data="M 0,0 L 100,0 L 100,100 L 0,100 L 0,0 z">
    <Degrafa:fill>
        <Degrafa:SolidFill color="#EECCEE" />
    </Degrafa:fill>
    <Degrafa:stroke>
        <Degrafa:SolidStroke color="#FF00FF" weight="3" />
    </Degrafa:stroke>
</Degrafa:Path>

Give it a fill color and a stroke color, and we get a pretty purple square. Now I know my Degrafa Path component will have a square in the upper left, because I know my square was in the upper left in Inkscape. Nice and easy.

Files

• square.svg
• Square (download)

Design

I knew right away that the design was not going to have any right angles, but I also didn’t want to go with rounded rectangles everywhere. Modern TVs tend to have a lot of soft rounded edges, so I decided to go with a more vintage look. So I fired up Inkscape and got to work:

Implementing the video player design above in Degrafa, the cabinet mapped to a RoundedRectangle, and the screen & antenna became Paths. You can read more about about translating SVG to Degrafa in my Inkscape SVG to Degrafa Path article. But for now, let’s focus on the resulting Degrafa code:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application
        xmlns:mx="http://www.adobe.com/2006/mxml"
        xmlns:Degrafa="http://www.degrafa.com/2007"
        layout="absolute">
 
    <Degrafa:GeometryComposition graphicsTarget="{[box]}">
        <!-- Antenna -->
        <Degrafa:Path data="...path data...">
            <Degrafa:transform>
                <Degrafa:TranslateTransform x="15" />
            </Degrafa:transform>
        </Degrafa:Path>
 
        <!-- TV cabinet -->
        <Degrafa:RoundedRectangle y="144" width="350" height="300"
                cornerRadius="20" />
 
        <Degrafa:fill>
            <Degrafa:SolidFill color="#333333" />
        </Degrafa:fill>
        <Degrafa:stroke>
            <Degrafa:SolidStroke color="#FF00FF" weight="4" alpha="0.4" />
        </Degrafa:stroke>
    </Degrafa:GeometryComposition>
 
    <!-- TV Screen -->
    <Degrafa:GeometryComposition graphicsTarget="{[tvscreen]}">
        <Degrafa:Path data="...path data...">
            <Degrafa:fill>
                <Degrafa:SolidFill color="#FF99FF" />
            </Degrafa:fill>
            <Degrafa:stroke>
                <Degrafa:SolidStroke color="#FF00FF" weight="2" alpha="0.4" />
            </Degrafa:stroke>
            <Degrafa:filters>
                <mx:GlowFilter color="#EEEEEE" alpha="0.2" blurX="16" blurY="16" />
            </Degrafa:filters>
        </Degrafa:Path>
    </Degrafa:GeometryComposition>
 
    <mx:Canvas width="350" height="444"
            horizontalCenter="0" verticalCenter="0">
        <mx:Canvas id="box" />
        <mx:Canvas x="50" y="174" id="tvscreen" />
    </mx:Canvas>
</mx:Application>

I ended up using a pair of GeometryCompositions to wrap my three shapes to help keep my fills, strokes, and filters organized. It made sense to do it this way, but I won’t claim it’s the best way. Throw the control bar on below the TV screen, and the design is done.

Backend

The backend is build on the OvpNetStream class provided by the Open Video Player project. OvpNetStream extends NetStream and smooths out some of the rough edges as I discussed previously. Basically, it provides a sane interface (no need to construct a dynamic object with function callbacks) and useful events (like metadata and progress events).

For this demo, we simply instantiate OvpNetStream on creationComplete and wire up all the event handlers:

private function complete():void {
    nc = new OvpConnection();
    nc.addEventListener(OvpEvent.ERROR, errorHandler);
    nc.addEventListener(NetStatusEvent.NET_STATUS, connStatusHandler);
    nc.connect(null);
 
    ns = new OvpNetStream(nc);
    ns.addEventListener(OvpEvent.ERROR, errorHandler);
    ns.addEventListener(NetStatusEvent.NET_STATUS, streamStatusHandler);
    ns.addEventListener(OvpEvent.NETSTREAM_METADATA, streamMetadataHandler);
    ns.addEventListener(OvpEvent.PROGRESS, streamProgressHandler);
    ns.addEventListener(OvpEvent.COMPLETE, streamCompleteHandler);
 
    vid = new Video();
    vid.attachNetStream(ns);
    vidContainer.addChild(vid);
}

The most interesting events are the metadata and progress events. The metadata event delivers the duration of the video and its size. The progress event arrives periodically (theoretically every 100ms by default, but in reality I see them come in just a couple of times per second) and delivers the current video time.

Control Bar

The control bar consists of three components: a play-pause button, a scrubber, and a volume slider. They were skinned using Degrafa in Part 1. In order to control video playback, we need to wire the control bar components to the instance of OvpNetStream created above.

Here are the event handlers for the three control bar components:

// PlayPause event handler
private function playPauseClick():void {
    if (first) {
        first = false;
        ns.play(filename);
    } else {
        ns.togglePause();
     }
}
 
// Scrub event handlers
private function scrubPress():void {
    ns.pause();
    playPause.selected = false;
}
private function scrubDrag():void {
    ns.seek(scrub.value);
}
private function scrubRelease():void {
    ns.togglePause();
    playPause.selected = true;
}
 
// Volume event handler
private function volumeChange():void {
    ns.volume = volume.value;
}

In the playPauseHandler(), the initial click calls play() which actually loads the video (and then starts playback), all subsequent clicks just toggle between play or pause. For the scrubber handlers, I chose to break them up into three separate steps: on mouse down pause the video, on mouse up restart playback, and on drag attempt to seek to the to the new time.

That’s it. Here is the resulting Degrafa-skinned video player (view source enabled):

Click Play to start playing Elephants Dream (which is the “world’s first open movie,” and pretty cool too). Right away you’ll notice some visual issues because the dimensions of the video are unknown until the metadata arrives. Also, scrubbing has some problems which I believe are related to cue points in progressive downloads. Lastly, I didn’t implement any indicators for buffering or download progress, so you’ll need to be patient. Since this is just a demo, I’ll have to leave fixing those bugs as an exercise for the reader.

Files

• Video Player (download)

Button

To get started, I built out a simple button skin with a slight shine on the top half. I also added rounded corners to give the classic web 2.0 look-and-feel. There’s really not much to look at:

Play-Pause Button

I’m using a toggleable Button component as the base of my Play-Pause button. By leveraging Degrafa’s stateful skins, I simply change the visibility of the Play and Pause geometry depending on the skin’s state. Here’s a snippet from the states block of the skin:

<states>
    <State name="upSkin">
        <SetProperty target="{rect}" name="fill" value="{upFill}"/>
        <SetProperty target="{play}" name="visible" value="true"/>
    </State>
    <State name="selectedUpSkin">
        <SetProperty target="{rect}" name="fill" value="{upFill}"/>
        <SetProperty target="{play}" name="visible" value="false"/>
    </State>
    ...
</states>

Additionally, the play arrow and pause bars are dynamically sized based on the button height, so they readily scale to any size. The result:

Scrubber

Getting total control over a Slider skin is not easy in Flex 3. There are two issue that I find quite annoying: the thumb size is hard-coded into the class and the highlight skin is offset from the track. Fortunately, the web is full of workarounds for the thumb size issue, but for this skin I only needed to hard-code an offset (+6,+6) to bring the thumb’s origin to (0,0) and make all my geometry line up correctly. Similarly, I added a 1 pixel offset to the highlight skin to bring its origin to (0,0) to match the track. The result:

Volume Slider

For consistency, the Volume slider re-uses the Scrubber’s thumb skin, but the track and highlight are wedges (Polygon‘s in Degrafa). The only clever piece of code is the highlight skin’s overridden updateDisplayList() function:

override protected function updateDisplayList(unscaledWidth:Number, unscaledHeight:Number):void {
    super.updateDisplayList(unscaledWidth, unscaledHeight);
    awidth = unscaledWidth;
    aheight = unscaledHeight;
 
    if (this.hasOwnProperty('parent') &&
             this.parent.hasOwnProperty('parent') &&
             this.parent.parent.hasOwnProperty('width') &&
             this.parent.parent.width > 0) {
        _ratio = awidth / this.parent.parent.width;
    } else {
        _ratio = 0.00001;
    }
}

In order to correctly draw the highlight wedge, we first need to know the dimensions of the track. For simplicity, the Volume track height is hard-coded in both the track skin and highlight skin, but the width of the track is variable. In this case, the width of the track is the same as the width of the HSlider component itself. So in the updateDisplayList() code above, the track width is found and used to compute the ratio of widths. This ratio is later used to draw the highlight geometry. The end result:

The Full Control Bar

Just displaying all the components side-by-side gives us the beginnings of a video player control bar:

Not too shabby. In Part 2, I’ll assemble the final video player frontend including the pretty control bar components above, and weld it to an OvpNetStream-powered backend.

Files

• Button (download)
• Play-Pause Button (download)
• Scrubber (download)
• Volume Slider (download)
• The Full Control Bar (download)

My main interest in the nested SWFs approach is for performance reasons, both the reduced initial download size and the ability to defer component creation can make a big difference in the real world. And secondarily for testing reasons, because it’s just awesome to see a big enterprise app wired up via hudson with FlexMonkey and Fluint tests.

None of this would be very interesting without the ability to communicated between SWFs. Thankfully, there are a few good options when talking between Flash 9 SWFs, because they run together inside Flash Player in AVM2. Talking between Flash 9 or newer and Flash 8 or older is still possible, but because of the AVM1/AVM2 split you need to use LocalConnection which I’m not going to get into.

Child Application

How does SWF to SWF communication work? First, let’s start with a simple child app:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
 
    <mx:Script>
        <![CDATA[
            [Bindable] public var myProp:String = 'foo';
 
            private function btnClick():void {
                dispatchEvent(new Event('child'));
            }
            public function myFunc(color:uint):void {
                setStyle('backgroundColor', color);
            }
            public function myFuncReturn(i:int, j:int):int {
                return i + j;
            }
        ]]>
    </mx:Script>
 
    <mx:Label text="{'myProp = ' + myProp}" />
    <mx:Button label="dispatch event" click="btnClick()" />
</mx:Application>

The child app exposes one public property myProp, two public functions myFunc and myFuncReturn, and a custom event.

Main Application

The main app exercises all four options in the child SWF. But in an effort to mimic reality, I’m imposing the additional constraint that while the child’s API is known, the actual MXML is unavailable.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" verticalGap="12">
    <mx:Script>
        <![CDATA[
            import mx.controls.Alert;
            import mx.events.FlexEvent;
            import mx.managers.SystemManager;
 
            private var childApp:Application;
 
            private function init():void {
                SystemManager(loader.content).addEventListener(
                        FlexEvent.APPLICATION_COMPLETE, childReady);
              }
 
              private function childReady(e:FlexEvent):void {
                  childApp = e.target.application as Application;
                  childApp.addEventListener('child', childEventHandler);
              }
              private function childEventHandler(e:Event):void {
                  Alert.show('got child event');
              }
 
              private function setChildProp():void {
                  if (childApp.hasOwnProperty('myProp')) {
                      childApp['myProp'] = 'bar';
                  }
            }
            private function callChildFunc():void {
                if (childApp.hasOwnProperty('myFunc') &&
                        childApp['myFunc'] is Function) {
                    childApp['myFunc'](0xFF00FF);
                }
            }
            private function callChildFuncReturn():void {
                if (childApp.hasOwnProperty('myFuncReturn') &&
                        childApp['myFuncReturn'] is Function) {
                    var val:int = childApp['myFuncReturn'](13, 4);
                    Alert.show('13 + 4 = ' + val);
                }
            }
        ]]>
    </mx:Script>
 
    <mx:Panel title="Child">
        <mx:SWFLoader id="loader" source="test_child.swf" complete="init()" />
    </mx:Panel>
 
    <mx:Button label="set child property" click="setChildProp()" />
    <mx:Button label="call child func" click="callChildFunc()" />
    <mx:Button label="call child func return" click="callChildFuncReturn()" />
</mx:Application>

In the main app, the child SWF is loaded via the SWFLoader MXML tag, which calls the init() function on completion. Then we wait for the child SWF to finish loading before casting it to an Application and wiring up a handler for our custom event. The other three child-to-parent communication options are exercised by the three button click callback functions. In each callback, we first check to see if the child property exists, and in the case of the two function calls, if it can be cast to a Function. In the Adobe docs, because the child MXML code is in the same folder as the parent MXML, they just use a simple cast prior to invoking functions:

FlexApp(loadedSM.application).setVarOne("Updated varOne!");

Which is great for them because they control both the parent and the child SWFs, but doesn’t really work when you have some 3rd party SWF you need to use or Creative lobs some crazy flash animation grenade into your cube at 5:15pm with a nice note to send over a working solution before you go home for the evening. Yep, that never happens.

There is another point that I often forget about MXML: instantiation via tags creates a public instance of the component. So for example, if we added id attributes to the child label and child button, then they would be directly accessible in the parent via childApp['childLabel'].text or childApp['childButton'].addEventListener(...). I find my sense of API cleanliness is deeply offend by this manner of communication, so I tend to stick with one of the four options I described above (probably why I always forget).

Here is the final product:

 »  Main App

Digging Deeper: If you really want to maximize client-side performance, you might find yourself loading and unloading child SWFs. In such a situation, it is important to be a good citizen and make sure your child SWFs clean up after themselves.

Files

• Child App (download)
• Parent App (download)

And like those before me, I’ve come to the same conclusion about video in Flash: it’s pretty cool, but I sure wish it was better. Enter the Open Video Player as the answer to some of NetStream‘s woes. Alas, all of the OVP docs and samples are, once again, all about streaming, Akamai, bandwidth, etc.

The elephant in the room for an AIR video player: What if I’m offline?

The Easy Way: VideoDisplay

I gonna get started with the easiest possible local video player, which in Flex means using VideoDisplay. Here’s a simple AIR app that allows you to open a FLV file and play it:

<?xml version="1.0" encoding="utf-8"?>
<mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml"
        width="700" height="500">
 
    <mx:Script>
        <![CDATA[
            [Bindable] private var filename:String = '';
 
            private function openVideo():void {
                if (vd.playing) {
                    vd.pause();
                    playPause.label = 'PLAY';
                }
 
                var docs:File = File.documentsDirectory;
                docs.browseForOpen('Select a Video', [new FileFilter("Video", "*.flv")]);
                docs.addEventListener(Event.SELECT, openFileHandler);
            }
 
            private function openFileHandler(e:Event):void {
                var f:File = e.target as File;
                filename = f.name;
 
                vd.source = 'file://' + f.nativePath;
                vd.play();
            }
 
            private function stopClick():void {
                vd.stop();
                playPause.label = 'PLAY';
            }
 
            private function toggleClick():void {
                if (vd.playing) {
                	vd.pause();
                	playPause.label = 'PLAY';
                } else {
                	vd.play();
                	playPause.label = 'PAUSE';
                } 
            }
        ]]>
    </mx:Script>
 
    <mx:ApplicationControlBar dock="true">
        <mx:Button label="Open Video" click="openVideo()" />
        <mx:Label text="{filename}" fontSize="14" fontWeight="bold" />
    </mx:ApplicationControlBar>
 
    <mx:Canvas width="100%" height="100%" backgroundColor="#000000" backgroundAlpha="0.1">
    	<mx:VideoDisplay id="vd" autoPlay="false" />
    </mx:Canvas>
 
    <mx:HBox>
        <mx:Button id="playPause" label="PAUSE" width="100" click="toggleClick()" />
        <mx:Button label="STOP" width="100" click="stopClick()" />
    </mx:HBox>
</mx:WindowedApplication>

The only real magic is the vd.source = 'file://' + f.nativePath line. Apparently, source wants a URL even for a local file, so just prepend file:// and everything works fine.

Getting Fancy with NetStream

As far as I can tell, no one actually uses VideoDisplay at the core of a video player component in a production system. The many benefits of NetStream are not really clear to me, but it is the darling of production systems. Thankfully, despite its name, NetStream is perfectly happy playing local video. Rebuilding the above example yields:

<?xml version="1.0" encoding="utf-8"?>
<mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml"
        width="700" height="500"
        applicationComplete="complete()">
 
    <mx:Script>
        <![CDATA[
            [Bindable] private var filename:String = '';
            private var nc:NetConnection;
            private var ns:NetStream;
            private var vid:Video;
            private var t:Timer;
 
            private function complete():void {
                nc = new NetConnection();
                nc.addEventListener(AsyncErrorEvent.ASYNC_ERROR, errorHandler);
                nc.addEventListener(NetStatusEvent.NET_STATUS, connStatusHandler);
                nc.connect(null);
 
                ns = new NetStream(nc); 
                ns.addEventListener(AsyncErrorEvent.ASYNC_ERROR, errorHandler);
                ns.addEventListener(NetStatusEvent.NET_STATUS, streamStatusHandler);
                ns.client = { onMetaData:streamMetadataHandler };
 
                t = new Timer(300);
                t.addEventListener(TimerEvent.TIMER, streamProgressHandler);
 
                vid = new Video();
                uic.addChild(vid);
            }
 
            private function openVideo():void {
                if (ns) {
                    ns.pause();
                    playPause.label = 'PLAY';
                }
 
                var docs:File = File.documentsDirectory;
                docs.addEventListener(Event.SELECT, openFileHandler);
                docs.browseForOpen('Select a Video', [new FileFilter("Video", "*.flv")]);
            }
 
            private function openFileHandler(e:Event):void {
                var f:File = e.target as File;
                filename = f.name;
 
                ns.play('file://' + f.nativePath);
                playPause.label = 'PAUSE';
 
                vid.attachNetStream(ns);
 
                t.start();
            }
 
            private function errorHandler(e:AsyncErrorEvent):void {
                trace('ERROR: ' + e.text);
            }
 
            private function connStatusHandler(e:NetStatusEvent):void {
                trace('CONN_STATUS: ' + e.info.code);
            }
 
            private function streamStatusHandler(e:NetStatusEvent):void {
                trace('STREAM_STATUS: ' + e.info.code);
            }
 
            private function streamMetadataHandler(info:Object):void {
                for (var key:String in info) {
                    trace("STREAM_METADATA: " + key + "=" + info[key]);
                }
                uic.width = info.width;
                uic.height = info.height;
 
                vid.width = info.width;
                vid.height = info.height;
                vid.x = 0;
                vid.y = 0;
 
                len.text = parseFloat(info.duration).toFixed(1);    
            }
 
            private function streamProgressHandler(e:TimerEvent):void {
                   timer.text = ns.time.toFixed(1);
            }
 
            private function stopClick():void {
                ns.pause();
                ns.seek(0);
                playPause.label = 'PLAY';
            }
 
            private function toggleClick():void {
                ns.togglePause();
                playPause.label = (playPause.label == 'PAUSE' ? 'PLAY' : 'PAUSE');
            }
        ]]>
    </mx:Script>
 
    <mx:ApplicationControlBar dock="true">
        <mx:Button label="Open Video" click="openVideo()" />
        <mx:Label text="{filename}" fontSize="14" fontWeight="bold" />
        <mx:Label id="timer" fontSize="14" fontWeight="bold" />
        <mx:Label id="len" fontSize="14" fontWeight="bold" />
    </mx:ApplicationControlBar>
 
    <mx:Canvas width="100%" height="100%" backgroundColor="#000000" backgroundAlpha="0.1">
        <mx:UIComponent id="uic" width="100" height="100" />
    </mx:Canvas>
 
    <mx:HBox>
        <mx:Button id="playPause" label="PAUSE" width="100" click="toggleClick()" />
        <mx:Button label="STOP" width="100" click="stopClick()" />
    </mx:HBox>
</mx:WindowedApplication>

NetStream is a wonder of engineering. Basic usage is understandable, just feed in null to the NetConnection to switch to progressive download mode, and use the same file:// trick above to play a local video. But after that, things get weird fast. First, the metadata handling to totally backwards: you have to create a dynamic object with a onMetaData property that maps to a callback function. My guess would be that there is some legacy bullshit going on that breaks addEventListener. Second, you can’t tell if a video is playing or not. Third, the lack of progress event means you need to use a timer to track playhead time. Add it up – LAME.

Reaching for the Grail: Open Video Player

According to their website, it’s Open Video Player to the rescue. And I’ll have to agree that it fixes many of NetStream issues. Swaping in OvpNetStream yields:

<?xml version="1.0" encoding="utf-8"?>
<mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml"
        width="700" height="500"
        applicationComplete="complete()">
 
    <mx:Script>
        <![CDATA[
            import org.openvideoplayer.net.OvpConnection;
            import org.openvideoplayer.net.OvpNetStream;
            import org.openvideoplayer.events.OvpEvent;
 
            [Bindable] private var filename:String = '';
            private var nc:OvpConnection;
            private var ns:OvpNetStream;
            private var vid:Video;
 
            private function complete():void {
                nc = new OvpConnection();
                nc.addEventListener(OvpEvent.ERROR, errorHandler);
                nc.addEventListener(NetStatusEvent.NET_STATUS, connStatusHandler);
                nc.connect(null);
 
                ns = new OvpNetStream(nc);
                ns.addEventListener(OvpEvent.ERROR, errorHandler);
                ns.addEventListener(NetStatusEvent.NET_STATUS, streamStatusHandler);
                ns.addEventListener(OvpEvent.NETSTREAM_METADATA, streamMetadataHandler);
                ns.addEventListener(OvpEvent.PROGRESS, streamProgressHandler);
 
                vid = new Video();
                uic.addChild(vid);
            }
 
            private function openVideo():void {
                if (ns) {
                    ns.pause();
                    playPause.label = 'PLAY';
                }
 
                var docs:File = File.documentsDirectory;
                docs.addEventListener(Event.SELECT, openFileHandler);
                docs.browseForOpen('Select a Video', [new FileFilter("Video", "*.flv")]);
            }
 
            private function openFileHandler(e:Event):void {
                var f:File = e.target as File;
                filename = f.name;
 
                ns.play('file://' + f.nativePath);
                playPause.label = 'PAUSE';
 
                vid.attachNetStream(ns);
            }
 
            private function errorHandler(e:OvpEvent):void {
                trace('ERROR: ' + e.data.errorNumber + ': ' + e.data.errorDescription);
            }
 
            private function connStatusHandler(e:NetStatusEvent):void {
                trace('CONN_STATUS: ' + e.info.code);
            }
 
            private function streamStatusHandler(e:NetStatusEvent):void {
                trace('STREAM_STATUS: ' + e.info.code);
            }
 
            private function streamMetadataHandler(e:OvpEvent):void {
                for (var key:String in e.data) {
                    trace("STREAM_METADATA: " + key + "=" + e.data[key]);
                }
                uic.width = e.data.width;
                uic.height = e.data.height;
 
                vid.width = e.data.width;
                vid.height = e.data.height;
                vid.x = 0;
                vid.y = 0;
 
                len.text = nc.streamLengthAsTimeCode(e.data.duration);
            }
 
            private function streamProgressHandler(e:OvpEvent):void {
                   timer.text = ns.timeAsTimeCode;
            }
 
            private function stopClick():void {
                ns.pause();
                ns.seek(0);
                playPause.label = 'PLAY';
            }
 
            private function toggleClick():void {
                ns.togglePause();
                playPause.label = (playPause.label == 'PAUSE' ? 'PLAY' : 'PAUSE');
            }
        ]]>
    </mx:Script>
 
    <mx:ApplicationControlBar dock="true">
        <mx:Button label="Open Video" click="openVideo()" />
        <mx:Label text="{filename}" fontSize="14" fontWeight="bold" />
        <mx:Label id="timer" fontSize="14" fontWeight="bold" />
        <mx:Label id="len" fontSize="14" fontWeight="bold" />
    </mx:ApplicationControlBar>
 
    <mx:Canvas width="100%" height="100%" backgroundColor="#000000" backgroundAlpha="0.1">
        <mx:UIComponent id="uic" width="100" height="100" />
    </mx:Canvas>
 
    <mx:HBox>
        <mx:Button id="playPause" label="PAUSE" width="100" click="toggleClick()" />
        <mx:Button label="STOP" width="100" click="stopClick()" />
    </mx:HBox>
</mx:WindowedApplication>

It’s not a revolution because OvpNetStream just extends NetStream, but we instantly get standard events thrown for progress ticks and metadata, and also some pretty time formatting as a bonus. The OVP also does about a hundred other things related to streaming, streaming servers, and Akamai. That’s about all I know about video right now, so before I can post again I’ll need to learn something new…

Files

Just tarballs (it’s an AIR app after all):

• test_vid.tgz (using VideoDisplay)
• test_vid_stream.tgz (using NetStream)
• test_vid_ovp.tgz (using Open Video Player)

ButtonBar

First, I built out a pair of ButtonBar skins (view source enabled):

ToggleButtonBar

Next, I augmented the my basic ButtonBar skins with the various required selected skins (selectedUpSkin, selectedDownSkin, etc.) to create a pair of ToggleButtonBar skins (view source enabled):

iPhone Theme

Lastly, I dissected the iPhone-esque theme sample from the Degrafa Samples page, and created my own bastardized iPhone theme. I factored out a theme color from each component into a CSS style called mainColor to allow the skin to be tweaked. Check it out (view source enabled):

Conclusions

I learned a couple of things during my skinning exercise, but probably the most important came to me in an amazing “A-Duh” moment: Degrafa is really powerful. This is probably the same as saying MXML is a high-level language with a lot of leverage, but the Degrafa team has done a great job bringing this leverage to bear on skinning and graphics in Flex. At this point, I find it hard to imagine creating a style without it.

Secondly, semantic naming is a must inside a stateful skin. So, I replaced any names like darkFill or lightStroke, with nice semantic names like overFill and selectedStroke. So if I look at a chunk of code like this:

<State name="downSkin">
    <SetProperty target="{rect}" name="fill" value="{overFill}" />
</State>

I can immediately know that my downSkin state is using a fill from my overSkin state, and probably implies the states are the same.

Lastly, always resist the temptation to re-use/re-purpose the CSS style from the underlying component in a skin. For example, the iPhone theme above uses a theme color which I intentionally named mainColor. I could easily have used Button’s aptly-named themeColor style (inherited down from UIComponent). But this would dangerously overload the meaning of themeColor, because while it normally controls the Button’s border color it would now control the body color in my iPhone button skin.

Files

• ButtonBar (download)
• ToggleButtonBar (download)
• iPhone Theme (download)

Building Buttons

With a very minimal amount of effort, I was able to create a few “web 2.0″ button skins. I just followed one of the millions of glass button photoshop tutorials, but did the work in mxml code using Degrafa’s declarative syntax. Here are my results (view source enabled):

Button Explorer

But then I decided to take it a step further and build out a Degrafa Button Explorer (with a small tip of the hat to the original Flex Style Explorer). The Degrafa Button Explorer allows you to adjust a bunch of properties and colors for all three buttons styles. It goes a step further than the original and provides not only the CSS, but also the full code of the stateful Degrafa-powered button components.

 »  Degrafa Button Explorer

Digging Deeper: I’ve been following the skinning performance issues discovered by the guys at EffectiveUI. The most recent benchmarks appear to show that stateful Degrafa skins (like those produced by the Degrafa Button Explorer) are safe to use.