BlackBerry: "Application is not responding; process terminated" because of UiApplication.getUiApplication().popScreen()?

I have a Blackberry application which, when run in some emulators with touch support (ex: 9500, 9520, 9530, 9550), terminates with:

"Application is not responding; process XPTO terminated"

Using logs, I found out that it seems like the application is stopping in a class where I asynchronously make HTTP requests: something like:

public class LoadingFullScreen extends FullScreen implements Runnable {

    private Thread actionThread = null;

    protected void onDisplay() {
        actionThread = new Thread(this);
        actionThread.start();
    }

    protected void onUndisplay() {
        if(actionThread != null && actionThread.isAlive()) {
            actionThread.interrupt();
        }
    }

    public void run() {
        //make http requests - this is done successfully

        synchronized(Application.getEventLock()) {
                Screen active = UiApplication.getUiApplication().getActiveScreen();
                if (active instanceof LoadingFullScreen) {
                    Logger.debug("LoadingFullScreen popping screen"); //this appears in logs
                    UiApplication.getUiApplication().popScreen(active);
                    Logger.debug("LoadingFullScreen screen popped"); //this never appears in logs
                }
        }
    }
}

I launch this screen with UiApplication.getUiApplication().pushModalScreen(new LoadingFullScreen())

In the logs I can see:

[0.0] Wed Jul 27 17:53:06 GMT 2011 - DEBUG: LoadingFullScreen popping screen
[0.0] JVM: bklt[1] @163148: JBSC on=0
[0.0] JVM: bklt[1] @163148: SC 0
[0.0] JVM: bklt[1]: setTimeout 30
[0.0] Application XPTO(212) is not respon开发者_运维技巧ding; process terminated

It seems like UiApplication.getUiApplication().popScreen() is blocking the application, and so the OS kills the application, but why?

EDIT:

I have also tried using

UiApplication.getUiApplication().invokeLater(new Runnable() {...} };            

instead of synchronized(Application.getEventLock()) {...} but I have the exact same result

EDIT 2:

I have also tried active.close() instead of UiApplication.getUiApplication().popScreen(active); but I have the exact same result

EDIT 3: Using javaloader I got this kind of stacktrace from the emulator:

guid:0x9C3CD62E3320B498 time: Thu Jul 28 15:02:50 2011  severity:0 type:3 app:Java Exception data:
    ForcedStackTraceException
    net_rim_services_impl(4) 27 2 0x1030B000
    net_rim_os-3(4BEF0320)
     HttpConnectionManager$CleanupThread
     run
     0x3B09
guid:0x9C3CD62E3320B498 time: Thu Jul 28 15:02:50 2011  severity:0 type:3 app:Java Exception data:
    ForcedStackTraceException
    XPTO(247) 60 4 0x124A0400
    net_rim_cldc-16(4BEEF8A5)
     TextField
     getFocusRect
     0x2A61
    net_rim_cldc-12(4BEEF8A5)
     Manager
     getFocusRect
     0x717
    net_rim_cldc-12(4BEEF8A5)
     Manager
     getFocusRect
     0x717
    net_rim_cldc-12(4BEEF8A5)
     Screen
     getFocusRect
     0x9AF2
    net_rim_cldc-12(4BEEF8A5)
     Screen
     callOnExposed
     0x9D16
    net_rim_cldc-13(4BEEF8A5)
     UiEngineImpl
     <private>
     0x9007
    net_rim_cldc-13(4BEEF8A5)
     UiEngineImpl
     removeScreen
     0x7D08
    net_rim_cldc-12(4BEEF8A5)
     Screen
     close
     0x6B66
    XPTO-8(4E316B06)
     LoadingFullScreen$1
     run
     0x34D5
    net_rim_cldc-8(4BEEF8A5)
     Application
     dispatchInvokeLater
     0x1A87
    net_rim_cldc-8(4BEEF8A5)
     Application
     <private>
     0x2809
    net_rim_cldc-8(4BEEF8A5)
     Application
     processNextMessage
     0x1AEF
    net_rim_cldc-9(4BEEF8A5)
     ModalEventThread
     run
     0xBE4F
