event.type == "applicationSuspend" - Saving State Watch Out!

Solar2D iOS
#1

I noticed that when I suspend and resume my app my app crashes with no immediately obvious console error giving me a clue. This is iOS. This only happens when I fairly quickly resume after 1 - 3 seconds or so. After 3 seconds or so, then my app doesn’t resume - it actually restarts.

Turns out that I am spending way too many cycles saving state when I suspend my app. Ouch! It never occurred to me before that I have a limited amount of time to save state before the OS pulls the plug. Whoops!

I have 68 ‘chunks of data’ to save in event.type == “applicationSuspend”

When I output some debug to the console my: for i = 1, #chunk do loop

the loop terminates at i = 56 and not 68.

I just wanted to point this out as I’ve never encountered this problem before. No doubt many of you are saving state in “applicationSuspend”… Hopefully you are saving all you think you are saving…

Meantime, I’ll have to think of a solution to my particular problem of spending too much time in my function to save state and the OS pulling the rug after 56 chunks saved and not the entire 68 chunks…!

:open_mouth:

https://docs.coronalabs.com/api/event/system/type.html warning about it here…

#2

I find no issues saving state in onSuspend (but I do block crappy devices). I save 500KB of encrypted data.

You have a couple of seconds to clean up on suspend. How much data are you trying to save and how efficient is your actual code?

1 Like
#3

325KB! My persistence code has been gathering dust in a corner for a few years if you know what I mean…

Turns out that I am saving rather a lot of data that does not need saving - i.e. its state is immutable. I will tidy up and reduce my 325KB size down to a fraction of that. Interesting and encouraging to see that you are saving 500KB SGS. I wonder if you are reaching the limit of the data size that can be saved? All the same, I’m with you on the crappy devices! In saying that I am running a crappy old iPad Mini 4 from 2015. Yikes! :-o

Now, back to my crappy code! Ha! :slight_smile:

#4

I’d best take the opportunity to encrypt also. I’ll dig around in the docs and see what the options are. Cheers. :+1:

#5

Definitely encrypt local saves otherwise they are too easy to modify. I crunch the data to the absolute minimum which is 400-500KB, then encrypt it using the openssl plugin.

I imagine it is more a slow code issue in your case. If you need help optimizing feel free to reach out.

1 Like
#6

Much appreciated SGS. I’ll reach out if I get into bother. I think I’ll be able to reduce the file size to just a few KB as my persistence code is legacy code from earlier apps and its efficiency can be greatly improved. I will look into the openssl plugin today also. I am sure using it will ease my mind considerably. Thanks again! :slight_smile:

#7

@anon63346430 got myself into a bind with saving/restoring tables with numerical indices. I have a LOT of string concatenation ops in my save/restore code and file pointer manipulation. Hangover from decades of C programming and not really embracing json as I ought to!

Turns out that a single call to newState = table.concat(buffer) before writing the file out is blazing fast. I’ve ditched the vast number of calls to the Lua concatenation operator and all is well and good. Phew, relief! :slight_smile: