Communication and Security with the Flash Communication Server - Sharing Data in Real Time
(Page 2 of 4 )
Real-time applications often require data to be shared among or transmitted between multiple movies. The Shared Object class is familiar to many Flash programmers as a way to create a kind of supercookie; a local shared object (LSO) can store ActionScript data on the client between sessions. Flash communication applications can use remote shared objects (RSOs) to share information in real time between movies
running on different clients. If a movie updates a property of a remote shared object, the same property is updated in every other movie connected to it. When a shared object changes, each client is notified of the changes. Shared objects can be used to:
- Hold the position, shape, and color information of each graphical element in a shared whiteboard
- Hold the data for each form element in a shared form
In object-oriented programming (OOP), the data within all the objects in an application defines the current state of the application.
Shared objects provide a convenient mechanism to hold the state of a communication application distributed across multiple clients and servers.
Remote shared objects can be temporary or persistent. Temporary shared objects last only while they are being used. Persistent shared objects are saved on the server when they are not in use, allowing clients to pick up where they left off as soon as they reconnect to the server. Proxied shared objects are a mechanism for making shared objects available across multiple application instances; one application instance always owns the shared object but others can create a network connection to the master instance and create proxies (essentially an alias) of the shared object. That way, clients connected to any instance can connect to the same shared object. The feature is often important for creating large scale applications.
The code to work with shared objects on the client is a little different from that required on the server. Working with shared objects is also a little more complicated than working with streams or managing network connections. You need to do four basic things when working with shared objects:
- Get a remote shared object using SharedObject.getRemote( ).
- Customize the shared object so your program can respond to changes made to the shared object by each movie or by the server.
- Connect to the shared object.
- Once connected, update the shared object’s properties as necessary.
Chapter 8 provides complete coverage of using shared objects, but let’s have a quick look at what some client-side code looks like. On the client, the SharedObject. getRemote( ) method returns a remote shared object. However, the shared object usually needs to be set up with an onSync( ) method and then connected using a Net-Connection object before it can be used. Here we get a shared object namedusersto which each movie will connect. Then, an onSync( ) method is defined that, for demonstration purposes, displays information about changes made to the shared object as soon as they occur. Then the shared object is connected to the server:
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;
trace("User connected with id: " + id);
trace("and name: " + users_so.data[id]);
break;
case "delete":
var id = info.name;
trace("User disconnected with id: " + id);
break;
}
}
};
users_so.connect(nc);
The onSync( ) method is often the most interesting part of shared object coding. When the local copy of the shared object is synchronized with the server and whenever any slots (properties) in the shared object change, the onSync( ) method is invoked automatically. The onSync( ) method is passed an array of information objects. Each object contains information about the shared object or about what has happened to a slot (property) in the shared object. Chapter 8 describes shared objects and the onSync( ) method in detail. Each information object has acodeproperty, which describes what happened (“clear” if every slot is deleted, “change” if a slot is added or updated remotely, or “delete” if a slot is deleted). The name of the slot that has been updated or deleted is always found in the information object’snameproperty. To add or update data to a shared object slot within Flash, use thedataproperty of the shared object:
users_so.data["guest_4"] = "brian";
Likewise, you can retrieve the value in a slot using thedataproperty:
trace("The user's name is: " + users_so.data["guest_4"]);
Client and Application Objects
Whenever a client connects to an application instance on the server, a Client object is created on the server side to represent the remote client. The Client object can be used by server-side scripts to send and receive data messages to and from each individual remote Flash client. Every application instance also has a single application object that provides a convenient way to manage the instance’s life cycle. The applicationis a singleton instance of the server-side Application class.
Scripting Client objects and theapplication object is covered in Chapter 4. The Client andapplication objects, in concert with the ability to query web application servers, provide the core features needed to authenticate clients as they connect. Authentication is covered in detail in Chapter 18.
Next: The Communication Classes >>
More Flash Articles
More By O'Reilly Media
|
 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.
|
|
