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


Thank you for visiting the BlackBerry Support Community Forums.

BlackBerry will be closing the BlackBerry Support Community Forums Device Forums on April 1st (Developers, see below)

BlackBerry remains committed to providing excellent customer support to our customers. We are delighted to direct you to the CrackBerry Forums, a well-established and thorough support channel, for continued BlackBerry support. Please visit http://forums.crackberry.com or http://crackberry.com/ask. You can also continue to visit BlackBerry Support or the BlackBerry Knowledge Base for official support options available for your BlackBerry Smartphone.

"When we launched CrackBerry.com 10 years ago, we set out to make it a fun and useful destination where BlackBerry Smartphone owners could share their excitement and learn to unleash the full potential of their BlackBerry. A decade later, the CrackBerry community is as active and passionate as ever and I know our knowledgeable members and volunteers will be excited to welcome and assist more BlackBerry owners with their questions."

- Kevin Michaluk, Founder, CrackBerry.com

Developers, for more information about the BlackBerry Developer Community please review Join the Conversation on the BlackBerry Developer Community Forums found on Inside BlackBerry.


Reply
Developer
Posts: 41
Registered: ‎09-11-2009
My Device: Not Specified
Accepted Solution

Creating a Separate Thread

I need to know how to run a thread along side my GUI thread.  Right now I have a GUI app and what I need is a thread that will start when the GUI does and will accept incoming messages (from a TCP socket) and for the time being just display the message once it's reacieved in a dialog window in the GUI.

 

I already understand what I need to do with regard to the socket business, so mainly my question is this: How do I create a thread that A) starts when my GUI does and B) can create a pop-up message in the GUI from time to time?

 

(the thread should also quit when the GUI quits)

Developer
Posts: 562
Registered: ‎09-30-2009
My Device: Not Specified

Re: Creating a Separate Thread

Have you looked at java.lang.Thread?

 

 

Developer
Posts: 41
Registered: ‎09-11-2009
My Device: Not Specified

Re: Creating a Separate Thread

I have, but I'm not exactly sure where to start it.  Should I start the thread after I have sent my GUI app to the Event Dispatcher like this?

 

 

public class MyApp extends UiApplication{
        
    public static void main(String [] args){                
        MyApp theApp = new MyApp();
        
        SomeRunnable runnable = new SomeRunnable();
        Thread theThread      = new Thread(runnable);
        
        theApp.enterEventDispatcher();
        theThread.start();      
        
    }
        
    public MyApp(){
        //display error screen
        pushScreen(new SomeScreen());       
    }        
}

 

 

Developer
Posts: 19,636
Registered: ‎07-14-2008
My Device: Not Specified

Re: Creating a Separate Thread

If you want your Thread to update Screen, then it needs to know about the Screen, so I don't think what you have here is what you want.

 

Instead, let us say that you have a RichTextField and you will dump whatever comes in from the Thread into it.  So in your Constructor of your Screen you will create this RichTextField, and then you will create and start your Thread, and pass in to this Thread, the RichTextField that this Thread will update.  Then, whenever the Threads gets something it wants to display, it can just obtain the Event Lock and update the Field.

 

This will work, but the recommended approach is to use the Observer pattern.  And the Thread will notify the Screen of changes that it thinks it might be interested in.  Have a look at the Observer Pattern for more.

Highlighted
Developer
Posts: 131
Registered: ‎08-13-2008
My Device: Not Specified

Re: Creating a Separate Thread

If you read the API it will tell you that enterEventDispatcher() does not return. So no, you never put anything underneath it.

If anything, the thread can be started by the GUI (in the constructor of MyApp?)

Developer
Posts: 41
Registered: ‎09-11-2009
My Device: Not Specified

Re: Creating a Separate Thread

Well the GUI app has many screens that the user will be able to navigate through and if a message comes in I need the message to show up in a pop up dialog regardless of what screen the user currently has open.  Couldn't a thread have a function like the following that could perform that task properly?

 

 

public void alert(final String message){
        UiApplication.getUiApplication().invokeLater (new Runnable(){
                                                           public void run(){
                                                               Dialog.alert(message);  
                                                           }});
}

 

But there are some messages that may affect a particular screen's field so an Observer Pattern would be useful.  Could you point me in the direction of any good tutorials regarding the topic?

 

Developer
Posts: 300
Registered: ‎03-12-2009
My Device: Not Specified

Re: Creating a Separate Thread

Just worked on something like this last night. peter_strange pointed me in the right direction.

 

 

	/**
* Process the results of some time-consuming operation.
*/
public void populateList(Object o_name)
{
// update your screen here, field managers, whatever
}

/**
* Start a thread to carry out time-consuming work in a
* separate thread and deliver the results back in the
* event dispatching thread.
*/
public void launchWork()
{
new Thread()
{
public void run()
{
//
final Object res = Stuff();

Runnable r = new Runnable()
{
public void run()
{
// run the populate list after the connection is made
populateList(res);
}
};

Application.getApplication().invokeLater(r);
}

/**
* Do time-consuming work in this method
*/
private Object Stuff()
{
// do **bleep** here

return Object;
}

}.start();
}

 

 

Developer
Posts: 562
Registered: ‎09-30-2009
My Device: Not Specified

Re: Creating a Separate Thread

If there's one screen that is always shown when the application is started, when you start the thread from that screen, it will remain regardless of what screens you put in front of it (just make sure you control how many threads you spawn, so you don't create more than you need).

 

The other option is starting your thread before you enter enterEventDispatcher (I think that would work too.)

Developer
Posts: 41
Registered: ‎09-11-2009
My Device: Not Specified

Re: Creating a Separate Thread

I started my thread after enterEventDispatcher() and it is behaving like I want it to.  I didn't know that nothing after enterEventDispatcher() was executed, so that helped out a lot.

 

My thread has an ongoing loop that will either A) create a pop-up message or B) store the message's contents in a global variable (depending on the message's type).  Since I have it displaying the pop-up windows ok I think my problem is solved for now.

 

One last question: Will the thread be killed when the GUI app is closed if I started the thread on the line before "enterEventDispatcher()" ?

 

Thanks for the help!

Developer
Posts: 19,636
Registered: ‎07-14-2008
My Device: Not Specified

Re: Creating a Separate Thread

Threads are owned by the application not the Screen that started them.  The Thread will be killed if you do a

System.exit(..);

regardless of when you start it.

 

The major reason for my suggesting that you start the Thread in the Constructor of a Screen was so that it was easy to give the Thread a handle on something that it could update.  If you are just displaying popup messages, that is irrelevant, and it doesn't matter when you start your Thread. 

 

I'm a little concerned about this statement:

"store the message's contents in a global variable"

Global to what?

I would recommend that you create a properly synchronized Vector, either in PersistentStore (if you want the messages to be retained over restarts) or in RuntimeStore, have your thread add elements to this, and have your processing remove from this.  Do this properly from the start, it will save you grief in the long run.