You most likely will have this bug too

[killarkai]

I am using nokia 7650 on my tests, i'm not sure does it happen to other handsets, but you can try it out. What i'm sure is it DOES happen to the "Blockgame" that Nokia shared as code example.

Here are the steps to inflict the bug:
1. start your j2me game and play it
2. get someone to call you
3. answer/reject the call, unpause your game and play
4. quit your game and exit the application
5. try to launch your game again

Voila! you'll have "System error". You can't run the game, you can't delete the game, the only way to rectify this is to "reboot" your handset.

It even happen to the commercial j2me games that i tried.

Any feedbacks from Nokia? or fellow developers?

[yowchuan]

Man...that's one serious bug...

Probably that's one of the few things you can't try out on an emulator...wonder how can you "call" an emulator? Do they have a function to do that?

Cheers,
YC

[yowchuan]

Member "affinitystudios" had this problem too:-

http://nkn.forum.nokia.com/forum/sho...AhideNotify%2A

Cheers,
YC

[yowchuan]

Also you might want to refer to this thread as well. Many seems to be facing the same problem...I wonder if there's a fix for this at all...

http://nkn.forum.nokia.com/forum/sho...threadid=13439

Cheers,
YC

[jameswmohr]

I had this problem on my 3650, and after a number of tests came to a good solution.

First, most people know that pauseApp() is never called, and startApp() is only called once: when the app actually starts.

Second, although hideNotify() and showNotify() are called as described (mostly), I could never get them to successfully pause and unpause my program when a call came in: inevitably the program would lock.

So, the working solution (it was posted earlier on this board) is to use Displayable.isShown(). Call this in your main canvas loop at the start of every frame and, if it returns false, then consider yourself paused. I can vouch that this successfully handles phone call interruptions on the 3650 as well as when the user presses the red disconnect key (which puts the MIDlet in the background).

[killarkai]

i used your method and managed to get my game to pause, but what about that system error? do you have a way to solve that too?

[badappleFG]

Killarki the system error shoudl disappear..

in you first post example even though you were physical unpausing game MIdlet did not register that action as unpasing the game..

thus system error as you were trying to restart game that had not properly eixted..I think?

If this is not right someone correct me..

[badappleFG]

seems that Dsiplayable.isShown() sould be called in every screen not just the main one..or am I missing something?

[badappleFG]

Okay stupid question time..

what is the difference between using Displayable.isShown and checking for false and heading to display menu and calling mainmenu.init to handle game at end of call
..and using

a keyPressed method to check for a softkey press..ie pressing the pickup call button as pausing the game?

Obviously keyPressed implementation could be used in all screens not just the gameCanvas screens..

have I missed something here?

Okay firgured out do a portable version..

If we do if(!keyCode==

all the action keys of game then assume gameIsPaused and setup mainmenu as

menu.init(parent);
parent.setDisplaable(menu);

..so now code is then portable to every device..and works both in the canvases of the game including the splash canvas as well as the form screens..cool!
'

OKay yes I wil post a longer code description at my weblog:

http://www.freeroller.net/page/shareme/Weblog

I should have it up on Monday and post a link here as well..

[shmoove]

That approach won't work, because the moment the incoming call comes in the displayable on screen is not one of your MIDlet's displayables, but the "xxx is calling. Answer?" screen. So you won't be able to capture keypresses on that screen.
Also, there is no keyPressed() on form screens.

shmoove

[badappleFG]

okay but keyPressed is still the way to go on Canvas screens..

on Form screens you check for is it not the command keys you defined if not then assume tits the answer call button and processed as paused form screen....basicaly send user back to main menu so when call is doen they can re-enter the form screen tha tthey were on..

[kisember]

Are you sure that you can capture commands when you unable to capture keyPressed events?
As shmoove wrote, another screen is in focus when incoming call comes, so that point the midlet already in background, no input delivered.

[shmoove]

another screen is in focus when incoming call comes, so that point the midlet already in background, no input delivered.

Yes. That was my main point, and that's the reason this approach won't work neither on a Form nor on a Canvas.
As a side note I added that you can't even implement that on a Form because there is no keyPressed() on forms so:

on Form screens you check for is it not the command keys you defined if not then assume tits the answer call button

this can't be done.
I think the only viable way to catch an incoming call on forms is checking isShown() in a loop. And a real pain in the *&! it is! If only Nokia had implemented the pauseApp() method properly

shmoove