Read SharedObject directly from sol file (Android)

[marchbold]

Made a bit of an error in a recent release of an Android app and accidentally changed the name of the swf that was packaged with the app. (We upgraded this project from FB to IntelliJ and ignored the output name change.)

It seemed fine in testing however we use a SharedObject in this app to store some user data and I hadn't realised that a SharedObject is stored in a path containing the name of the swf:

#SharedObjects/app.swf/objectname.sol

So the name change to swf meant that our users are losing their data when upgrading the app.

#SharedObjects/app_new.swf/objectname.sol

I was hoping to be able to do a new update and merge the two objects, but I can't seem to load the old data with SharedObject.

Does anyone know how to read the .sol format directly? Is there a library available anywhere?

I can access the file in the old path but I'm hoping I don't have to write a parser.

[rewb0rn]

Have you tried to create a second .swf with the old name and load it into your main.swf to see if that one can load the old SharedObject, while the main swf (new name) accesses the new SharedObject?

I have no info about the .sol format. But in case no one can help, here is another idea: You could try and release a new version that copies all the user data from the new SharedObject to some other persistence storage, e.g. a local database or your own file format. Then one week later you release another update to access the old SharedObject and merge into it all the data that exists in the local database / your own file format. That way you quickly revert the broken change and also maintain the data that has been stored since the rename has occured for most of your users. (All that started the app during that week)

[marchbold]

Good idea, but that method would involve ensuring everyone updated through both versions right? Anyone who skipped one of the versions would lose data?

Think I'm going to have to bite the bullet and write an as3 sol parser.

[rewb0rn]

Yes, this would only work for those people that start the app at least once for each update, so you would definitely lose data for a portion of the users. Depending on the kind of data (preferences vs progress data for example) this might be acceptable or not. We have been using this approach in the past when migrating from one local storage type to another, but over periods of several months and only for preference / login data that is not catastrophic to lose.

[marchbold]

Unfortunately we can't rely on that in this case. Our user's are irregular updaters and we have a critical issue I have to address.

Definitely going to be even more hesitant on using SharedObject for mobile apps in the future.

[rewb0rn]

Have you tried to create a second .swf with the old name and load it into your main.swf to see if that one can load the old SharedObject, while the main swf (new name) accesses the new SharedObject?

[marchbold]

Hmmm, no I have not. And that sounds like a great idea! Started writing a sol parser but going to try that as well.

[ASWC]

You really should be hesitant. AIR makes it very easy to create persistent data that YOU completely control with all SQLite and related classes. SharedObject not only should not be relied upon for important data but the user is in total control of it as well (can be deleted ANYTIME).

[zwetan_uk]

if you want to parse manually, the format is about

header - 16 bytes

  |_ magic:      00 BF       - 2 bytes - readUnsignedShort()

  |_ LSO length: 00 00 04 59 - 4 bytes - readUnsignedInt()

  |_ TCSO:       54 43 53 4F - 4 bytes - readUnsignedInt()

  |_ padding:    00 04 00 00 00 00 - 6 bytes - readUnsignedInt() + readUnsignedShort()

data

  |_ LSO name:   ...               - VA bytes - readUTF()

  |_ padding:    00 00 00 00       - 4 bytes - readUnsignedInt()

  |_ data:       ...               - N bytes (AMF0) eg. be sure to use ObjectEncoding.AMF0

or if you want more control you can look into this project, there is an AS3 class AMF0

cvlib

[marchbold]

zwetan_uk​ Gotten exactly that far already myself Though the padding in your "data" block is actually the AMF version, and will be 3 for newly created SharedObjects (AMF3).

data

|_ LSO name length: 2 byte short  readUnsignedShort

|_ LSO name bytes: readUTFBytes

|_ AMF version: readInt

|_ data ...

I was hoping to use the ByteArray.readObject function to read the AMF data block at the end, but it's not working, keeps throwing range errors. The data definitely is there, though looks slightly different from what I've read about AMF data, but not sure if I just don't understand the AMF data format.

Have you got a copy of that cvlib? Doesn't seem to be on Google Code any more? Hoping I don't have to write an AMF parser as well.

ASWC​ Isn't SQLite still stored in a file in the application storage? So the user can just as easily delete that as a shared object? Definitely agree that SharedObjects aren't the best solution for storage though.

[marchbold]

zwetan_uk​ I found a copy, thanks.

Definitely looks as though the format in the SharedObject is a variant on the AMF standard object encoding, but I've got it extracting what I need now.

[zwetan_uk]

michaelarchbold​
thanks for the AMF version bit, missed that one
but do check the AMF0 class it seems a LSO even if versioned as AMF3 starts as AMF0
and only when a certain bit is encountered then it moves to AMF3 deserialization

I didn't tested more than that, it was just notes I kept in prevision of implementating ShareObject in Redtamarin

in other things you might want to look into
SolVE - Local Shared Object Viewer/Editor for Flash

in the source file it got archive of discussions about the format eg. etc/SharedObjectFile.html
but imho the AMF0 AS3 class is the one that was working reading most .sol files when I tested long ago

ASWC​

I don't see the issue, it is a user save file, it helps the user restore settings/preferences/etc.
if the user delete it then he/she is just deleting his/her own "save file"

now in term of formats it is rather really good as it does support class serialization/deserialization and stays very compact
in general I go this way: if the data need to be user readable/editable I go with XML or JSON or Conf style file
but if I need to store complex objects to restore states in the app LSO is the way to go
and for SQLite I would say it is more if I have to store a lot of data that need to be searched/filtered locally

anyway I don't see LSO as something not reliable just because the user can access it

[Guillaume DOWiNO]

Hi Michael,

I also need to read some older sharedobject for an app I'm porting to another technology than AIR AS3, but I never find somewhere the path where are saved the shared object localy on Android and iOS. Do you know this ?
You write "#SharedObjects/xxx" where have you found this ?

Regards,

[marchbold]

From memory I was just doing a directory listing on the device and inspecting the files in the application storage directory.