During an active play session if the game is interrupted it must be paused and saved and the user must be able to continue the game with a continue game option from the main menu. I can understand how to add a continue option to the main menu if the game gets paused and remove the option if it is not needed. But how to you keep all the game states saved when the user gets an incoming call and dose’nt come back to the game for at least 24h. Do you just pause the thread and then resume it when the user comes back to the game. Is this a possible solution. Would pausing the thread still mean that your game is holding stack memory for the time until the user comes back to the game. Reading the Developer Check list there are some difficult stuff there needing implementing ( well I suppose once you’ve done it once you’ll know how to implement it again for the next applications) You need to also do the above when a soft key is pressed and when a red soft key is pressed and when the application is exited and the user does not press the button. How do you save the game when an incoming call is received when you need to save it for long periods. I think using the showNotify() and hideNotify(). But do you pause your thread… surely saving everthing to RMS is not a solution. Brian

From all the submissions I''ve done, I''ve not needed to save the game state (let alone to RMS), nor have I had to return to the main menu. All that I''ve needed to do is put a paused message along the lines of: "Paused. Press any key."

But what do I know?

Skizz

In the Nokia Check list it specifies that you need to do this for ''nokia'' to ''love your app'' so i would like to do it if its not rocket science.

The only way i can think of doing this is to not close the app but maybe like you told me before skizz use some kind of yeild statement and leave the thread goingin the background.

Its late so will sleep on it and see if there is a better way.

B

You basically pause your application by setting a flag in your run method of the thread. The thread still runs, but the application do not get processed. There are some issues to handle if your application is a time-based application, like when you resume you have to take the new time to start processing, etc. But that''s up to you to resolve it.
There seems to be some issue with pauseApp and startApp. From the documentation it seems like they should be called when you get an incoming call, but for some phones we tested on it doesn''t. Instead we resorted to using showNotify and hideNofity to do the pausing. But when we port to a series 60 phone, this method did not work. Instead we do the pausing in the startApp and pauseApp. So we handle both just in case and to make porting of applications easier.

So you are then leaving your application running in the background. from the time the player leaves the game to take the call or do what ever to the time they come back?

Does this adversely effect the phones responcivness and do you use anything like yeild statements to make it better?

Brian

Leaving the application running in the background doesn''t affect the phone''s responsiveness. The CPU running the phone''s software is separate to the DSP that handles sending/receiving voice data.

Skizz

That all depends on the implementation on the phone. The Sharp GX10 doesn''t allow access to the apps menu if an app is running. The Nokia S60 switches to the app if selected from the apps menu. I''ve yet to see a phone that can run two instances of the app at the same time - I think it wouldn''t happen mainly to simplify the record store management (no need to serialise access to it).

Skizz