April 2006 Archives

I've posted the slides for my ActionScript 3 presentation for FITC 2006. Did you catch the big announcement at the end?

I had a really enjoyable time presenting this session. It was definitely one of the more technical sessions at the conference, but everyone seemed genuinely interested and I had numerous people come talk to me afterwards (which is usually a good sign).

You can download my slides here. Some of the session highlights...:

• I dissected the ByteArray class.
• I created a drawing program that allowed you to either save a JPG or PNG by converting the pixel data into a ByteArray.
• I covered using URLLoader and URLStream to pull binary information into the player. I demonstrated parsing an Excel .xls file and displaying the results in a DataGrid (holy !@#). My good friend Jim Cheng contributed the Excel-parsing code.
• I talked about the binary Socket class as well as the types of applications that can be built on top of it. I demonstrated my VNC project and connected to my SuSE Linux server through Flash running in FireFox.
• I talked about the new Loader display object and showed how to create an on-screen image out of a ByteArray.
• Lastly, I talked a bit about emulators, and showed the Chip8 Emulator in action.

I also touched on combining Socket and Loader to deliver .swfs in a secure manner. When you view a .swf file, it ends up in your browser's cache and can usually be decompiled rather effortlessly with tools like ASV. I talked about the use case where you can use Loader to download an entire .swf file over a Socket connection (receiving the data as a ByteArray), then place the .swf on the stage via Loader.loadBytes. This route prevents the .swf from being cached by the browser and makes it much harder to decompile. It's not 100% secure yet, but imagine public/private key encryption to deliver the .swf contents over a secure Socket instead. The days of easily-decompiled .swf files may be coming to an end?

Finally, the biggest news and probably most exciting part of my presentation was the very last slide. I made a big announcement - something that I've been dieing to talk about for a very long time now, but was just waiting for the right time.

There is now an Open Source Commodore 64 Emulator written in ActionScript 3! (The Trac page might still be password protected, go bug Aral to remove the password if he hasn't yet.) Claus Wahlers and I have teamed up to create the emulator. It's still a work in progress, and we're looking for hardware-nerds to step up to the plate and help us finish it. The CPU code is complete, but hasn't been extensively tested. The memory code is a work in progress, and we haven't had a chance to start on the display code yet. Still though, it's a good start.

At this point, we're just running the CPU as fast as possible without trying to get the timing completely accurate. On the debug Flash Player, it runs at ~2.5 MHz. On the release Flash Player, it runs at closer to 6 or 7 MHz. This is a good thing, as the original Commodore chip only runs at 1 MHz. So, in theory, it should be possible to emulate the games in real-time without any slow down or speed delays (holy @#!@).

To friends, old and new, here's to next year. FITC rocked the llama pretty hardcore this year. It was great catching up and meeting some new faces, and I hope to see you all again soon!

One last thing - I totally thought way too much about my "supermarket item" that appeared next to my session information. I picked "Love Bites" since my session was about "bytes" and by the end I was hoping you would "love" them. Get it? Hah! Total geek humor... *waits for the tomatoes to fly*

I'm headed out the door, departing for FITC 2006. This year I'll be giving 2 sessions. The first is a Q & A session on the Next Generation Flash Platform at 9:00 am tomorrow morning, and the second is an ActionScript 3 presentation on Sunday at 10:15.

If you see me walking around, stop and say hi. I'm looking forward to catching up with some old friends that I haven't seen in awhile (like Ted and Chafic), and making some new ones along the way.

Here's to safe travels for everyone attending, and another killer conference this year!

Tags: Flash, FITC, ActionScript

Last week someone on Flexcoders was having trouble with a popup window triggering commands in the Cairngorm framework for Flex 2. At the risk of repeating myself, I'm reproducing the answer here because it was on my "things to blog" list, and also because it should make finding the answer with search engines a bit easier.

Here is an illustration of the problem:

// This code goes inside of a class that gets opened via PopUpManager.createPopUp, 
// such as a subclass of TitleWindow
var event:MyEvent = new MyEvent ( data ); // MyEvent extends CairngormEvent
dispatchEvent( event );

Normally, the above code would cause the FrontController to handle the event in the normal Cairngorm manner (by invoking the Command associated with the event). However, when the event is dispatched from a popup window, nothing happens. Changing the code to the following fixes the problem:

// This code goes inside of a class that gets opened via PopUpManager.createPopUp, 
// such as a subclass of TitleWindow
var event:MyEvent = new MyEvent ( data ); // MyEvent extends CairngormEvent
Application.application.dispatchEvent( event );

By dispatching the event from the application reference, the FrontController behaves how you would expect.

So what causes the unexpected behavior in the original code? The answer lies in the class hierarchy at runtime, and the nature of event bubbling.

The reason the FrontController doesn't pick up the event in the first case is because even though the event will bubble up the display list, the application itself is not in the same display branch as the popup window. The event therefore never reaches the application, and the FrontController thus can not handle it. Visually, the runtime structure of your application might look something like this:

Unlike what you may expect, the application itself is not the root of the display list. When popup windows are created, they are not created on the same branch of the application, but rather they are created under the root display class, SystemManager. This makes the popup effect simple -- apply a blur filter over the entire application branch and keep the mouse and keyboard focus on the branch with the popup window. The popup window appears "on top" because of the nature of the new display list model, and it turns out to be relatively easy to make the window appear modal.

So, when you dispatch an event from one of the regular Child Forms, the event will bubble up to the application and the FrontController will handle it as it normally would. When you dispatch an event from a popup, the event still bubbles up, but it never passes by the application instance and therefore the FrontController can never map it to a command. By forcing the event to be dispatched from the application instance itself (in the second code block, above), the event is sure to pass through the application and thus the FrontController will be able to handle it.

For now, this behavior is a "Fact of Life" (FOL). It's just the way the PopUpManager works, and it's something to keep in mind when using Cairngorm 2. Future versions of the framework may come up with a more graceful way to handle this scenario, but for now, dispatching the event from the application is the way to go.

Tags: ActionScript, Flex, Flex 2, Cairngorm

Here is a simple example demonstrating how to use namespaces to access element nodes using E4X syntax. Create a new Flex Project and paste the code in the main .mxml file:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
	layout="vertical"
	creationComplete="onCreationComplete();">
	
	<mx:HTTPService id="latest" url="http://ax.phobos.apple.com.edgesuite.net/WebObjects/MZStore.woa/wpa/MRSS/newreleases/limit=10/rss.xml"
		showBusyCursor="true" resultFormat="e4x" result="onResult( event );" />
		
	<mx:Script>
		<![CDATA[
			
			import mx.rpc.events.ResultEvent;
						
			[Bindable]
			public var rockArtists:XMLList;
			
			// Define the namespace used in the rss feed for "itms".  Note that the
			// namespace we define is "items" instead.  These values do not need
			// to be the same, but generally should be for readability purposes.
			namespace items = "http://phobos.apple.com/rss/1.0/modules/itms/";
			
			private function onCreationComplete():void {
				// Load the RSS feed
				latest.send();	
			}
			
			private function onResult( event:ResultEvent ):void {
				var rss:XML = event.result as XML;

				// Filter the feed by the Rock category
				var rock:XMLList = rss.channel.item.(category == "Rock");
				
				// Use "items" namespace prefix (corresponding to the namespace we
				// defined above) to access the artist elements
				//rockArtists = rock.items::artist;
				// Or, alternatively:
				use namespace items;
				rockArtists = rock.artist;
			}
			
		]]>
	</mx:Script>
	
	<mx:Label text="Rock Artists:" />
	<mx:List dataProvider="{rockArtists}" />
	
</mx:Application>

The above code will grab the 10 New Releases from iTunes, filter the results by the Rock category, and display all of the artist names inside of a List.

The key here is that the artist element nodes are created with <itms:artist> in the RSS feed. In the XML, the "itms" namespace is defined as xmlns:itms="http://phobos.apple.com/rss/1.0/modules/itms/". This namespace is re-created in ActionScript using the namespace keyword in ActionScript, but instead of calling it "itms" it is defined as "items". In general, you'd want to keep the prefix the same for both, but for illustration purposes you can see that they're allowed to be different.

Accessing the artist element nodes then is simply a matter of using the namespace via use namespace items and asking for just the artist (without the namespace prefix). Another approach is to omit the use namespace ... code and use the namespace prefix directly: rock.items::artist. In both cases, the namespace to use is the one defined in ActionScript, and not the one defined in the XML file (so "items" instead of "itms").

Special thanks to Peter Hall, mostly just for his dry wit and sarcastic humor (or humour?).

Tags: ActionScript, Flex, Flex 2, E4X, XML