Question

I've searched and none of the topics really seems to help, my problem here is I start a thread on a PopupScreen, wait for it to finish and then close the PopupScreen with the appropriate notification, Here's my code

LoginThread lt  = new LoginThread(str1, str2);
lt.start();

synchronized(lt){
    try{
        lt.wait();
    }catch(InterruptedException ie){
        ie.printStackTrace();
    }
    //Everything works fine until here i add
    close();
   //Or
   this.close();

}

private class LoginThread extends Thread{
    public LoginThread(String str1, String str2){

    }

    public void run(){
        synchronized(this){
            notify();
        }
    }
}

Any suggestion how I can close this popuscreen?

Was it helpful?

Solution

Responders should be aware that this is a BlackBerry Java question, and there are BlackBerry Java implications regarding this processing that are perhaps not apparent in the code supplied.

From a BlackBerry Java perspective, there are many reasons for displaying a PopupScreen, one of which is to lock out the user while some background processing takes place. However this lockout is never achieved using thread.wait. The BlackBerry Ui processing uses an Event driven model, as I understand it a bit like Swing (I am not a Swing expert). The upshot of this is if you try to code a wait and you are attempting to stop the user moving on, then you must wait on the Event Thread, which blocks user input completely. The BlackBerry OS barfs if you try to do this (except on the Simulator, where it sometimes lets you do it for some reason).

For more on this, see here:

What-is-the-Event-Thread

In this case, the user wishes to close the popup screen once the long running processing has completed. I recommend doing that using an pattern like the Observer pattern, in other words, have the Thread call back the Observer (the PopupScreen) on completion. The Observer (screen) can then close itself.

In the mean time, the screen displayed (the Observer) can ignore events that would normally close it, like the 'Esc' key. This screen will display something useful to the user, like "Please wait".

One word of caution however, the call back will take place on the background Thread, but if you want to do Ui processing, the close must be on the Event Thread. Swapping to an Event Thread context is typically done using code like the following:

UiApplication.getUiApplication().invokeLater(new Runnable() {
  public void run() {
    // put code in here
  }
});

This all said, I suggest the Original Poster search again, since I think there are many samples like this around. In none of the samples that I have seen, has anyone used a wait, so I don't quite see why the OP attempted to use a wait in the first place. If this has been seen in a sample, please point me at it (in a comment) so that I can try to fix it.

OTHER TIPS

You probably have to release all locks before you close yourself. Move the close out of the synchronized scope.

In addition you should put the start() in the synchronized block, otherwise the thread may notify() before you reached wait().

Where to begin. The code is a mess, I would not lock on a 'thread' because it is just confusing. Apart from that your wait is unreliable because spurious notifications are possible; so you could be woken up for no particular reason.

This means you need to do it in a loop, but in your case there is not a condition you are waiting for.

I would forget about using synchronized. And in this case I would have a look at a CountDownLatch you initialize to one. The login thread will do a countdown and the main thread will do an await and blocks till the login thread has called countdown. This way you don't need to deal with custom synchronization.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top