Adobe recently released version 10.3 of the Flash Player. Amongst the cool new features there is a long expected one by the privacy control freaks: the clearing of local shared objects when clearing cookies in the browser. The idea is very nice, whenever the user clears their cookies, they actually want to remove all the session information the browser maintains.
When my desktop updated to FP 10.3 this morning I decided to give this new feature a spin. After googling a bit I found this demo page from Microsoft made for IE. Simply input some text in the form field, hit save and after a refresh the data is maintained. Clear the cookies, refresh the page and the text is gone.
So where's the problem ?! It seems FP doesn't care which browser was used to set that shared object, so it simply deletes ALL shared objects created by any browser. Try this:
1. Open the link above in Chrome/Firefox. Enter some text and hit refresh. The text is stored.
2. Open an IE instance.
3. Clear the cookies in IE.
4. Refresh the page in Chromme/Firefox. The information is gone.
I know there has been a lot of pressure on Adobe to implement this, but I think the way it works now makes Shared Objects very unreliable. When a user clears the cookies in a browser, they expect that only the information in that browser will be affected.

I really hope Adobe fixes this soon by making clearing local storage browser-dependent. I opened a bug here, if you agree please vote for it.

I've been in the online gambling industry for a while and I noticed that it's relying more and more on the Flash Platform. The applications created by online gambling companies have large budgets and use state of the art technology. They usually have dedicated User Experience professionals who make sure the application looks and feels right to the customers. After all, the most important thing is to make the users feel good and you won't succeed that if they can not find the sounds off button.

Live betting
There isn't a sports punter in the world who can say that they don't like to bet after the event has started. Nothing compares to watching the game on TV and waiting for the price to reach your target. In this kind of applications data synchronization between the server and the client application is crucial and sometimes 1 second of delay can mean thousands of bets have to be canceled. There's no need to add that this is bad for business.

The live game events is a great way to stay in touch with what's happening if you're not watching the game.

Lobby
Because online gambling companies sometimes have a lot of games the offer, there is an increasing need for lobby applications which can present the games to the user and allow him to launch them with just one click.

Great 3D look and very good matching sounds.

(source livedealer.org)

A very interesting thing I noticed a while ago is the behavior of SharedObjects when the data in them is an object as well. The idea is that when you add any Object to the data field of a SharedObject instance this is not cloned and is passed by reference. So from then on, any changes to the Object will be reflected in the SharedObject data.

If you want to prevent this behaviour it's best that you create clones of the object and asign them to the SharedObject.

Bellow I added a Flex example to prove it. The first time you run the program below, it will show the current date because there's nothing in the SO. From the second run onward it is showing the 78 Date although that change is never flushed.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" creationComplete="init()">
 <mx:Script>
  <![CDATA[
   private function init():void
   {
    var so : SharedObject = SharedObject.getLocal("someTest");
    //Initialize with the current date or the date in the Shared Object
    var someDate: Date = new Date();
    if (so.data.thedate != null) someDate = so.data.thedate as Date;
    //show the date in the UI
    theDate.data = someDate;
    //put it in the shared object and force write it to disk
    so.data.thedate = someDate;
    so.flush();
    //the changes done to the object are stored in the shared object
    someDate.setFullYear(1978, 4, 2);
   }
  ]]>
 </mx:Script>
 <mx:DateField id="theDate" width="100%" height="100%" />
</mx:Application>