Understanding shared objects
Shared Objects can store any data types supported by flash. As far as the storage location is concerned, shared objects can be divided into local models of client computers and remote models stored on servers. You can use it to record user information (such as user name, gender, and other set parameters), or use it on the server, stores information shared by other online users in real time (such as chat room content and online user name orders)
Shared object means that users can apply application entities on different servers among different users. Flashcom server supports three types of shared objects: local, remote, and server-side. The following describes the three shared objects.
Local shared object)
It is used to access local data stored in users' computer hard disks and can be accessed by other applications at different times. The local shared object extension is. sol, the default storage path is C:/Documents and Settings/login name/Application Data/Macromedia/Flash Player/Server domain name/movie path/album file name .swf /. The local shared object can also be temporary, that is, only available when the application is running. We can also use a local shared object without connecting to the Flash COM server. For more information about local shared objects, refer to the export dobject. getlocal method in the manual.
The method for creating and accessing a local shared object is as follows:
VaR so = sharedobject. getlocal ('mycooker') // create a local shared object
So. Data. Username = 'liu21st ';
So. Data. MSG = 'century of the year ';
So. Data. Counter = 10;
// By default, the above information is not immediately written to the user's disk. It will not be written to the disk until the animation is disabled or the user leaves your website. To write data immediately, you must use the flush method. As follows:
So. Flush ();
// Store data
// Note: data attributes must be used to read or write data to a local shared object.
You can use the onstatus event to check whether the data is successfully stored.
The Returned Code value is
Export dobject. Flush. Success (write successful)
Export dobject. Flush. Failed (write failed)
Sample Code:
So. onstatus = function (Info ){
Status = info. Code;
Status = 'your dobject. Flush. SUCCESS '){
Trace ('write succeeded ');}
Trace ('write failed ');
var
if (
else
Remote shared object)
Using the Flash video's actionscript program, you can create materials on the server that can be accessed by different online users. These materials are called remote shared objects. Like a local shared object, a remote shared object can be accessed by a local computer. The difference is that data is stored on the server, so any user can connect to the remote shared object to access the same information. The default storage path is the export dobjects folder under the Application Object Path. The extension is. FSO.
Remote shared object is also the most common shared object type. When an online user (or server program) updates the content of a remote shared object, other users online to the same application entity will automatically receive the update event (onsync ), keep data synchronized with each other. Chat Room applications are built using this mechanism.
For example, you can open a remote shared object, such as a telephone number table (valid permanently on the server ). When the user side makes any changes to the shared object, the modified data is automatically synchronized to other users connected to the remote shared object. If, for some reason, the local data information is updated but not connected to the server, the changes will be synchronized to the remote shared object the next time you connect to the server.
For more information, see the export dobject. getremote method in the manual.
To create a remote shared object:
VaR client_nc = new netconnection ();
Client_nc.connect ('rtmp: // localhost/videochat/room1 ');
So = export dobject. getremote ('records ', client_nc.url); // data is not written to the disk.
So. Connect (client_nc );
The Data Reading and Writing Methods for remote shared objects are similar to those for local shared objects. They also use data attributes and flush methods.
Use the following statement to write data to the shared object directory of the server-side application folder.
So = export dobject. getremote ('records ', client_nc.url, true );
// The remotely shared file name of this statement will be records. FSO
When the content of the remote shared object changes or is online for the first time, it will send an onsync event to the client, so that all online users can obtain the latest shared object data in real time.
Sample Code:
so.onSync = function(list) {
k in list) {
trace('name = ' + list[k].name + ', event = ' + list[k].code);
// do whatever else you want to do here
}
for (var
}
Proxied shared object)
The proxy shared object is a remote shared object that can be shared between the client and the server. The difference is that it is created by the server-side actionscript program, for example, there are two chat rooms on the server: chat01 and chat02. In chat02, you can connect to the shared object defined in chat01. For more information, refer to sharedobject in the manual. get method.
Unlike mongodobject on the client, the value of shared variables must be set through mongodobject. setproperty to obtain the value of shared variables through mongodobject. getproperty.
Instance code:
application.appStart = function() {
nc = new NetConnection();
nc.connect('rtmp://' + master_server + '/' + master_instance);
proxySO = SharedObject.get('myProxy',true,nc);
// Now, whenever the client asks for a persistent
};
// shared object called myProxy they will receive myProxy
// shared object from the master_server/master_instance
myInfo = SharedObject.get('foo');
addr = myInfo.getProperty('address');
myInfo.setProperty('city', 'San Francisco');
names = sharedInfo.getPropertyNames();
x in names){
propVal = sharedInfo.getProperty(names[x]);
trace('Value of property ' + names[x] + ' = ' + propVal);
var
var
for (
var
}
Before using the remote shared object, confirm your dobject. connect returns true. mongodobject is called on the client. the flush method only copies a copy locally. To ensure a copy on the server, you must use mongodobject on the server. flush method, such:
- // Sample server-side code for flushing a persistent shared object
application.onAppStart = function()
application.mySO = SharedObject.get('SharedObjName', true);
// When a user disconnects, flush the shared object.
application.onDisconnect = function(client)
application.mySO.flush();
- // to the server
- // Get the shared object when the application is loaded.
-
- {
-
- }
-
-
- {
-
- }
If multiple clients or servers synchronize remote shared objects at the same time, the problem may occur. To solve this conflict, follow these steps.
1. store information of different users in different locations
This is the simplest method. For example, you can store data in different locations for each user in a chat room, and only modify the data part of the user during synchronization.
2. Allocate a data owner
A more complex method is to define a user as the owner of the data within a limited period of time. The owner can lock the shared object on the server and synchronize other data until the available information is returned. The following is the sample code:
An application that records the highest score of the game is used to solve the synchronization conflict problem. Currently, the highest score saved by the system is 95. At the same time, two users broke this record and scored 105 and 110 respectively, if the highest score is not locked, the updatehighscore method will be executed for both scores. One of the scores may not be recorded. This problem is solved by locking the shared object.
- application.onAppStart = function()
application.scoreSO = SharedObject.get('high_score_so', true);
application.scoreSO.onSync = function(listVal)
trace('got an onSync on scoreSO');
application.onConnect = function(newClient,name,passwd)
newClient.updateHighScore = function(final_score)
application.scoreSO.lock();
application.scoreSO.getProperty('high_score_so') < final_score)
application.scoreSO.setProperty('high_score_so', final_score);
application.scoreSO.unlock();
- {
-
-
- {
-
- }
- }
-
- {
-
- {
-
- if (
- {
-
- }
-
- }
- }
3. Notify the client
When the server receives a synchronization request from the client, the mongodobject. onsync event notifies the client that the change is rejected, and then provides a user interface to resolve the conflict. This technology is usually used when clients are not updated frequently.
4. Accept some and reject others
The application resolves synchronization conflicts based on the "first come first served" principle. It usually takes the customer to re-request to resolve the conflict.
5. Use the send method to increase the control level
The notify dobject. send command broadcasts messages to all clients connected to the remote shared object, including the sender himself.