Resuming From a "Cold" Start (Saving and Resuming app state)(Using System Events to Save App State)

Getting Started Newbie Questions
#1

Hello

I have come across this article but it is kind of outdated. Also when I leave the app and return to it as stated in the article the game messes up**(I am trying to resume in “Cold state” as referred to the article)**. How do I save the app state before leaving the game and resuming it when coming back. Can you also still used the code in the article or no longer supported.

Here is the link to the article : http://coronalabs.com/blog/2012/07/17/using-system-events-to-save-app-state/

Thanks

Schoolt25

#2

Hi @Schoolt25,

The article is a little old but nothing has changed in what it outlines. You can still use system events to handle the app’s state (as it’s about to exit, when it opens “cold”, etc.).

As for “saving the app state”, that is completely dependent on your project. Every app will need to do something different at this point, i.e. saving certain data, remembering the “scene” that the player was in, etc. So there’s no further advice I can give you on that, except that it will almost certainly involve saving some data to the app’s local sandbox, and then reading that data when the app opens and using it to go back to where you were when the app quit.

Best regards,

Brent

#3

Hey Brent

Thanks for replying I have another question to regarding when exiting the app what system events can I use?

Thanks

Schoolt25

#4

Hi @Schoolt25,

The event types are documented here:

http://docs.coronalabs.com/api/event/system/type.html

Best regards,

Brent

#5

Currently I have some help menu’s that are overlay screens.  When they pop up I have paused the physics in the game and then when they close the popup I resume the physics.  This works great for the overlay screen.

If I use the “applicationSuspend” - pause physics like I do on my overlay screen

and use the “applicationReume” - unpause physics like I do on my overlay screen

Since it works for my overlay, would this code work for suspending the application if they leave volutary (hit the home button) or if they receive a phone call?

In reading the Tutorial: Using System Events to Save App State it indicates that the default UIApplicationExits onSuspend is false which is recommended because your apps will resume where they left off automatically unless the OS quits the app in the background.

  1. What does OS quits the app in the background mean?

  2. If it will resume automatically, why do I need to include code to save the app State?

Thanks

Lori

#6

Hi Lori,

In most cases, when the user “suspends” the app (presses the home button or turns off the device entirely) the app should remain in a backgrounded/suspended state (those two terms being the same thing in this context). The user would not typically expect the app to restart entirely upon being backgrounded, although that might be logical in some cases, which is why the non-default option exists in the build settings file.

Now about your questions:

  1. At any time, the OS reserves the right to quit/restart an app that is in the background. This usually happens because the user has opened several other apps since the suspension of that app, and/or the OS needs to allocate more memory toward the currently active app or toward apps that were opened more recently. That’s why, if saving state is important to your game, you should consider this very real possibility and handle the “applicationExit” state as mentioned in that tutorial.

  2. I guess I answered this one in #1. You don’t need to save state on the “applicationSuspend” state, only on the “applicationExit” state. In mirror image, you would then ignore reading/restore of that saved state info on the “applicationResume” state, and instead handle it on “applicationStart”.

Hope this helps,

Brent

#7

Would the “suspend” on applicationExit work the same as what I do when I suspend for pulling up an overlay screen?

Thanks

Lori

#8

Hi Lori,

Well basically yes… if you managed the state on exit, you could return the user to that point in the app, as if it never quit. I should warn you, however, that restoring the exact state can be difficult depending on the app, and if you’re using physics, it will probably be impossible to return the physics world to the exact state that it was frozen in (on pause or whatever). This is because there are countless forces and velocities going on under the Box2D hood… even ones so subtle that you can’t see them… and it would be practically impossible to return the physics world to that point with all of the same physical energies going on.

Brent

#9

So what do I do about keeping the players happy and having the ability to return to game play?    Just let them return to the “altered” state? 

Thanks

Lori

#10

Hi Lori,

Well, it depends on your game design. If your physical objects are more “predictable”, like you have a player moving at a specific linear velocity, you could store that velocity as part of the saved state and resume it when the game returns to that state. However, if you have something like a stacked tower of blocks that are under the influence of gravity and inter-block forces and friction, it may not behave exactly like it did when you saved the state.

What type of physics game are you making?

Brent

#11

It would be more in lign with tower of blocks.  It isn’t under the force of gravity so much as collisions.   I did notice that when I pause and resume for the overlay - it freezes and then when resume the objects take off from the position of their freeze.  I already save the number of moves and score etc during game play so i think I should be ok.

Thanks

Lori

#12

Would I put the system events in my build.settings or would I need them on each level?

Thanks,

Lori

#13

Hi Lori,

What system events in build.settings? I’m not sure I understand…

#14

The system events for applicationSuspend and resume.

#15

Hi Lori,

You should handle system events with a listener function and take the proper action. So basically, it’s not in build.settings, it’s somewhere in your main code.

Brent

#16

Thanks

#17

Hi @Schoolt25,

The article is a little old but nothing has changed in what it outlines. You can still use system events to handle the app’s state (as it’s about to exit, when it opens “cold”, etc.).

As for “saving the app state”, that is completely dependent on your project. Every app will need to do something different at this point, i.e. saving certain data, remembering the “scene” that the player was in, etc. So there’s no further advice I can give you on that, except that it will almost certainly involve saving some data to the app’s local sandbox, and then reading that data when the app opens and using it to go back to where you were when the app quit.

Best regards,

Brent

#18

Hey Brent

Thanks for replying I have another question to regarding when exiting the app what system events can I use?

Thanks

Schoolt25

#19

Hi @Schoolt25,

The event types are documented here:

http://docs.coronalabs.com/api/event/system/type.html

Best regards,

Brent

#20

Currently I have some help menu’s that are overlay screens.  When they pop up I have paused the physics in the game and then when they close the popup I resume the physics.  This works great for the overlay screen.

If I use the “applicationSuspend” - pause physics like I do on my overlay screen

and use the “applicationReume” - unpause physics like I do on my overlay screen

Since it works for my overlay, would this code work for suspending the application if they leave volutary (hit the home button) or if they receive a phone call?

In reading the Tutorial: Using System Events to Save App State it indicates that the default UIApplicationExits onSuspend is false which is recommended because your apps will resume where they left off automatically unless the OS quits the app in the background.

  1. What does OS quits the app in the background mean?

  2. If it will resume automatically, why do I need to include code to save the app State?

Thanks

Lori