Flash Media Server is good for a lot more than just streaming video and audio. With Remote Shared Objects you can store persistent data on the server to do things like create chat applications or a user poll.

I’ve created lots of polls in the past using AMFPHP – there’s one sitting to the far right column ->. It’s easy to do and very reusable. Storing data in a database has many advantages over using Remote Shared Objects but the RSO approach has one very distinct advantage: it automatically updates while you’re looking at the data. Check out the poll below. Submit your vote and then open this page in another Tab/Window ( I’d suggest opening in another Window so that you can see both at the same time. ) Submit you vote again and see it update the chart from your original vote. Cool, eh?

And the best thing of all is that it doesn’t take any extra code to achieve that. It pretty much comes with. It’s just a combination of the Sync event on the RSO and DataBinding.

Getting Dirty
This example is very similar to my first two RSO examples except that I’m storing an ArrayCollection of Data Transfer Objects in the RSO. In practice it is no different than storing a String, Number, etc. except that FMS doesn’t actually notice that the value of the RSO has changed when you use setProperty().

All you have to do after calling setProperty() is call the setDirty() method on the RSO and that will do the trick for you. I have an entire post dedicated to setDirty with a simple example.

The best of both worlds
It would be very easy – if you have FMS and AMFPHP going for you – to set up a killer poll that used a database to store the data but used Remote SharedObjects to connect concurrent users so that when one user updated it would fire the Sync event for everyone viewing the poll and then we could go to the database to refresh the data. More about that later.

Creating a user poll using Flash Media Server and Remote SharedObjects originally appeared on polyGeek.com on October 23, 2008.

Here’s another of those lessons that I learned after hours of trying to figure out why my code wasn’t working. In this case my code just wasn’t dirty enough. :-)

What had happened was that I was trying to save an ArrayCollection of objects to a Remote SharedObject. And it just wouldn’t take. It worked fine if I tried to set the value of a String, or Number, but that wasn’t what I needed.

What was even more baffling was that when I debugged I could see that the RSO had stored the initial set of data. But I couldn’t make any changes and update the values.

Eventually I noticed this method for RSOs called setDirty – from the docs:

setDirty()
Indicates to the server that the value of a property in the shared object has changed. This method marks properties as dirty, which means changed.

Call the SharedObject.setProperty() to create properties for a shared object.

The SharedObject.setProperty() method implements setDirty(). In most cases, such as when the value of a property is a primitive type like String or Number, you can call setProperty() instead of calling setDirty(). However, when the value of a property is an object that contains its own properties, call setDirty() to indicate when a value within the object has changed.

Essentially the Remote SharedObject can’t tell when a complex object has changed it’s value. So change the value and then calling setDirty is like saying, “Trust me, it’s changed.”

Even with a primative type, like String or Number, if you set the value of an RSO to the value it already has then the Sync event won’t fire. Now that’s probably a good thing in most cases but there might be some cases in which you want to fire the Sync event regardless. In that case use setDirty.

In the example here you’ll notice that if you repeatedly click either of the top buttons it will only call the Sync event on the first click. Afterwards, even though you are calling the setProperty() method over and over the Sync doesn’t refire.

But the bottom buttons call the setProperty() and setDirty(). That forces the Sync to fire even if the value of the RSO hasn’t changed.

Getting Dirty with Remote SharedObjects originally appeared on polyGeek.com on October 22, 2008.

In this simple example here I’m storing two persistent Remote SharedObjects. The first Remote SharedObject is to keep track of the number of visitors that load the Flex app. Each time the app starts up and creates a connection to Flash Media Server it gets the data, which is just a number, and then adds one to it before updating the RSO. Pretty simple but there are a few nuances to consider.

One of them is that in order to keep the data current, so that if another user visits while you have it open you would like for it to increment your visitors count as well. So we have to keep listening to the SYNC event of the RSO. But when we update the RSO the first time it will cause fire the SYNC event again, causing it to update again, and again.

The easiest way I could think of to stop that is to keep track of which time the SYNC event is running. By setting a Boolean – _isTotalSet – equal to false and then after we update the _totalCountRSO setting it to true then we can use that within an if-statement to make sure that we keep getting updates to the SYNC event but only update the _totalCountRSO once.

The other RSO is a little more tricky. It tracks the current number of users. The problem is that when a user leaves the page, either by browsing to another page or closing the Tab/Window we need to know so that we can subtract one from the _currentCountRSO.

To get that update we have to rely on the HTML container and ExternalInterface to get a notification. Something that isn’t particularly reliable. If the notification doesn’t arrive then the _currentCountRSO will slowely keep counting up every now and then. I haven’t come up with a solid solution as yet. I’m looking at using some server side script to occationally reset the _currentCountRSO to zero. That will come in a later update, when I get to that chapter. ;-)

Adendummmm
The Javascript for removing 1 count from the _currentCountRSO isn’t working at all within the blog. It does work in stand alone pages with the app. I have allowScriptAccess set to always, the Javascript is embeded in the page template. Got me. Any ideas?

Actually, I just discovered that it does work on FireFox in my Ubuntu laptop. Whatever!

The index.template.html is included in the source code so you can see how all that works. Plus I threw in a comment here and there. It should be pretty easy to follow.

All you need to run this app yourself is Flash Media Server 3. If you need I have a video tutorial that covers FMS installation and setup.

Persistence of Remote SharedObjects originally appeared on polyGeek.com on October 21, 2008.

It turns out that Flash Media Server 3 can do a lot more than just stream video. You can also use it for things like storing Remote SharedObjects. Which is really handy for creating all sorts of collaborative web applications.

Remote SharedObjects are very similar to local SharedObjects. But the Remote version has one very, VERY, handy feature: when the data in a Remote SharedObject is changed it triggers an event to every instance of the SharedObject.

As an example, check out the Flex app to the right here with the Flex accordion. Have you noticed it changing automatically? If so that’s because someone else is viewing this page, right now, and they are navigating around in the accordion. If it’s not changing then maybe there’s no one else reading this post.  So try opening this page in a new Tab/Window. Now you can navigate in one Tab/Window and see it change in the other. Cool, eh?

Obviously this is a very rudimentary example but I wanted to keep it as simple as possible and not muck up the essential point here with a bunch of unnecessary code.

To experiment with this you’ll need Flash Media Server 3 running on your machine. If you don’t already then I have a video tutorial that covers the installation and setup. It’s very easy, when it works. When it doesn’t it’s a real pain in the rear exhaust port. :-)

Tip: Don’t change the value of a Remote SharedObject in the SYNC handler. Because that will cause it to fire again, and again, and, I think they call this an infinite loop. You don’t want that. :-)

Addendummmmm
Initially this app wasn’t working on any PC except mine. After a few hours of pondering, and poking I finally happened upon the solution.

If you look at the source code you’ll see the following line in the init() method:

_nc.connect( "rtmp://localhost/FMS_Flex" );

Now the version that you’re actually loading here is slightly different because I added a little code to call to get the IP address from a database. Because I’m running this off my home PC and I don’t have a static IP address. So now when it changes all I’ll have to do is go update the DB and all my apps will work again.

Anyhow, the connection should actually look like this:

_nc.connect( "rtmp://localhost:1935/FMS_Flex" );

or in the actually implimentation here

_nc.connect( "rtmp://" + ip + ":1935/FMS_Flex" );

Where the variable “ip” is retrieved from the DB.

Now this does seem a little odd to me because I could stream video off my FMS server without specifying the port. Do you know why? ’cause I don’t. :-)

Special thanks to cisnky for the suggestion that it was port related. Because I didn’t think it was at first.

Experimenting with Remote SharedObjects originally appeared on polyGeek.com on October 20, 2008.