Video and the Flash Communication Server - Making the connection
(Page 4 of 4 )
In Example 1-3, connectButton is set to deliver click events to the click( ) function whenever it is clicked. The button displays one of three labels—Connect, Wait..., or Disconnect—depending on the state of the connection. If the button label is Connect, the click( ) function tries to make a connection using nc.connect( ). If the button label is Disconnect, clicking the button closes the current connection by calling nc.close( ).
Example 1-3. Making or breaking a connection when the Connect button is clicked
connectButton.addEventListener("click", this);
function click (ev) {
var button = ev.target;
var command = button.label;
switch (command) {
case "Connect":
nc.connect("rtmp:/helloVideo", userNameInput.text);
button.label = "Wait...";
button.enabled = false;
break;
case "Disconnect":
nc.close();
button.label = "Connect";
break;
}
}
Attempting to connect displays the Wait... button until the nc.onStatus( ) method from Example 1-2 is called and the results of the attempt are known.
Showing remote users
So far we’ve seen how a connection is established and how shortly afterward the client knows its own ID, which it uses to publish a stream by the same name. Let’s have a look at how the client knows what streams to subscribe to and how to display their video along with the name of each user.
When the server calls the client’s setID( ) method, setID( ) calls the initUsers( ) method shown in Example 1-4 to set up a shared object and connect it to theusersshared object. Example 1-4 does three things: it gets a shared object, dynamically defines an onSync( ) method for it, and then connects it using thencnet connection. When the shared object is first synchronized with the server, any data in the server’s version of the shared object is copied to the client’s version of the shared object, and then onSync( ) will be called to notify the client of the changes. After that, any changes made in the server’s version result in the client’s version being updated and onSync( ) being called again. The onSync( ) method in Example 1-4 does all the work of reacting to changes in the shared object. When invoked, it receives an array of information objects. Each object has acode property, which indicates what kind of change the object represents. There are numerous possible codes as discussed in Chapter 8, but we are interested in only two of them: “change” and “delete”. We can ignore the rest because all of the updates and deletions of the shared object are done by the server-side code in main.asc. A “change” code indicates that the server has added or updated a slot in the shared object.
Besides the built-incodeproperty, the contents of the information object depend on the type of change reported by the shared object. In this example, the information object’snameproperty contains the name of the slot that has changed. For example, if a user has logged in and been given the ID “guest_2”, then an information object with acode value of “change” will also have aname property of “guest_2”. If a user disconnects, the server will delete a slot of the shared object so thecodevalue will be “delete” and thename property will identify the deleted slot. The onSync( ) code in Example 1-4 loops through the array of information objects passed into onSync( ) and examines each object’scodeproperty. If thecodeproperty is “change”, the initUsers( ) method plays the user’s stream and shows her name in one of theGuestVideo movie clips. If thecodeproperty is “delete,” the example stops playing the stream associated with the user who has disconnected.
Example 1-4. Setting up the users SharedObject
function initUsers () {
users_so = SharedObject.getRemote("users", nc.uri);
users_so.onSync = function (infoList) {
for (var i in infoList){
var info = infoList[i];
switch (info.code) {
case "change":
var id = info.name;
var mc = _root[id];
mc.nameInput.text = users_so.data[id];
if (myID != id) {
var ns = new NetStream(nc);
mc.video.attachVideo(ns);
ns.play(id);
mc.ns = ns;
}
break;
case "delete":
var id = info.name;
var mc = _root[id];
mc.ns.close();
mc.nameInput.text = "";
mc.video.clear();
break;
}
}
};
users_so.connect(nc);
}
I’d like to look more closely at the code that starts playing a remote user’s stream and shows her name:
case "change":
var id = info.name;
var mc = _root[id];
mc.nameInput.text = users_so.data[id];
if (myID != id) {
var ns = new NetStream(nc);
mc.video.attachVideo(ns);
ns.play(id);
mc.ns = ns;
}
break;
Thenameproperty is the remote user’s ID. For example, if it is “guest_2”,_root[id]equates to the GuestVideo movie clip of the same name. Once we know what clip represents the user, we can show the name the user selected when she logged in by setting the text of thenameInputTextInput component inside the movie clip:
mc.nameInput.text = users_so.data[id];
Unlike the server-side code that used users_so.setProperty( ) and users_so.getProperty( ) to set and get values in a shared object slot, in the client a specialdataobject is available to read and write slot values. For example, to get or set theguest_2slot of the shared object, use the expression:users_so.data["guest_2"].
Because the server-side code changes a slot each time a user connects, the client will receive notification that a slot has changed when other remote users connect as well as when it connects. However, we want to play only the streams of remote users because there is no point in wasting bandwidth to play the local user’s own stream. Fortunately, the setID( ) method was called before the shared object was set up and connected, so we already know the local user’s ID. Ifidis different from the value in themyID variable, idrepresents a remote user and we can safely play it. To play it, the code creates a new NetStream object and attaches it as a dynamic property of the movie clip:
var ns = new NetStream(nc);
mc.video.attachVideo(ns);
ns.play(id);
mc.ns = ns;
If a remote user disconnects, the NetStream object playing her stream can be safely closed, her video cleared, and thenameInputfield set to an empty string:
case "delete":
var id = info.name;
var mc = _root[id];
mc.ns.close();
mc.nameInput.text = "";
mc.video.clear();
break;
Hello Video! Summary
If you’ve read through the code and commentary on the helloVideo application, you’ve seen most of the communication classes working together to create a very simple video conference application. And, while there is a lot more we can do with Flash and FlashCom, you’ve already seen many of the essential techniques for building a communication application.
Conclusion
While writing this book, I met online with the other authors to discuss our project. I used some of the sample applications I wrote for the book and another Macromedia application built on top of Flash and FlashCom: Breeze Live. One of the earliest conferences I had was with Robert Reinhardt. I was at home in Toronto, on eastern standard time, and he was in Los Angeles on Pacific time. It was dark in Toronto and the sun was about to start setting in L.A. Aside from the immediacy of our conversation—something more akin to being in the same room than being on the phone or using text messaging—there was something compelling about seeing the light gradually change on the other side of the continent as we spoke. In later conferences with Giacomo Guilizzoni, I was impressed with how helpful it was to be able to share code and make notes that we could both see and edit while we discussed what parts of this book each of us should work on. Communication applications that include live video, audio, and data make collaboration at a distance more immediate and effective. Flash and FlashCom together provide a platform that can be used to build a wide range of compelling communication applications. Whether you need to build a shared simulation to enhance an online course or a simple video conference, text chat, or video-on-demand application, you’ll find a rich toolbox of classes and components to create it described in detail in the chapters that follow.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
|
 This article is excerpted from chapter one of the book Programming Flash Communication Server, written by Brian Lesser, Giacomo Guilizzoni, Robert Reinhardt, Joey Lott, and Justin Watkins (O'Reilly, 2005; ISBN: 0596005040). Check it out today at your favorite bookstore. Buy this book now.
|
|
