Handling
real-time data with shared objects
Shared objects are a new feature in Macromedia
Flash. They have been likened to "super cookies" because
they allow you to store data locally or remotely—and,
in the latter case, share information with other users.
Shared objects store information in slots,
each of which can be of a unique data type and contain
different information. When you use remote shared objects,
changing any information in a slot causes Flash Communication
Server to synchronize the entire slot.
Flash Communication server won't send data in other
slots, unless you have modified them.
When you first connect to a remote shared
object and when you or anyone else modifies data in it,
an onSync event is triggered, which returns a list of slots
that Flash Communication server has modified. When you first
connect to a shared object you get an onSync event with
a list of all the information in the shared object. The
onSync event also informs you when changes that you make
to a shared object are successful, or when an error or conflict
occurs.
There are two basic types of shared objects:
local and remote. For the most part you will use the remote
shared objects. However, you can also use local shared objects
to store information locally about an individual user's
preferences. An example of this is the SimpleConnect component,
which remembers the user's name for future logins. It is
only through using remote shared objects that you can share
information with others and store that data so you can use
it in the future on a server. Remote shared objects require
that you use Flash Communication Server; local shared objects
do not.
You can set a shared object to persist.
This means that the shared object can remain even when the
application is not using it. This is useful for saving the
shared object state. In the case of the whiteboard, imagine
if you left unexpectedly in the middle of creating a flow
chart. If the application did not persist the shared object,
then you would loose any information you had stored. Because
the whiteboard persists the shared object and stores all
the drawing information in it, you or anyone else can leave
and come back to a whiteboard application instance; upon
your return, the application will automatically store and
retrieve all of the drawing information. You can set shared
objects to persist locally so that even when you go offline,
a locally accessible version of the information is available
to you. You can then update and synchronize the information
the next time you connect to the server.
Saving and retrieving data
You save information in a shared object just as you would
in any other variable. The important thing to remember is
that all slots reside under ".data". If you create a shared
object called my_so, and you want to have a property called
"name", then you should store information as "my_so.data.name".
In the case of a remote shared object this will trigger
a sync event for all connected users, notifying them of
a change.
Data is retrieved from a shared object
much as it is written. Flash Communication Server
retrieves data from a shared object similarly to how it
writes data to the shared object.
To put the "name" property described above into a text field,
you use something like this:
name_txt.text = my_so.data.name
The onSync event is also a common place
to retrieve data from a shared object. In most cases, you
put your code inside an onSync event handler to deal with
any changes that occur. The list returned with the onSync
event lets you differentiate when you or someone else has
changed, added, deleted, or rejected data. |
