Ludicrous Software

When to Save Shared Object Data

(I ran up against this problem a couple of months ago, and when it happened again today I’d completely forgotten about how I’d fixed it, so this is more a note-to-self than anything else…)

My past practice has been to write data to the Shared Object right before the `fscommand2(“quit”)` call, on the assumption that this would ensure that it would capture the most recent data, and nothing would be lost. This has worked fine up until the Nokia 5800, which handles this kind of strangely.

In the process of testing a game, I transferred the swf to the phone via Bluetooth, so it was in my messaging inbox. When I launched the game from there, it would save the data as expected, and so the data would be waiting for me when I launched the game again. All’s well so far.

Next step was to package the game into a sis file. When it was installed from the sis and launched from the icon in the Apps folder, the game would not save data upon exit. Very odd. Even odder was that if I navigated directly to the installed swf and launched the game from there, it would save data.

My best guess as to the cause of the problem is that the manner in which a swf is started and stopped when it’s installed from a sis file somehow interrupts the normal manner in which this occurs. I’m not sure of the hows or the whys, but this seems to be what’s happening.

Luckily, the fix is pretty simple: just make sure that you’re saving your data a short period of time before the app quits. In my case, to exit the game you return to the main menu, press the ‘quit’ button, then press ‘yes’ on the confirm screen. I modified the code so that the save data function is called when you return to the main menu screen. Even if you press the required buttons fairly quickly, this still gives a second or two for the data to be saved. In my case, that’s plenty of time, but be sure to test your application to make sure it’s sufficient for your app.