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.
| 1. | <?xml version="1.0" encoding="utf-8"?> |
| 2. | <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" creationComplete="init()"> |
| 3. | <mx:Script> |
| 4. | <![CDATA[ |
| 5. | private function init():void |
| 6. | { |
| 7. | var so : SharedObject = SharedObject.getLocal("someTest"); |
| 8. | //Initialize with the current date or the date in the Shared Object |
| 9. | var someDate: Date = new Date(); |
| 10. | if (so.data.thedate != null) someDate = so.data.thedate as Date; |
| 11. | //show the date in the UI |
| 12. | theDate.data = someDate; |
| 13. | //put it in the shared object and force write it to disk |
| 14. | so.data.thedate = someDate; |
| 15. | so.flush(); |
| 16. | //the changes done to the object are stored in the shared object |
| 17. | someDate.setFullYear(1978, 4, 2); |
| 18. | } |
| 19. | ]]> |
| 20. | </mx:Script> |
| 21. | <mx:DateField id="theDate" width="100%" height="100%" /> |
| 22. | </mx:Application> |
| 23. |
Subscribe to:
Post Comments (Atom)
3 comments:
Hi,
I don't think this behavior has anything to do with SharedObject. This is how all object instances behave in AS3, they are passed by reference.
For example:
var o:Object = {};
o.data = {};
var o2:Object = {};
o2.myValue = 20;
o.data.someObj = o2;
o2.myValue = 30;
trace(o.data.someObj.myValue);
//will trace 30
@IonutB
I agree this is the way Objects work, but with SharedObjects it's a bit different because they are stored on the disk and available in other instances of the application. Once you flush the object to the disk, you might expect that state to be on the disk, not any other changes.
So this is not a bug, it's the way it should be, it's just that you might find that the SO updates the value and you don't know why.
Post a Comment