FMS & AS3: NetConnection.client and NetStream.client
Ok...I blogged about this a bit ago and wanted to do a quick follow-up post. In the aforementioned post (always wanted to use that $10 word; lol) I pointed out how certain functions (onBWDone, onFCSubscribe, etc) are required in the current client so the server can call them, as needed.
So, the way to do it was to set the myNetConnection.client = this;. Well, that's still very relavant but it has been SERIOUSLY irritating me on a cleanliness level. Here is why:
public function onBWDone(... rest):void{ ... }
Can you tell why it is irritating? PUBLIC!! Now my media connection class has, what seems like, a new function added to the API. :-( That bites! I'm the only one writing code against it so it isn't a big issue.
After a few weeks of doing my best to ignore my now public event handler I run across something in LiveDocs.
myNetConnection.client = new Object();
DUH! :-) I thought about it initially but I have each of those handlers dispatching events/making other calls so I didn't want to mess with that. Seeing as you can say new Object() that means you could say new MyCustomClient() and have it do whatever you want.
Bottom line: You don't have to set the client property to this but you can set it to a "custom object" or a custom class. Just a quick tidbit.
Categories
Flash Platform0 TrackBacks
Listed below are links to blogs that reference this entry: FMS & AS3: NetConnection.client and NetStream.client.
TrackBack URL for this entry: http://mt.johncblandii.com/mt-tb.cgi/79
2 Comments
Leave a comment
John C. Bland II
To add to your tip. When defining the client, make sure you define event handlers FOR ALL THE #&$&@! events in the client. You didn't need to in AS2, but AS3 reacts differently when it raises an event in the client and the client isn't listening.
I spent 3 days trying to figure out why one subscription to a live stream would terminate unexpectedly. I had the typical onPlayStatus defined. Wasn't seeing any errors anywhere and after 3 days, I had every imaginable handler trace(ing) output. But forgot about the client.
Finally filled in all the events handlers in the client, and all my problems disappeared.
Interesting enough...I don't see errors or statuses in the handlers but their lack of definition seemed to be enough.
You could do that or make your client a dynamic class or a simple object (which is dynamic by nature).