NetConnection, SharedObject, & NetStream’s client Property in ActionScript 3

Past two weeks, I’ve been porting over some Flashcom & Flex 1.5 code to Flex 2 (still using FCS 1.5 vs. FMS 2). One nice addition I found in the ActionScript 3 SharedObject class is the client property. This little gem allows you have events that are called by SharedObject.send to be called on a proxy class instead. What this means is, if someone in a Flashcom application causes the remote SharedObject to be updated, and it fires a “onChatMessageUpdate” method, it’ll actually get called on the client object if you set it to something. Since a lot of intrinsic classes are now “final”, meaning you can’t futz with ‘em as easily as you could in AS2, this is a great way to incorporate it via Composition.

var my_rso:SharedObject = SharedObject.getRemote("chat", nc.uri, false);
my_rso.owner = this;
my_rso.onChat = function(str)

function onChatMessage(str)
        textArea.text += str;

In the past, you’d use something like the above; proxying the message yourself, or even putting the logic inside the method closure if you were in a hurry.

Now, you can forward it to an anonymous object, yourself, or even a class instance.

var my_rso:SharedObject = SharedObject.getRemote("chat", nc.uri, false);
my_rso.client = this; // onChatMessage needs to be a public function in this class
my_rso.client = {onChatMessage: function(str){ // }}; // anonymous function
                my_rso.client = new ProxyClass(); // you can make a class specifically to handle events

David Simmons from Adobe told me it was on NetConnection as well. Just checked, and she’s on NetStream too. In my tests, for classes, it only works on methods in the public namespace; protected & private don’t work. I didn’t test custom namespaces, nor do I know how to make it “see” them.

Handy! Thanks Adobe.

Screen Capture Driver for Flashcom

Fabio Sonnati just found this screen capture driver that is free for personal use. I tested it in Flash 8 using:


I then right clicked on the SWF, went to Settings, chose the Camera tag, and chose the “VHScrCap” driver from the list of Camera drivers, and walla, I could see my Flash movie in Flash.

Opening the SWF from my desktop, I could then see my desktop. I’m having challenges getting specific settings from the driver, but that’s becaues I’m rusty with Flashcom, and it doesn’t come with them in the program itself.

Naicu Octavian pointed us to iuVCR from iuLabs, which has a video driver settings panel.

Now you can capture your desktop utilizing Flashcom without being a h@X|\|0|3! (i.e. Video card out via S-VHS cable to capture card in on another computer that has a SWF that selects the Capture Card driver in the settings list, and broadcasts that to a localhost Flashcom server… whew!)

VidiPost Test: Crazy Cow

Testing the VidiPost service Graeme worked on (record video, publish to blog). Their signup process is a little tricky, some of the buttons on the service’s site itself are not very apparent nor obvious what they do, nor is the actual camera/mic settings brainless to setup… but man, how easy is that to just hit record, publish, copy paste some code and put on your blog? Wow… good job Graeme & team!

Class Deserialization: OpenAMF & Flashcom

Had a hell of a time debugging some OpenAMF calls yesterday. Turns out, when Flash deserializes your class, it basically takes a vanilla object, puts properties on it and assigns their values, and then points that instance’s __proto__ property to the prototype of the class you registered via Object.registerClass. The downside to this is it doesn’t run your setter functions on any getter/setters you have set on the class. Naturally, your getters fail immediately because they look to a private equivalent variable which is different, and when you call the setter… it’s really a function.

How Flash manages to keep “firstName” the public property and “firstName” the public getter function in the same namespace is beyond me, but regardless, I’ve tested in Flashcom last night, and the same thing happens there, too, so it appears to be how Flash deserializes your class.

The way we, “solved it” as my manager says, or “worked around it” as I claim, is emulating, EXACTLY the Java class equivalents. So, you have private properties in the Java model class, like:

private String firstName;

And same on the Flash side:

private var firstName:String;

And instead of getter/setter functions in Flash, you just use the get/set function methology:

public function getFirstName():String
return firstName;

public function setFirstName(val:String):Void
firstName = val;

I really don’t like this at all, and personally feel that there should either be an event letting you know when the class is deserialized (Flashcom does this for server-side ActionScript classes via the onInitialize event) so you can then run the getter/setters yourself, OR Flash should just intrinsically know there are getter/setters in place, and set the private variables accordingly. This gets sticky though because you’re now having the Flash Player run code on your classes. Thus, I vote for the first.