Client-Side Communication ActionScript > SharedObject (object)
Client-Side Communication ActionScript > SharedObject (object) |
|
SharedObject (object)
Availability
 |
Flash Player 6. |
|
Flash Communication Server MX (not required). |
Shared objects are quite powerful: they offer real-time data sharing between multiple client movies and objects that are persistent on the local or remote location. You can think of local shared objects as "cookies" and remote shared objects as real-time data transfer devices. Common ways to use shared objects are summarized below.
|
Maintaining local persistence |
This is the simplest way to use a shared object, and does not require Flash Communication Server. For example, you can call |
|
|
Storing and sharing data on a server |
A shared object can store data on the Flash Communication Server for other clients to retrieve. For example, you can open a remote shared object, such as a phone list, that is persistent on the server. Whenever a client makes any changes to the shared object, the revised data is available to all clients that are currently connected to the object or who later connect to it. If the object is also persistent locally and a client changes the data while not connected to the server, the changes are copied to the remote shared object the next time the client connects to the object. |
|
|
Sharing data in real time |
A shared object can share data among multiple clients in real time. For example, you can open a remote shared object that stores real-time data, such as a list of users connected to a chat room, that is visible to all clients connected to the object. When a user enters or leaves the chat room, the object is updated and all clients that are connected to the object see the revised list of chat room users. |
The following examples show a few ways shared objects are called within ActionScript programs. Note that in order to create a remote shared object, you must first connect to the Flash Communication Server with the RTMP protocol.
// Create a local shared object
so = SharedObject.getLocal("foo");
// Create a remote shared object that is not persistent on the server
nc = new NetConnection();
nc.connect("rtmp://server.domain.com/chat/room3";
so = SharedObject.getRemote("users", nc.uri);
so.connect(nc);
// Create a remote shared object that is persistent on the server
// but not on the client
nc = new NetConnection();
nc.connect("rtmp://server.domain.com/chat/room3";
so = SharedObject.getRemote("users", nc.uri, true);
so.connect(nc);
// Create a remote shared object that is persistent on the server
// and on the client
nc = new NetConnection();
nc.connect("rtmp://server.domain.com/chat/room3";
so = SharedObject.getRemote("users", nc.uri, "/chat");
so.connect(nc);
Designing remote shared objects
When designing remote shared objects, develop a model for how the data will be managed. Take into account issues of data design and management, conflict resolution, and storage (persistence) requirements, both locally and on the server. These issues are discussed briefly in this section.
When using a locally persistent remote shared object, make sure your Stage size is at least 215 by 138 pixels. The Flash Player needs at least this much space to display the Settings panels.
Data associated with shared objects is stored in attributes of the object's data properties; each set of attributes constitutes one slot. For example, the following lines assign values to three slots of a shared object:
so.data.userID = "myLogonName"; so.data.currentStatus = "in a meeting"; so.data.lastLogon = "February 27, 2002";
Each time a client changes an attribute, all the attributes for that slot are sent to the server and then propagated to all clients attached to the object. Thus, the more information a slot contains, the more network traffic is generated when any attribute in that slot is changed.
For example, consider a shared object with the following attributes occupying a single slot:
so.data.year.month.dayOfMonth = someValue;
If a client changes the value of the year, month, or dayOfMonth attribute, the entire slot is updated, even though only one data item was changed.
Compare this data structure to a shared object with the same attributes, but with a flat design that occupies three slots instead of one:
so.data.year = someValue; so.data.month = someValue; so.data.dayOfMonth = someValue;
In this case, because each slot contains only one piece of information, less bandwidth is required to update all connected clients when a single data attribute is changed.
You can use this information when designing your remote shared objects. For example, if an object is designed to be updated frequently by multiple clients in real time, minimizing the amount of data per slot can improve performance. This design can also help minimize data collisions (multiple clients trying to change a single slot at the same time).
If more than one client (or a server application) can change the data in a single slot of your shared object at the same time, you must implement a conflict resolution strategy. Here are some examples:
Use different slots The simplest strategy is to use a different slot for each player or server that might change data in the object. For example, in a shared object that keeps track of users in a chat room, provide one slot per user and have users modify only their own slots.
Assign an owner A more sophisticated strategy is to define a single client as the owner of a property in a shared object for a limited period of time. You might write server code to create a "lock" object, where a client can request ownership of a slot. If the server reports that the request was successful, the client knows that it will be the only client changing the data in the shared object.
Notify the client When the server rejects a client-requested change to a property of the shared object, the SharedObject.onSync event handler notifies the client that the change was rejected. Thus, an application can provide a user interface to let a user resolve the conflict. This technique works best if data is changed infrequently, as in a shared address book. If a synchronization conflict occurs, the user can decide whether to accept or reject the change.
Accept some changes and reject others Some applications can accept changes on a "first come, first served" basis. This works best when users can resolve conflicts by reapplying a change if someone else's change preceded theirs.
Local disk space considerations
You can choose to make remote shared objects persistent on the client, the server, or both. (Local shared objects are always persistent on the client, up to available memory and disk space.)
By default, Flash can save locally persistent remote shared objects up to 100K in size. When you try to save a larger object, the Flash Player displays a Local Storage dialog box, which lets the user allow or deny local storage for the domain that is requesting access. (Make sure your Stage size is at least 215 by 138 pixels; this is the minimum size Flash requires to display the dialog box.)
If the user chooses Allow, the object is saved and SharedObject.onStatus is invoked with a code property of SharedObject.Flush.Success; if the user chooses Deny, the object is not saved and SharedObject.onStatus is invoked with a code property of SharedObject.Flush.Failed.
The user can also specify permanent local storage settings for a particular domain by right-clicking (Windows) or Control-clicking (Macintosh) while a movie is playing, choosing Settings, and then opening the Local Storage panel.
You can't use ActionScript to specify local storage settings for a user, but you can display the Local Storage panel for the user by using System.showSettings(1).
The following list summarizes how the user's disk space choices interact with remote shared objects from a specified domain that request local persistence.
|
If the user selects Never, objects are never saved locally, and all |
|
If the user selects Unlimited (moves the slider all the way to the right), objects are saved locally up to available disk space. |
|
If the user selects None (moves the slider all the way to the left), all |
|
If the user selects 10 KB, 100 KB, 1 MB, or 10 MB, objects are saved locally and |
Additionally, if the user selects a value that is less than the amount of disk space currently being used for locally persistent data, Flash warns the user that any shared objects that have already been saved locally will be deleted.
Note: There is no size limit in the Flash Player that runs from the authoring environment; the limit applies only to the stand-alone player.
Method Description Closes the connection between a remote shared object and the Flash Communication Server. Connects to a remote shared object on the Flash Communication Server. Immediately writes a locally persistent shared object to a local file. Returns a reference to a locally persistent shared object that is available only to the current client. Returns a reference to a shared object that is available to multiple clients by means of the Flash Communication Server. Gets the current size of the shared object, in bytes. Broadcasts a message to all clients connected to the remote shared object, including the client that sent the message. Specifies the number of times per second that a client's changes to a shared object are sent to the server.
Method summary for the SharedObject object
Property (read-only) Description The collection of attributes assigned to the
Property summary for the SharedObject object
data property of the object; these attributes can be shared and/or stored.
Method Description Invoked every time an error, warning, or informational note is posted for a shared object. Initially invoked when the client and server shared object are synchronized after a successful call to
Event handler summary for the SharedObject object
SharedObject.connect, and later invoked whenever any client changes the attributes of the data property of the remote shared object.
Constructor for the SharedObject object
For information on creating objects that do not require Flash Communication Server, see SharedObject.getLocal. For all other objects, see SharedObject.getRemote.
|