I’ve just made my first commit to GitHub, and it consists of a modified version of as3syndication lib that will work in the Flash IDE. You may recall that earlier I proposed the fix and offered the files here. Now, if you prefer, you can just go to my profile at GitHub.

The people may now rejoice.

I’d like to take a moment to draw your attention to a very useful class that’s been around for some time, but that I’ve never really bothered to use: flash.system.Capabilities. It gives you all kinds of useful information about the environment your SWF currently resides in. I’ve got an example below.

The SWF above (with any luck) should tell you whether or not you’re running a debug version of flashplayer, who the manufacturer of your flash plugin is, what operating system you’re running, what player type you’re using (should be plugin on this page), and what version of the flash player you’re running.

If you download the files for this demo here and run the SWF on your local machine, you should see a different value in the player type field.

The player type is the most useful piece of information to me. In theory you could use it to load different data or behave differently in general depending on whether you’re viewing your SWF in the Flash IDE or on a webpage, without having to add your own obnoxious boolean “debug” flags.

I’m pleased to formally announce the relaunch of my portfolio at www.agitcraft.com. It’s been a long,  winding, mostly poorly organized effort on my part consisting of numerous missteps and restarts. I’ve technically been working on this iteration of the site for about 4 months (from scratch), although I’ve been grinding away at redesign efforts both with this domain and with my previous portfolio at altpixel.net for well over two years now. To give you a vague idea of how long this has been brewing, the svn I’ve been working out of is currently in revision 381 after going through at least 4 branches, and I’m the only person developing this.

I’d also like to take this opportunity to give credit where credit is due:

• Jack Doyle for the greensock tweening platform (which makes all the animation in the site possible), without which I’m sure I would have gone crazy long ago.
• The entire Papervision3d team for their excellent 3D package, which powers the 3D “solar system” motif that I use to display my interface.
• The team of developers who’ve thus far worked on as3syndicationlib. There were a couple issues I ran into, but they were minor in the long run and they certainly don’t take away from the fact that I was able to parse and consolidate 5 feeds in real time with only a few lines of code. Awesome!
• The developers of PureMVC, for making a framework that has literally changed the way that I work on large projects and made my site possible.
• Matt McInerny at the League of Movable Type for providing the fantastic “Raleway” typeface I’m using both in my logo and for section headers.
• An anonymous sound fx provider at flashkit.com for providing the ominous intro tune that plays when the site loads. I say anonymous because I was inattentive when I grabbed the audio and forgot to take note of the name/location of the file I snagged. I dug around today but could not, for the life of me, find the file on there. If anybody recognizes it let me know and I’ll give a proper shout out.

The wealth of libraries and tools freely available is part of what makes Flash such an exciting platform to develop for. I certainly could not have completed a project of this scale without them.

Anyway, if you like the site let other people see it. If you have problems with it let me know. I’m hoping this remains a growing work rather than a one-off showpiece.

It’s time to speak about a problem that’s been troubling me for quite a while now. Flash CS4 (and certainly versions that precede it) seems to have major problems consistently and accurately rendering text. I’ve prepared some screen captures that demonstrate the problem.

Text Field Properties

It all begins innocently enough. I’ve created a text field on the stage and I move over to the properties panel to toy with it. In this case, the text field uses Arial Regular at 12 points as its font. It’s anti-aliased for readabilty, and it’s selectable.

Embedded Characters

Although I don’t expect that any of my viewers will be without Arial, I embed the font all the same. I make a broad selection of characters that should cover most if not all of my use cases for this text field, without embedding everything.

Editing Text

Now that I’ve configured my text field, I select it on the stage and put in some standard lorem ipsum to test my application with. Everything up to this point seems fine…

How Text Renders

…until I finish editing the text. Now that I have it selected, but am no longer editing it, everything has changed. Compare this screen capture to the one that precedes it.

This problem is not new. It’s particularly pernicious when you’re trying to align other objects with on-screen text.

Perhaps you, like me, have had a need, at some point or another, to parse RSS feeds in Actionscript. If so, then perhaps you’ve also stumbled across the generally wonderful as3syndicationlib developed by Mike Chambers and Christian Cantrell. For those of you who aren’t in the know, allow me to provide the following excerpt from the project’s google code page:

Use the syndication library to parse Atom and all versions of RSS easily. This library hides the differences between the formats so you can parse any type of feed without having to know what kind of feed it is.

These claims actually hold up pretty well…once you get the code running.

