Issue with SharedObjects between Air 3.4 and Air 3.5

[Lorenzo_Nuvoletta-K15qTH]

I opened a bug a while ago https://bugbase.adobe.com/index.cfm?event=bug&id=3347676 but I am not sure if the bug is being worked on or not, I see Reason "Waiting" and not really suire what that means.

The issue is this, I have been storing some infromation about the user in a SharedObject using this syntax _diskCache = SharedObject.getLocal("diskCache");

The name of the SWF file is MOBILE.swf, although the parameter <filename> in the Application.xml is <filename>Air App</filename>

For months:

Android has been storing the SharedObject data using the actual SWF name, so in MOBILE.swf,

iOS has been storing the SharedObject data using the <filename> parameter, so in Air App.swf.

Since Air 3.5 this has changed (When compiling an ad-Hoc IPA), Air 3.5 now works like Android.

This is ok since all devices should behave the same, although now all the players that had data stored in their SharedObjects are going to lose it, and trust me they are going to get mad about it and vote down my app.

The only workaround I found for this is change the filename everytime i have to compile for iOS or Android, this is getting pretty PITA, is it anything that Adobe can do alleviate my pains? Or does anybody knows a better workaround?

Thanks.

[chris.campbell]

This unfortunately was deferred for 3.5, but has a status of "ToFix" for AIR 3.6.  I'd recommend pinging me again in a couple weeks to see if I have any updates available.

[chris.campbell]

Hi Lorenzo,

I realize you have a workaround that you're using, but I also received the following info from the team today that I wanted to pass along.  This is being treated with high priority and we're hoping to have this addressed in a future 3.5 update.

The problem shows up when the tags <content> and <filename> in the application descriptor have different values (which is a common scenario). So an easy way for a developer to fix the problem for the time being would be to assign same values to these tags.

Thanks,
Chris

[Lorenzo_Nuvoletta-K15qTH]

Hi Chris, thanks, currently we are using the workaround you described.

Out of curiosity, since this bug was introduced in Air 3.5, can't they simply revert to how it used to work in Air 3.4?

[Nimisha1]

For more details and workaround please refer

http://blogs.adobe.com/airodynamics/2012/12/10/changed-behavior-of-shared-object-on-ios-in-air-3-5/

We would like to hear your feedback, please let us know if you face any issues!

Thanks,

Nimisha

[chris.campbell]

We now have a partial fix available in our AIR 3.6 labs release.  For additional details please see our release notes or this announcement page:

http://forums.adobe.com/thread/1111619