Imagine you run a Flash calculator on your site, that can store numbers in a Local Shared Object (LSO), and have the great idea of adding a pop-up version of the calculator. After rolling up your brain sleeves and thinking about it for a minute, it becomes pretty clear that both versions will have to access the same LSO. There are mainly two reasons for this:

1. In the pop-up version the user will want to have access to the numbers she has already stored in the main version.
2. Numbers stored in the pop-up version should become available to the main version.

“That’s an easy one”, you think. “Since I’m already using the

SharedObject.flush()

method every time I save a number, to make sure it gets written to the disk, the LSO will always be up-to-date. Right?”

You guessed it …

The problem

Wrong. The following scenario demonstrates it: A visitor goes to the website, makes some calculations and saves a few numbers. He then opens the pop-up version, it loads the numbers from the LSO, and he saves a few more numbers. He closes the pop-up and the LSO now contains the old numbers from the main version and the new numbers from the pop-up version. So far so good.

But now he goes to watch the latest episode of Diggnation and that’s where the problem starts. Alex and Kevin (once again) start trying to figure out how many beers they must have drank in all the Diggnation episodes. Our visitor thinks “Ah, wait a minute, I have the calculator still open. I’ll figure it out once and for all”. He clicks on the calculator tab and starts crunching the numbers. When he’s done he saves the result, so that he can email it to them, because they couldn’t figure it out. The problem is, that now the LSO contains the old numbers from the main version and the number of beers that Kevin and Alex drank – but the saved numbers from the pop-up are gone.

The reason this happens, is that once you load the LSO with the

SharedObject.getLocal("lsoID_str", "/")

method into an SWF file, the SWF file works with it’s own temporary copy of the LSO. Whatever happens with the real LSO in the meantime, it will be overwritten by the SWF’s own copy the next time

SharedObject.flush()

is called or when the SWF file flushes automatically by being closed.

The solution

That means that you need to force the SWF to update it’s copy of the LSO before you change any information in the LSO. The intuitive way to achieve this – calling the

SharedObject.getLocal("lsoID_str", "/")

method again – doesn’t work. If the SWF already has a copy of the LSO, the

getLocal()

method will not do anything. The way you can force the SWF to load a fresh copy of the LSO however, is by first deleting the variable to which you assigned the Shared Object.

So keeping in mind, that we have to refresh the LSO every time we want to access it, or store data in it, the right code for this job might look something like this:

class SO {
     private var cookie_so:SharedObject;
     public function SO() {
     }
     public function saveNumber(id_str:String, value:Number):Void {
          loadSO();
          cookie_so.data[id_str] = value;
          unloadSO();
     }
     public function returnNumber(id_str:String):Number {
          loadSO();
          var fetchedNumber:Number = cookie_so.data[id_str];
          unloadSO();
          return fetchedNumber;
     }
     private function loadSO():Void {
          cookie_so = SharedObject.getLocal("calculator", "/");
     }
     private function unloadSO():Void {
          cookie_so.flush();
          delete cookie_so;
     }
}

Now, you can open multiple instances of the SWF file, save numbers in each of them and LSO will contain the saved numbers from all of them.

About the getLocal()method

As you can see in the above script, the

SharedObject.getLocal("lsoID_str", "/")

method has two parameters. The first one is required and holds the name of the LSO. If an LSO with this name doesn’t exist, this method will create one. Otherwise it loads the LSO into the variable it is assigned to.

The second parameter is optional and holds the “localPath”. This is important for our example, because if “localPath” is not specified, the LSOs of the calling SWFs will be stored in a folder structure mirroring the structure on the host. That means that if one calculator is in the root directory, it’s LSO will be stored in a folder called “example-domain.com”. But if the pop-up calculator is in a subfolder of the root directory called “pop-ups”, then it’s LSO will be stored in a subfolder of the “example-domain.com” folder called “pop-ups”. The result would be, that the root calculator would not be able to read the LSO of the pop-up calculator. That is why we need to specify the second parameter. The value of “/” specifies, that the LSO is stored under “example-domain.com” to which every SWF running on that domain has access.

Notes

This solution works reliably when the SWF files are embedded in a browser, but it works only sporadically when I open the files locally in my Flash player. I suspect this is more a problem with my system, rather then with the script, because when I open the same files locally with a browser, they work fine again.