The problem is that the codebase was written specifically for development in Flex. While Flex is a great platform for certain projects, many of us still use Flash for a lot of the work we do, so a toolkit that relies on packages that are only available to Flex just doesn’t do it.

This problem is also no secret. It’s listed as an accepted issue on its project page. The problem is that the codebase apparently hasn’t been updated since December of 2006.  That’s no joke kids.

Fortunately, a solution was pushed forth from outside the project by a Mr. Martin Legris in the form of a bare implementation of the missing “DateBase” class that the syndication library looks for, as well as an edit to an import statement buried down in ParsingTools.as.

So if you, like me, have a need to consume RSS/Atom Feeds in Flash and need a solution that works, look no further. I present, to you, an updated version of the as3 syndication library with the necessary changes in place to begin using it out of the box in your flash projects.

The files are all available here.

I received quite a response yesterday to my post offering a circular fill animation. First of all, I had a brief conversation with Frank Salim.

Frank: drawArc

?

is there a reason that isn’t an appropriate solution?

me: drawArc isn’t a function in flash.display.graphics

Frank: wacky

arcTo is a function on the canvas 2d context in html5

me: There is a curveTo function that takes 2 anchor points

Frank: are there any curve functions?

ok

me: but it’s not very intuitive

and this is easier

once the asset exists

Frank: can an asset contain code

me: sure

Frank: shrug

1. Write perfect code.
2. Use Runtime Error Handling

Some day I’ll elaborate on the secrets of the first option(1, 2), but for the time being I’d like to talk about Runtime Error Correction and Handling.

Let me begin by explaining what a runtime error is. As compared to a Compile Error, which is caught on compilation, or a Logical Error, which is due to fuzzy logic on the part of the programmer, a Runtime Error is an error that occurrs in your code while it is executing.

Flash has several types of Runtime errors that are thrown at different times depending on the type of error that occurrs. As somebody who works with Flash every day, I can say with some confidence that the most important and common ones for you to worry about are TypeErrors, ReferenceErrors, and RangeErrors. You may also find yourself occasionally encountering SecurityErrors and SyntaxErrors, but for now we’ll just worry about the first three.

How do these errors occur? Let’s break it down one by one.

TypeErrors

Type errors generally occur when you improperly coerce the value of one variable to the type of some incompatible “other” variable. What does this mean? Here’s an example:

var mov = getChildByName("myMovieClip");
mov.gotoAndPlay(2);

The code above will throw an error because you’re implicitly (rather than explicitly) trying to coerce a DisplayObject into behaving like a MovieClip. What the hell am I talking about? Well, if you check the documentation for the “getChildByName” method on the MovieClip class, you’ll see that it returns a DisplayObject. What this means is that whenever you call this method without explicitly casting its return object, Flash is going to assume you’re just talking about a vanilla, plain-jane DisplayObject.

Here are two solutions:

var mov = getChildByName("myMovieClip") as MovieClip;

…or…

var mov = MovieClip(getChildByName("myMovieClip"));

Both lines of code do the same thing. For the sake of readability, I prefer the first method.

ReferenceErrors

Reference Errors occur when you try to access or set a property that doesn’t exist on a non-dynamic class. For people who are new to object oriented programming in AS3, this will happen for a while until you really appreciate the difference between a dynamic and a non-dynamic class. Let’s look at an example.

package {
     public class Foo() {
          public function Foo() {
               trace(this.bar);
          }
     }
}

The example above will throw a Reference Error because the class Foo doesn’t have a property named “bar.” I have two solutions.

package {
public class Foo() {
     public var bar:*;
          public function Foo() {
               trace(this.bar);
          }
     }
}

In the above example, we just made sure that the public class Foo does have a property named “bar.”

package {
     public dynamic class Foo() {
          public function Foo() {
               trace(this.bar);
          }
     }
}

In this second example, we made the public class Foo into a dynamic class. What this means is that we can refer to any property we want on Foo, and if it doesn’t exist Flash will create it for us automatically. This may sound like a very tempting proposition, but the first approach is most definitely preferred on this one, which is a point I will explain at a later date. For the time being, just take my word for it: Avoid making your classes dynamic if you can.

RangeErrors

A Range Error occurs when you attempt to refer to an index that doesn’t exist in an Array. For example:

var shitty_bands:Array = [ "Slipknot", "Linkin Park", "Insane Clown Posse"];
trace(shitty_bands[3]);

