You will need a boolean variable. We're going to access this from two threads, so we make it volatile.
Code:
private volatile boolean pauseGame;

Originally Posted by
Shayan Rais
How to detect the incoming call, Please can someone share the code?
Assuming a Canvas is displayed, you will receive a hideNotify() event, as I wrote in my previous post.
Code:
protected void hideNotify() {
// we intercept this to detect an incoming call/sms/etc
pauseGame = true;
}

Originally Posted by
asjadazeem
There is also a problem while intializing a tread globally, how can I pause and resume a thread? I mean there must be a pair of function for this?
You cannot "pause a thread", and I strongly recommend you do not attempt to stop and restart.
If your thread contains a loop, check the pause flag in the loop.
Code:
public void run() {
while (!exitGame) {
if (!pauseGame) {
doGameLogic();
}
repaint();
serviceRepaints();
makeSureYouSleep();
}
}
protected void paint(Graphics g) {
int width = getWidth();
int height = getHeight();
if (pauseGame) {
// this paints something like "press 5 to resume"
paintPauseScreen(g, width, height);
} else {
paintGameScreen(g, width, height);
}
}

Originally Posted by
asjadazeem
For the screen tap resume thing, can I start/resume a thread by clicking a button? If that so please share the code.
Easy.
Code:
protected void keyPressed(int code) {
if(pauseGame) {
if (code == KEY_NUM5) {
// or some other key
pauseGame = false;
}
} else {
bufferThisKeyPress(code);
}
}

Originally Posted by
asjadazeem
The game can't be suspended other wise and thats why I need to create a new thread everytime and end the previous one.
It can be left looping, provided it's doing almost nothing each time around the loop but calling Thread.sleep().
Why do I suggest you don't stop the thread?
The obvious thing to do is:
Code:
// DON'T DO THIS
private volatile boolean running;
public void run() {
running = true;
while (running) {
// do game stuff
}
}
protected void hideNotify() {
// stop the thread
running = false;
}
protected void showNotify() {
// kick off a new thread to resume the game
(new Thread(this)).start();
}
So, why not?
You cannot stop a thread. All you can do is leave a message to tell a thread to stop itself, as in the code above with the boolean variable. The thread won't immediately stop... it will only stop next time the loop goes around and checks the variable. On a typical game, on a low end phone, that might be as much as 100ms later.
What's the problem?
Some low end devices are not able to run Java apps while handling a call. As soone as the phone rings, the application "goes into the background", which can actually mean that the entire Java VM is frozen and no more bytecode executes until the end of the call. The effect of this is that the events might not happen when you expect.
Expected: hideNotify() at the start of the call, showNotify() when the call ends.
Actual: (possibly, depending on device) hideNotif() and showNotify() happen in rapid succession, one then the other, with no delay in between - this can happen if both events are sitting in the event queue when the VM gets "unfrozen".
Think about what happens in my "don't do this" example, if hideNotify() and showNotify() happen one then other, with no delay in between.
1. hideNotify() gets called, and sets "running" to false
2. showNotify() gets called, and starts a new Thread.
3. the new Thread enters run(), and sets "running" to true
4. the old Thread eventually loops around, checks "running" and finds it's true - it doesn't fall out of the loop
We now have two threads running around the game loop and some very odd things happening.
I have seen this dozens and dozens of times, where game developers have used this technique to stop and restart the game thread. The code works fine on the device they originally tested the code on (probably a Nokia), but causes havoc when you try to get the game working on other devices.
Allowing the thread to keep running, in a loop where it just "idles" (sleep-loop-sleep-loop-...) is much more reliable across different implementations of MIDP, and never causes any problems in my experience.
Graham.