Trigger main thread method from secondary thread?

Okay, I have a program, and it needs to connect to a very, very laggy server to get data. Without threading, the entire UI will hang during this lag. So, I've made threads that grab the data, and put said data into variables the entire program can access.

However, I have a dilemma. Once that data is stored, the program must do things with it. However, it can not do said things from the secondary thread, and the main thread can not sit around waiting for the data to be ready for any length of time.

As an analogy, if you have any kind of email notification popup anywhere, think of the email system as a secondary thread and whatever you do throughout the day as the main thread. You certainly don't sit around and do nothing waiting for an email, but when you see the popup, you run the appropriate method (ie. go check your email).

The best solution I see is if the thread, after moving data where it has to go, could send some sort of trigger - very, very much like a button press - that would alert the main thread to divert into a processing method.

The most obvious (if perhaps unorthodox) way to accomplish this would be to actually create some form of action event and trigger it from the thread, but as best I can tell, that specifically requires calling actionPerformed(), and any method called from a thread is apparently run inside the thread its self, which would be bad.

Does anyone have any application-independent advice on this?

Is this a Swing application and is the background thread a SwingWorker? If so then a simple solution is to add a PropertyChangeListener to the SwingWorker and wait for the state property to change to DONE.

If not a SwingWorker, then do the same thing on your own (which you discussed above), use a listener, otherwise known as the Observer Pattern.

Interesting. Technically, yes, this involves Swing, but I don't think the background thread is a Swingworker. A thread retrieves and arranges data into a String, and the main processing thread is expected to use setText() to put that String into a JEditorPane. If the setText() is run directly from the thread, autoscroll in the JEditorPane fails for no apparent reason, and there are other issues.

Of course, some of these threads go beyond just setting text, and invoke other methods that I would prefer not be in secondary threads. I am familiar with action listeners and hyperlink listeners; can I make my own? Do you have any links (or good search terms) for how to do that?

Sure you can make your own. Shoot, you could just give your background thread a change listener, but just be sure to call stateChanged from within the thread on the EDT only. The main resource I've used for this (and pretty much all Swing coding) is two fold.

For Swing Listeners, this series of tutorials: Writing Event Listeners

and for Swing concurrency, this: Concurrency in Swing

I see the part about change listener. Does that extend beyond Swing objects? For example, could I have a change listener attached to a boolean? Thread sets (or otherwise "changes") the boolean after the data is ready, main thread picks it up much like a button press, and knows it's time to work with the data?

Quote:

---

Originally Posted by DigitalMan

I see the part about change listener. Does that extend beyond Swing objects? For example, could I have a change listener attached to a boolean? Thread sets (or otherwise "changes") the boolean after the data is ready, main thread picks it up much like a button press, and knows it's time to work with the data?

---

You can't attach anything to a primitive, be it a boolean or an int. ChangeListeners are added to objects only, and the class needs to have a public method, usually addChangeListener(ChangeListener cl), that allows you to add it.

And sorry for being picky, but "Threads" don't set anything. Objects can change variables or states within threads, but it's the objects themselves that are doing the changing.

Also, have you considered using a SwingWorker as your background thread here? They can be quite useful in this situation you know.

Okay then. Say I wanted something - primitive, higher object, whatever it takes - to modify from a thread, so that a change listener or similar listener would be triggered on a different thread (the primary execution one). What would you recommend?

Also, SwingWorkers seem like something too deep to get into at the moment. And not all my threads are Swing-related.

If Swing, I would use a SwingWorker since they really aren't all that difficult to deal with and have all of the stuff you need already rolled up in them. If not Swing then I'd just create a simple Observer Pattern type listener. I'm not too crazy about Java's ready-made Observer/Observable since whatever is the Observable must subclass the Observable class rather than implement an interface. I usually just roll my own interfaces and use them.