Inspiring

Question

SharedObject unexpected behavior or bug?

Forum|Forum|12 years ago
March 25, 2014
2 replies
1419 views

var a:SharedObject = SharedObject.getLocal("test");

trace(a.data.userData);

var d:Array = [1,2];

a.data.userData = d;

a.flush();

d.shift();

I find this behavior odd. If you run this, the first time you'll get nothing in the trace as userData hasn't been initialized. The second time you will get just '2' traced, when I'd expect '1,2'. I find it odd because I've called flush to commit the SO changes to disk. However doing a shift on the array affects the array in userData. I get passed by reference and all, but I think this amounts to a bug - affecting it after the flush() has been run. I've probably seen this before but it caught me off-guard yesterday and took some looking to figure out what was happening.

ActionScript

This topic has been closed for replies.

A

Andrei1-bKoviI

Inspiring

This is quite an interesting finding about ShareObject and its handling...

Does it mean that SO retains reference to an object while application is running and writes a value when application closes? Or, perhaps, another way to look at it is that SO instance is held in Flash memory until application is killed? Adobe description states that there are extra processes occurring when application is closing besides automatic flush(). Is this behavior a manifestation of such behavior?

Did you experiment with this use case?

kglad

Community Expert

the so stored in memory is updated by flash at indeterminate times, similar to the way garbage collecting is indeterminate. however, unlike gc, you can direct flash to update the stored so by using the flush() method.

when you update an so in flash it typically will be updated in memory so quickly that it's difficult (but possible) to close/crash a swf so quickly after an so updates that it fails to save that update to memory. it's not possible to do that if you execute a flush() after the update.

and this topic is not about so's. it's about arrays, shallow vs deep.

it just happend that the op discovered this (shallow vs deep) 'issue' when using an so.data property as a deep copy of an array. the same 'issue' would be found if a more typical copy (of one array assigned to another array) were used.

A

Aaron Beall

Inspiring

Forgive me if I misundstood this thread, but it seems like dmennenoh understood the array behavior, just not the SharedObject state behavior. It looks like he assumed that SO data is only saved via flush(). In fact, under normal circumstances, the current state of data of an SO will be written when the SWF is closed, as long as local storage is allowed by the user's Flash Player settings. Using flush() is mostly provided as a way to let your program resolve problems with saving, like prompt the user for more storage space, or deal with write permission problems -- things that you don't have the chance to resolve when the SWF is closing.

Sorry if I simply re-stated what's already been said.

-Aaron

kglad

Community Expert

a.data.userData is a deep copy of the array d.

if you want a shallow copy use the slice method:

a.data.userData=d.slice();

D

dmennenohAuthor

Inspiring

Right. Like I said, I get the pass by reference. I just think once you do a flush the data in the SO should not be affected. Call it what you want, I find it strange behavior.

kglad

Community Expert

the flush() method is irrelevant.

this is expected behavior of deep copies of an array whether in actionscript or any other programming language. once you understand deep vs shallow array copies, you won't find it baffling.

in brief:

var a:Array = [1,2];

var b:Array = a; // deep copy.

a.push(3);

trace(b); // 1,2,3 expected

---------------------------------------

var a:Array = [1,2];

var b:Array = a.slice(); // shallow copy

a.push(3);

trace(b); // 1,2 expected

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded