User Guide

SharedObject class 129
Once a value has been passed for the local persistence of a remote shared object, it is valid for
the life of the object. In other words, once you have gotten a remote shared object which is
not locally persistent, you cannot get the same shared object with local persistence while the
shared object is active.
For example, the second line of code in the following does not get a locally persistent remote
shared object:
/* Get a remote shared object (remote01_so) that is persistent
on the server but not on the client.*/
var remote01_so:SharedObject = SharedObject.getRemote("someObject",
my_nc.uri, true);
/* Get a remote shared object (remote02_so) with the same name and path
as remote01_so, but with local persistence. remote02_so will just point to
the same object as remote01_so, and an onStatus message will be invoked
for remote2_so with the "code" value of the information object set to
"SharedObject.BadPersistence".*/
var remote02_so:SharedObject = SharedObject.getRemote("someObject",
my_nc.uri, "somePath");
Also, remote shared objects that are not persistent on the server are created in a different
namespace from remote shared objects that are persistent on the server. Therefore, if the
following line of code is added to the preceding example, no
SharedObject.BadPersistence error will result because remote03_so does not point to the
same object as
remote01_so:
var remote03_so:SharedObject = SharedObject.getRemote("someObject",
my_nc.uri, false);
Understanding naming conventions for remote shared objects
To avoid name collisions,
Flash looks at the location of the SWF file that is creating the shared object. For example, if a
SWF file at www.myCompany.com/apps/stockwatcher.swf creates a shared object named
portfolio, that shared object will not conflict with another object named portfolio that
was created by a SWF file at www.yourCompany.com/photoshoot.swf, because the SWF files
originate from two different directories.
To further avoid name collisions, Flash Player appends the application name and instance
name to the end of the path of the shared object directory. Unless two SWF files are located in
the same directory, use a shared object with the same name, and are connected to the same
application with the same instance name, there will not be a name collision related to
persistent shared objects on either local or remote locations.
However, if two different SWF files located in the same directory create objects with identical
names and the same location for
persistence, the names will conflict, and one object can
overwrite the other without warning. Implemented properly, however, this feature lets SWF
files in the same directory read each other’s shared objects.