When you look at the individual elements of the actions array, you will always find a single property named code, and for some codes an additional property called name. The data structure looks like the following:

event

actions

o 0 -
code
[name]
o 1 -
code
[name]
o 2 -
code
[name]

data

At the start of the syncData function, the code loops through the actions array and examines each element. You perform a switch statement on the code property, which defines the type of action you can perform. For this example, you are only interested in two specific codes: change and clear.

A clear code simply means that all of the current data should be cleared. The code executes a removeAll method on the data structure.

A change code indicates that a slot has changed on the server and provides the name of this slot through the name property. In this case, the slot names are 0-9.

The data array is the other extremely important part of this equation. The data is an associative array of the slots defined on FCS. So, in this example, data has slots named 0-9.

When you receive a change code, you also receive the name of the changed slot. This name allows you to look up the new slot information in the data array.

There are two more issues to understand, however. First, FCS informs the Flex client of changes to the data, however, it is up to the client program to analyze this data and determine whether it is new content to store or existing content to replace.

In this simplified example, you simply check to see if data of this slot name exists in the myData array. If it does, you replace that item with the new data. If it does not, you add it.

Second, and perhaps more complicated, is the interaction of the data from FCS with the Flex data binding mechanism.

Data Structure Review
An object is a collection of properties and it is one of the basic Flex data types. However, objects behave differently than numbers or strings.

For example, examine the following piece of code.

myNum1 = 5;
myNum2 = myNum1;
myNum1 = 6;

At the end of this code, myNum1 contains the number 6, and myNum2 contains the number 5; however, this same example does not hold true for objects. If you assign one object to another, as in the following example:

myObj2 = new Object();
myObj2.test = 3;
myObj2.case = 4;
myObj1 = myObj2;

Flex doesn't actually make a copy of the object, but rather myOb1 contains a reference to myObj2. So, there is one copy of all the data stored in the object and both names can be used to access this data. Therefore, myObj1.test and myObj2.test are really the same variable.

This can cause an issue when you receive a new object from FCS. For example, if you receive a change for Slot 1, the intuitive approach might be to assign the data coming from the FCS shared remote object directly to your myData array using an assignment (=) operator.

However, as noted above, if you simply set two objects equal to each other, Flex will be unable to make a copy, but merely provide a new reference or way for you to access the same data. This means that any time you attempt to make a change to an element in your myData array, in reality, you are attempting to change the shared remote object that FCS created.

The implication is that every user running your application will receive a change made by a single user. When used properly this can be beneficial, however, in many cases it can cause significant performance reduction and potentially prevent users with slower connections from accessing the application.

A quick way to resolve this issue is to create a brand new object every time a new piece of content arrives from Flash Communication Server and then use that newly created object in the myData array. Any changes made from within a single client's application will affect a user's copy of the data but will not change values in the shared remote object used by everyone.

The final step required to display incoming data from FCS is to provide the name of the function syncData to the sync event of the component. Now, whenever data changes on the server, a sync event will be broadcast from the RemoteShared component and the syncData function will be called to process the received data.

The Result
When you run this application, you have 10 rows in a DataGrid. Every two seconds, when the data changes on the Flash Communication Server, this data will be pushed to all connected clients, keeping them in sync.

While this is a rudimentary example, it shows how you can incorporate a Flash Communication Server remote shared object into your application in a way that is familiar to you, and keeps the metaphor established by the WebService tag. It demonstrates the very basic technique of dealing with returned data and illustrates the general concept of the server technology.

This article originally appeared on www.macromedia.com/devnet. Reprinted with permission.