If you are using Internet Explorer, please remove blackberry.com from your compatibility view settings.

Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

Reply
Developer
spookendiesel
Posts: 27
Registered: ‎07-17-2008
My Device: Not Specified

Re: Dialog.ask() in background thread crashes app on Bold simulator

Yeah, I'm afraid it does.

 

Regards,

 

Joanna

Please use plain text.
Administrator
MSohm
Posts: 14,362
Registered: ‎07-09-2008
My Device: BlackBerry Z30, BlackBerry PlayBook
My Carrier: Bell

Re: Dialog.ask() in background thread crashes app on Bold simulator

I haven't been able to reproduce this when the Dialog.ask is wrapped in an invokeLater block.  Can you post updated source code for your thread that triggers the exception?
Mark Sohm
BlackBerry Development Advisor

Please refrain from posting new questions in solved threads.
Problem solved? Click the Accept As Solution button.
Found a bug? Report it using Issue Tracker
Please use plain text.
Developer
spookendiesel
Posts: 27
Registered: ‎07-17-2008
My Device: Not Specified

Re: Dialog.ask() in background thread crashes app on Bold simulator

[ Edited ]

This is a simplified version of the original code which does work in the 4.2.1 JDE simulator (and devices) but doesn't work in the 4.6.0 JDE simulator.  I have played around with this sample and have found that moving the line of code highlighted in red has resolved my issue. 

 

I don't know why this is happening though and why it worked previously, but not when using the 4.6.0 JDE simulator.  Any ideas?

public class ScrSplash extends MainScreen { public ScrSplash() { // Start a background thread to do some processing whilst the screen is being displayed Thread tBackground = new Thread(new BackgroundThread()); tBackground.start(); } protected void paint(Graphics gGraphics) { // Code to draw the application logo (removed for clarity) } private void dismiss() { try { synchronized(UiApplication.getEventLock()) {

// We want to remove this screen from the display stack // as we don't want to let the user see it when exiting the app UiApplication.getUiApplication().popScreen(this); Application.getApplication().invokeLater ( new Runnable() { public void run() { if (Dialog.ask(Dialog.D_YES_NO, "The application was last closed in offline mode. Do you wish to continue working offline?", Dialog.NO) == Dialog.YES) { // Push the offline menu screen onto the display stack UiApplication.getUiApplication().pushScreen(new ScrOfflineMenu()); } else { // Push the login screen onto the display stack UiApplication.getUiApplication().pushScreen(new ScrLogin()); } } } ); } } catch (Exception ex) { // Code to display the error message (removed for clarity) } } private class BackgroundThread implements Runnable { public void run() { try { // Just so that splash screen is displayed long enough for user to see Thread.sleep(2000); } catch (InterruptedException ie) { } // Code for background processing (removed for clarity) // Now we have finished processing we can move to the next screen dismiss(); } } }

 

Here I have moved the popScreen method inside the invokeLater method.  This version doesn't work in the 4.6.0 JDE.

 

public class ScrSplash extends MainScreen { public ScrSplash() { // Start a background thread to do some processing whilst the screen is being displayed Thread tBackground = new Thread(new BackgroundThread()); tBackground.start(); } protected void paint(Graphics gGraphics) { // Code to draw the application logo (removed for clarity) } private void dismiss() { try { final ScrSplash scr = this; synchronized(UiApplication.getEventLock()) { Application.getApplication().invokeLater ( new Runnable() { public void run() { // We want to remove this screen from the display stack // as we don't want to let the user see it when exiting the app UiApplication.getUiApplication().popScreen(scr); if (Dialog.ask(Dialog.D_YES_NO, "The application was last closed in offline mode. Do you wish to continue working offline?", Dialog.NO) == Dialog.YES) { // Push the offline menu screen onto the display stack UiApplication.getUiApplication().pushScreen(new ScrOfflineMenu()); } else { // Push the login screen onto the display stack UiApplication.getUiApplication().pushScreen(new ScrLogin()); } } } ); } } catch (Exception ex) { // Code to display the error message (removed for clarity) } } private class BackgroundThread implements Runnable { public void run() { try { // Just so that splash screen is displayed long enough for user to see Thread.sleep(2000); } catch (InterruptedException ie) { } // Code for background processing (removed for clarity) // Now we have finished processing we can move to the next screen dismiss(); } } }

 

Here I moved the popScreen method to the end of the invokeLater method.  This version does work in the 4.6.0 JDE.

 

public class ScrSplash extends MainScreen { public ScrSplash() { // Start a background thread to do some processing whilst the screen is being displayed Thread tBackground = new Thread(new BackgroundThread()); tBackground.start(); } protected void paint(Graphics gGraphics) { // Code to draw the application logo (removed for clarity) } private void dismiss() { try { final ScrSplash scr = this; synchronized(UiApplication.getEventLock()) { Application.getApplication().invokeLater ( new Runnable() { public void run() { if (Dialog.ask(Dialog.D_YES_NO, "The application was last closed in offline mode. Do you wish to continue working offline?", Dialog.NO) == Dialog.YES) { // Push the offline menu screen onto the display stack UiApplication.getUiApplication().pushScreen(new ScrOfflineMenu()); } else { // Push the login screen onto the display stack UiApplication.getUiApplication().pushScreen(new ScrLogin()); } // We want to remove this screen from the display stack // as we don't want to let the user see it when exiting the app UiApplication.getUiApplication().popScreen(scr); } } ); } } catch (Exception ex) { // Code to display the error message (removed for clarity) } } private class BackgroundThread implements Runnable { public void run() { try { // Just so that splash screen is displayed long enough for user to see Thread.sleep(2000); } catch (InterruptedException ie) { } // Code for background processing (removed for clarity) // Now we have finished processing we can move to the next screen dismiss(); } } }

 

Message Edited by spookendiesel on 09-24-2008 05:55 AM
Message Edited by spookendiesel on 09-24-2008 05:56 AM
Please use plain text.
Administrator
MSohm
Posts: 14,362
Registered: ‎07-09-2008
My Device: BlackBerry Z30, BlackBerry PlayBook
My Carrier: Bell

Re: Dialog.ask() in background thread crashes app on Bold simulator

Is the screen you are popping the only one displayed within your application?  Or is there another screen under it?  If not, calling UiApplication.getUiApplication after popping your one and only screen on the stack attempts to get the instance of another application, not the one you are running (whatever application is lower on the display stack from your screen).

 

A few other comments.

 

1.  There is no need to synchronize on the event lock here.

2.  You can call scr.close instead of getting the UiApplication and popping the screen.

Mark Sohm
BlackBerry Development Advisor

Please refrain from posting new questions in solved threads.
Problem solved? Click the Accept As Solution button.
Found a bug? Report it using Issue Tracker
Please use plain text.
Developer
spookendiesel
Posts: 27
Registered: ‎07-17-2008
My Device: Not Specified

Re: Dialog.ask() in background thread crashes app on Bold simulator

Hmmm, ok I understand what you are saying about the display stack and it does make sense, but I still don't understand why this code worked on previous simulators and devices but not the 4.6.0 JDE. 

 

Anyway I have moved the problematic line of code to the end of the method which seems to work.

 

With regards to the synchronization on the event lock, you're right, it shouldn't have been in the sample I posted (I forgot to take it out), but it is necessary in my code as I'm doing some extra functions not shown in the code sample above.

 

Thanks for mentioning the close method though.  I don't know why I chose to do it by accessing the UIEngine, but the close method works just fine. :-)

Please use plain text.
New Developer
Lioni
Posts: 3
Registered: ‎10-16-2008
My Device: Not Specified

Re: Dialog.ask() in background thread crashes app on Bold simulator

although it seems a little bit late to add something to this thread (20 days after the last post) i had a simmilar problem and thought i might be of any help for the next one who read this

 

i had the following code:

 

final class SomeApp extends UiApplication
{

public static void main(String[] args)
{
SomeApp theApp = new SomeApp();
theApp.enterEventDispatcher();
}

SomeApp()
{
UiApplication.getUiApplication().invokeLater(new Runnable()
{
public void run()
{
if( Dialog.ask(Dialog.D_YES_NO, _resources.getString(SomeResourceID), Dialog.YES) == Dialog.NO )
System.exit(0);

initializeTheApp();

}
}
}

private void initializeTheApp()
{
// here i push some screens an do other thigs needed on the app startup

pushScreen(someScreen);

//....

}

// other code ...

} // class SomeApp

 

 