The code above will generate a range error because the shitty_bands array doesn’t have any entries at an index of 3. You’ve literally referred to an entry that is out of the range of the array, making this a pretty easy error to remember. To solve, you could…

var shitty_bands:Array = [ "Slipknot", "Linkin Park", "Insane Clown  Posse"];
trace(shitty_bands[shitty_bands.length-1]);

…use properties of the array to make sure that you don’t refer to entries outside of its range, which also saves you the trouble of actually needing to know the number of entries in the array at any given point (assuming you were just trying to grab the last item in the array), or you could…

var shitty_bands:Array = [ "Slipknot", "Linkin Park", "Insane Clown  Posse", "The Black Eyed Peas"];
trace(shitty_bands[3]);

…just add another shitty band to the array.

Admittedly, these are stop-gap solutions that all depend on what you’re actually trying to accomplish with your program. There is one final solution.

Explicit Error Handling

What do I mean by Explicit Error Handling? I mean that you anticipate when portions of your code may throw errors, and set up appropriate control structures to deal with them when they happen. There are two ways to do this, and the method you choose may vary depending on the type of error you anticipate and the amount of code you’re trying to control for. Let’s consider the first method.

Error Event Listeners

Many errors can be taken care of with simple event handlers. Security Errors and IOErrors, for example, have their own event classes that you can listen for.

package {

     import flash.net.*;

     import flash.events.*;

     public class Foo() {

          public function Foo() {

               var loader:URLLoader = new URLLoader();

               loader.addEventListener(SecurityErrorEvent.SECURITY_ERROR, _securityErrorHandle, false, 0, true);

               loader.addEventListener(IOErrorEvent.IO_ERROR, _ioErrorHandle, false, 0, true);

               loader.load(new URLRequest("data.xml"));

          }

     }

     private function _securityErrorHandle(e:SecurityErrorEvent):void {

          trace("SecurityError :: ",e.errorID);

     }

     private function _ioErrorHandle(e:IOErrorEvent):void {

          trace("IOError ::",e.errorID);

     }

}

Depending on how large or complex your application is this may be a good solution for you. I know that in some respects I find this easiest to understand as it runs on the existing Event metaphor that I’m accustomed to using for everything else in AS3.

The second method employs a construct which with, if you have done any programming in the past, you are probably familiar.

