It’s been well over a year since I update my game on mobile and it appears I’ve broken loading save data somewhere in the process.
Digging back it seems the current version that is live in the store uses a legacy form of sharedobjects (that is - not at all?) I think I’ve narrowed it down to a section of SharedObject.hx in the openfl 3.6.1 _legacy folders that an old version of the game would call:
#if (iphone || android || tizen)
var rawData:String = untyped lime_get_user_preference (name);
which looking at the bottom of the file appears to be shorthand for the function
cpp.Lib.load ("lime-legacy", "lime_legacy_get_user_preference", 1);
I think I need a way to call these native get and set user preferences functions that used to be used so that I can access current player’s save data, but be able to do that with all the very latest openfl/lime/haxe/hxcpp dependencies which my game now relies on in many other ways. Trying to call that line with modern frameworks crashes the game instantly with no error messages. I’m definitely a bit over my head with this kind of stuff.
Yeah, SharedObjects used to be saved as user preferences rather than as explicit
.sol files. Since the code for accessing those preferences seems to be completely absent from Lime now, you’ll want to grab the legacy code and put it in an extension, or manually find and parse the files where user prefs are stored with Haxe code.
Since I believe the user prefs can be found in different places on different Android devices, it’s probably easier to copy over the old Lime code.
Here’s an extension where the work is already done (probably). It came from a larger extension, with some things cut out and others renamed. Honestly, I didn’t test it after refactoring.
With that extension included, you would probably write something like this to access the old SharedObjects.
public static function convertLegacySharedObject(name:String):Void
var path = SharedObject.__getPath("", name);
var data = MobilePrefs.getUserPreference(name);
if(data != null && data != "")
var directory = Path.directory(path);
var output = File.write(path, false);
Ah thanks so much! I’ll have to test it out when I get a chance.
I had managed a horribly hacky method for android by finding and reading the “nmeAppPrefs.xml” file and parsing the xml for the data but like you said if different devices saved it in a different folder or name I’d be out of luck, plus would have to write a similar thing for however ios works. An extension for retrieving the user preferences should be much cleaner and more reliable.
Yeah, I was going to do the same thing until I saw this post. Perhaps Samsung is the only vendor that has a different Shared Preferences path, perhaps there are others. But using the bit of Java code should prevent you from getting the wrong path, and it’ll be the same as the legacy lime code returned.
Just added the extension and it seems to be working great on both android and ios! Exactly what I needed, and it worked without having to make any changes to your code.
Thanks for the help!