 as Joanna says it works fine on 8800 (for instance) and doesn't work on 9000.

it just exits the application no matter what the user answer to the Dialog and never reaches initializeTheApp(); line. no matter if the "if"evaluates true or false.

 

at first i was puzzled, but than i thought a little and it seems there's some logic in it.

since i haven't yet found a way to draw any UI before enter the EventDispatcher (if somebody knows something about it please tell me) i have to use "invokeLater(...)". only RIM knows the way the EventDispatcher works, but the most logical thing is to count the number of the screens on the stack and if they reduce back to 0 to try to close the application because there's no one to dispatch the events to.

 

since the dialog box is the first screen for this application when it's closed there's no more screens left and the framework tries to close the application.

apparently in 9000 this process doesn't wait for the event thread (that called the invokeLater()'s run() method) to finish it's job and closes the app as soon as it can, whitch is right after the user closes the Dialog and doesn't wait for the other screens that would have being opened in initializeTheApp() function.

once again - the line

    initializeTheApp();

is never reached.

 

perhaps that's a bug introduced in the new OS (or maybe there's an idea that i can't get)

 

with that in mind the workarownd  seemd obvious:

push a temporary screen whitch "wraps" the gap between closing of the dialog and pushing the app screens in initializeTheApp() and pop it out when the application screens are allready pushed so the screenn count never riches 0.

it worked fine. next code works ok on 4.6 and the prvious OSes.

 

 

final class SomeApp extends UiApplication
{
public static void main(String[] args)
{
SomeApp theApp = new SomeApp();
theApp.enterEventDispatcher();
}

SomeApp()
{
UiApplication.getUiApplication().invokeLater(new Runnable()
{
public void run()
{
FullScreen tempFS = new FullScreen();
UiApplication.getUiApplication().pushScreen(tempFS);

if( Dialog.ask(Dialog.D_YES_NO, _resources.getString(SomeResourceID), Dialog.YES) == Dialog.NO )
System.exit(0);

initializeTheApp();

UiApplication.getUiApplication().popScreen(tempFS);
}
}
}

private void initializeTheApp()
{
// here i push some screens an do other thigs needed on the app startup

pushScreen(someScreen);

//....
}

// other code ...

} // class SomeApp

 

 Joanna's case seems simmilar - when she pops the screen before the dialog when the dialog is closed there's a problems. i don't know what she meens by "doesn't work", but lots of problems may occur if an application whitch you think is running actually is stopped, so it doesn't matter. when she pops the screen after another screen is allready pushed in the stack there's no problems.

 

i guess some of the BlackBerry gurus can throw more light on the framework behaviour

 

(excuse my english since it's far from being my native tongue, and i hope that workarownd will help... somebody :smileyhappy:  )

 

Emil

Please use plain text.