Save/Restore app state

One thing I like about smartphones is that they can remember the last state of previously opened apps for some time, which is handy for stuff like games and deep-nested setting menus.
I'm not sure how/if this is implemented on other smartwatches, but I think it could be beneficial to the BangleJS 2.
I think it could be done by just writing vardumps to Flash memory and just loading them when requested? BangleJS 2 doesn't really have free buttons or button combinations, so I'm not sure how state management (quick app open or state deletion) could be done without using up widget space, but maybe a widget button (kinda like the message widget) would be fine.
I figure if such a thing were to be implemented there would be Bangle.on events for before saving and after restoring.

Apps could use the E.kill event to save state to a file, and check if the file exists and restore it when loading the app.

Yes... I had been wondering about that - you could potentially save/restore into Storage, but it's not going to be very fast, and potentially some peripherals that need setting up could end up broken when restored.

As @rigrig says you can (and some apps do) just use the kill event to save and restore, and that works pretty well.

So I've been trying to do a firmware thing for this, where certain Espruino builds would automatically save and load vardumps made with jsfSaveToFlash (I intend on making a format with a timestamp and maybe a dump of the current Graphics state?) on load calls, but I can't seem to figure it out - I save the vardump and load it with the same js*SoftKill and js*SoftInit things as the real save and load do, but it doesn't seem to load the variables, and instead just run an empty instance, as if there was no loading done at all.
@Gordon Can you help me figure out what's wrong, and maybe tell me if something with a concept like this would be merged?
Source code: https://github.com/TheGLander/Espruino/t­ree/suspend-runtime

I'm sorry, I don't really have the bandwidth for this at the moment - but what you're doing there (basically just changing jsfNameFromString(SAVED_CODE_VARIMAGE) to something else) looks fine to me, so there might just be some small bug in what's been done. Maybe print the filename to the console and check?

I'm not sure your persist argument is super helpful though.

In theory, yes, I'd be up for merging a PR that allowed you to save to image files (maybe not the timestamp/graphics/bit though). Ideally the changes in src/jsinteractive.c would be a bit cleaner though as there looks like a lot of code/duplication in there