guid:0x9C3CD62E3320B498 time: Thu Jul 28 15:02:50 2011  severity:0 type:3 app:Java Exception data:
    ForcedStackTraceException
    XPTO(247) 30 2 0x139DA800
    net_rim_cldc(4BEEF8A5)
     Object
     wait
     0x9922
    net_rim_cldc-8(4BEEF8A5)
     Application
     startModalEventThread
     0x1EB8
    net_rim_cldc-13(4BEEF8A5)
     UiEngineImpl
     addScreenModal
     0x83F4
    net_rim_cldc-13(4BEEF8A5)
     UiEngineImpl
     pushModalScreen
     0x674E
    net_rim_cldc-13(4BEEF8A5)
     UiApplication
     pushModalScreen
     0x62B0
    XPTO-8(4E316B06)
     MyBaseScreen
     <private>
     0x3AA6
    XPTO-8(4E316B06)
     MyBaseScreen
     openTheModalScreenFunction
     0x382C
    XPTO-8(4E316B06)
     MyBaseScreen$4
     fieldChanged
     0x4271
    net_rim_cldc-11(4BEEF8A5)
     Field
     fieldChangeNotify
     0x160B
    net_rim_cldc-16(4BEEF8A5)
     TextField
     replace
     0x7A5
    net_rim_cldc-16(4BEEF8A5)
     TextField
     inputMethodTextChanged
     0x24E1
    net_rim_cldc-15(4BEEF8A5)
     PasswordEditField
     inputMethodTextChanged
     0x4F26
    net_rim_cldc-27(4BEEF8A5)
     IMContext
     dispatchInputMethodEvent
     0x1E00
    net_rim_tid-4(4BEEF8E1)
     SLInputMethod
     sendComposedText
     0x5CA1
    net_rim_tid-4(4BEEF8E1)
     SLInputMethod
     sendComposedText
     0x5BD1
    net_rim_tid_fastEuropean(4BEF034C)
     FastEuropeanInputMethod
     sendComposedText
     0x48E1
    net_rim_tid_fastEuropean(4BEF034C)
     FastEuropeanInputMethod
     dispatchConversionEvent
     0x43E3
    net_rim_tid-4(4BEEF8E1)
     SLInputMethod
     dispatchKeyEvent
     0x5309
    net_rim_tid-4(4BEEF8E1)
     SLInputMethod
     dispatchEvent
     0x63CA
    net_rim_tid_fastEuropean(4BEF034C)
     FastEuropeanInputMethod
     dispatchEvent
     0x426E
    net_rim_cldc-27(4BEEF8A5)
     InputContext
     dispatchEvent
     0x3E15
    net_rim_cldc-27(4BEEF8A5)
     IMContext
     dispatchEvent
     0x21DE
    net_rim_cldc-11(4BEEF8A5)
     Field
     dispatchEvent
     0x3739
    net_rim_cldc-16(4BEEF8A5)
     TextField
     dispatchEvent
     0x30F6
    net_rim_cldc-27(4BEEF8A5)
     EventHandler
     <private>
     0x1460
    net_rim_cldc-27(4BEEF8A5)
     EventHandler
     processKeyEvent
     0x1A79
    net_rim_cldc-16(4BEEF8A5)
     TextField
     processKeyEvent
     0x37F6
    net_r

EDIT 4: I have tried to move the run() method in LoadingFullScreen to a new Runnable class, as I was told that having LoadingFullScreen implement Runnable could cause problems when that class is shown as a modal screen.

However, I had no luck and I still have the same problem.

Any ideas?

EDIT 5: Solved here: BlackBerry: "Application is not responding; process terminated" because of UiApplication.getUiApplication().popScreen()?

I remember that once I had almost same kind of problem. Whenever I tried to pop screen by acquring lock of Event thread, the app would crash. SO instead of getting hold(lock) of Event thread, try synchronizing on Event thread using invokeLater().

UiApplication.getUiApplication().invokeLater(new Runnable()
{  
   public void run()
   {  

   }  
});

As none of the answers solve the problem, I am posting here the solution I reached with help from other forum (http://supportforums.blackberry.com/t5/Java-Development/Application-is-not-responding-process-terminated-because-of/m-p/1234573#M168285)

I didn't find it relevant, but it seems that the way I was calling LoadingFullScreen matters:

public void fieldChanged(Field field, int context) {
    LoadingFullScreen loading  = new LoadingFullScreen();
    System.out.println("calling pushModalScreen"); //this was showing up in logs
    UiApplication.getUiApplication().pushModalScreen(loading);
    System.out.println("pushModalScreen done"); //this wasn't showing up in logs    
}

It turns out the emulators/devices I mentioned have support for 'SureType'. "That means they do some off things when you press a key. Typically, they will attempt to display a 'choice' for the user, becuase each key has two options. becuase you are doing a pushModal in the FieldChanged method, you are blocking this. And this I think is what it is getting upset about."

So the solution was to change the way this instead:

public void fieldChanged(Field field, int context) {
    if ( context != FieldChangeListener.PROGRAMMATIC ) {
        UiApplication.getUiApplication().invokeLater(new Runnable() { 
            public void run() {
                LoadingFullScreen loading  = new LoadingFullScreen();
                UiApplication.getUiApplication().pushModalScreen(loading);          
            }
        }
    }
}

Assuming smth is wrong (assuming there's a RIM bug) with UiApplication.getUiApplication().popScreen() here is just an idea to try:

Instead of UiApplication.getUiApplication().popScreen(active); try to call active.close().

i believe this is because ui thread and ur thread created are not communicating properly. you can use this following code.

UiApplication.getUiApplication().invokeLater(new Runnable()
{  
   public void run()
   {  

   }  
});

I was having similar strange issues with a popup screen I implemented. It turned out that I had 2 different methods trying to pop the screen at the same time. This led to the error.

I ended up creating a static helper method that I now use to close my screens, which checks if the screen is actually displayed before closing it.

Posted here in case it helps someone:

/**
 * Convenience method to request a screen to close & pop it from the display
 * stack. This method handles the UI threading issues.
 * 
 * @param screen
 *        {@link Screen} to be closed.
 */
public static void closeScreen(final Screen screen)
{
    UiApplication.getUiApplication().invokeLater(new Runnable()
    {

        public void run()
        {
            if (screen.isDisplayed())
            {
                screen.close();
            }
        }
    });
}

I have experienced something similar to this. I have a callback (invoked from another thread) in which processing happens, and informs the user of the indication of processing via Status and was using code like this:

UiApplication.getUIApplication.invokeLater(new Runnable(){
   public void run(){
     Status.show("....");
   }
});

And was getting near identical errors as the OP.

I realized then, because the callback was being executed multiple times, ALL of those Runnables were being queued up and hence "Too many threads" followed by a nice crash!

The solution:

UiApplication.getUIApplication.invokeAndWait(new Runnable(){
   public void run(){
     Status.show("....");
   }
});

That will block until the event queue gets cleared making way for more Status showing up.

Since its on a thread, it does not matter and thus a nice compromise.

End result: No more nasty crashes and no spurious messages in the event log.

To the OP: You may have to restructure slightly how you're informing the end user on notification of processing the UI logic in order not to exhaust the threading pool.

BTW, it should be noted - this is on BB 4.5 :)