package {
     public class Foo() {
          public function Foo() {
               try {
                    trace(this.bar);
               } catch (e:ReferenceError {
                    trace("Reference Error!");
               } finally {
                    // do something else
               }
          }
     }
}

The Try…Catch…Finally construct exists in pretty much every programming language known to man. It’s also pretty simple to understand. The application “attempts” to do whatever is within the “try” statement. If an error occurs, it’s handled in the “catch” statement, and whatever was going to take place in the “try” statement just doesn’t happen. After these steps, the application does whatever is indicated in the “finally” statement. It doesn’t get much easier than that. This is also nice because it forces you to deal with errors at the site of their creation, and to be more thoughtful about where and why errors happen.

I’ve been working, over the last few weeks, with Adobe’s Open Source Media Framework. The OSMF is Adobe’s initiative to provide a standard set of tools and interfaces for deploying video content on the Flash Platform.

The framework is built loosely according to a MVC pattern, in which the Model consists of various MediaElements, the View consists of a MediaContainer, and the Controller consists of a non-displayable MediaPlayer class. As of its current release (Sprint 9), methods of implementation are so varied that it’s hard to find reliable documentation or concrete examples of how to use many of the components of the framework. This makes it difficult to work with so far, but the capabilities being planned and exposed for the project make it very exciting to jump in and start coding.

Today I connected to the project SVN, updated to the latest revision, and jumped back into developing a wrapper that I originally began planning for Sprint 8. I’ve implemented a very simple class based on the latest revision of Sprint 9 which I’m offering you today. I’m calling the project Vidiot to reflect my hope that it will be so easy to use, even an idiot will be able to display video in Flash.

The demo above uses the Vidiot class to play a sample streaming video hosted by Akamai. Layout and playback controls are separate from the Vidiot class. The simplest use case for Vidiot looks like this:

var vidiot:Vidiot = new Vidiot();
addChild(vidiot);
vidiot.load("video path");

At this stage, it doesn’t really get any more complicated than that. You can use Vidiot to play either progressive or streaming video (though thus far I’ve been unable to stream from Edgecast. Hmm….), and in theory this thing is also set up to play audio or still images as well, though I’ll have to test that out and probably update some of the code.

I hope to continue to release new versions of Vidiot and keep it up to date with the latest builds of OSMF. If all goes well you’ll see more posts about this in the future.

Download sample video player and Vidiot source code

UPDATE: Vidiot has been updated. Check out the most recent post.

So, I thought I’d bring attention to a strange inconsistency I run into on a very regular basis while developing applications in Adobe Flash.

Much of the work that I do in flash has to do with displaying and managing video. To date, I have probably created at least 50 different playlist enabled video players, by which I mean video players with a list of either links, thumbnails, or both that allow you to play other videos in the same container without leaving the page. For example, something like this…

A Generic Video Player

…with a playlist that allows you to select other videos, like this…

Video Player with Playlist

This is all well and good. Because I try to build in a way that’s generalized for client accessibility and ease-of-use (and because I don’t want to be solely responsible for updating these things myself), the standard way to go about creating something like this would be to have an external XML document that contains all of the information required to build the playlist. The application is responsible for loading that document and extracting that information from it, which it uses to build a clickable, interactive playlist. This is all quite simple. The XML could look something like this:

<playlist>
	<item>
		<uid>1</uid>
		<title>Video 1</title>
		<video>PATH TO VIDEO</video>
		<thumbnail>Image for video</thumbnail>
	</item>
	<item>
		<uid>2</uid>
		<title>Video 2</title>
		<video>PATH TO VIDEO</video>
		<thumbnail>Image for video</thumbnail>
	</item>
	<!-- and on, and on, and on -->
</playlist>

The folder structure for such an application could (and would) conceivably look like this:

FLA Folder

FLV Folder

SWF Folder

XML Folder

Here’s where things get screwy.

In my application, when I’m ready to load my external XML in order to build a playlist, my code will look like this:

var req:URLRequest = new URLRequest("xml/playlist.xml");
var loader:URLLoader = new URLLoader();
loader.addEventListener(Event.COMPLETE, _playlistHandle, false, 0, true);
loader.load(req);

After I’ve loaded my playlist, suppose I want to play the first video. For the sake of brevity, we will suppose that I have an instance of a video player class that will allow me to simply pass the path to the FLV in to begin playing it, and that it’s already been instantiated and configured under the name “_player.”

function _playlistHandle(e:Event):void {
	var loader:URLLoader = e.target as URLLoader;
	var xml:XML = XML(loader.data);
	_player.play(xml.item.video[0].toString());
}

What do you suppose the path to my video is going to be, within my xml doc? If you look above, you’ll see I loaded the xml from the document root, and it would be natural for you to assume that the path to the first video is “flv/video.flv.” In this instance, you would be incorrect.

The correct path to the video file would be “../flv/video.flv.” Why is this? The relative path to an asset, in flash, varies according to what type of asset it is you’re accessing. In the case of XML you load your file from the location in which the SWF file is running, which in our example is the document root. When you’re loading video, however, you have to load your file from the physical location of the swf, not from where it’s running. In our example, that means our video file must be loaded as if the application is running from within our “swf” subfolder.

Why is this the case? I honestly have no idea. I can only imagine that in some obtuse way it’s meant to protect video content from being exploited by external domains or malicious third parties, though I can’t see exactly how.

Hopefully if you find yourself developing such an application, and you can’t figure out why the paths to your videos won’t resolve correctly, you’ll remember reading about the issue here. If anyone has a good explanation for why this is the case, I’d also be very curious to be informed.

So, beta versions of Flash Player 10.1 are already available, and a formal release is on the way. Which three features am I most excited about?

1. Global Error Handling

I’m planning on doing an article soon on error handling in Flash, but by the time 10.1 launches I’ll have to write another to highlight this great new feature. I’m consistently shocked by the number of unhandled flash runtime errors I encounter while browsing the web. Hopefully the addition of this feature will make it easier to handle some of them.

2. Out of Memory Management

Currently, it isn’t very easy or convenient to manage memory usage in Flash. This feature, while not making it explicitly easier, will at least allow swf content to fail more gracefully without obliterating the user’s state.

3. HTTP Streaming

Could it be true? Will I actually be able to legitimately stream video without having to pay companies like Brightcove and Edgecast to host it, and without having to install a streaming media server? If this is everything I hope it is, it will empower developers working on a smaller scale (me, for example) to deliver improved video experiences without breaking the bank.

This list is, of course, just a small selection of what I’m excited about. A full detail of the features that are on the way can be found here.