Re: Need guidance using threads for a barcode scanner application
On 11/9/2012 3:17 PM, kedward777@gmail.com wrote:
Hello,
Thank you for any help you can provide!
I am writing a simple java mobile application that runs on a handheld motrola bar code scanner using java 1.4 (NSI CrEME CDC).
Aside: That's a very old Java version, released almost eleven
years ago. Perhaps more importantly, support and security updates
for 1.4 ceased four years ago. Perhaps even more importantly, the
people who might try to help you have probably lost touch with antique
versions, and may inadvertently offer advice that will only confuse
matters. Get a newer Java if you can -- and if the device only has
an antique Java, well, that's life. Just be aware of the issue, and
don't believe everything we modernists tell you ...
I used the motorola sample program to successfully run on the scanner. When the user presses the trigger, the laser scans and displays the item code in a text area widget. BUT, the example is written such that it runs directly on the the initial thread, as represented below:
public static void main(String argv[]){
(new J_ScanSample1()).go();
}
public synchronized void go(){
createDisplay();
while (!exiting){
if (!stopScanning)
{scanner.read(null, this);}
}
After googling, I seem to believe I need to create the GUI in a runnable object, and then create the scanner background process in another runnable object, but could someone briefly give an example how I would do this? I think I launch the GUI as shown below, but then do I just set the scanner process in another runnable object? How does the GUI get updated after the scanner reads in data?
public static void main(String args[]) {
java.awt.EventQueue.invokeLater(new Runnable() {
public void run() {
new ScannerApp().setVisible(true);
}
});
}
Aside: Is there a reason you need to use "bare" AWT instead
of using Swing? It's been a l-o-n-g time since I did a non-Swing
GUI, and I've forgotten most of what I once knew about it.
In either Swing or AWT, the GUI objects should only be
manipulated by the thread that processes the event queue, because
most GUI objects are not thread-safe. This creates a conflict,
because activities on that thread should be brief: While they're
in progress, the GUI can't respond because the only thread that
dares touch the GUI is busy doing those activities. Long-running
tasks shouldn't run on the event thread lest they freeze the GUI,
and tasks running on other threads mustn't touch the GUI. What's
a programmer to do?
That's where invokeLater() and invokeAndWait() come in. You
launch the long-running task on a non-GUI thread, and when it
needs to report progress or results by changing the GUI, *it*
calls invokeXxx(). AWT or Swing will eventually execute the
invoked Runnable on the GUI's event thread, where it can safely
turn buttons red or whatever. The long-running task never touches
the GUI itself; it "sends an emissary" to do the dirty (and brief)
work. So:
- GUI or timer or whatever starts a long-running task,
launching it in a non-GUI thread.
- Each time the task wants to change the GUI (to report a
result, or update a progress indicator, or whatever), it
packages the update action in a Runnable and uses one of
the invokeXxx() methods.
- Some (usually short) time after invokeXxx(), the Runnable
executes on the GUI's thread and makes its updates.
- Meanwhile, the long-running task may have finished, or may
have kept chugging along, or may have waited for the GUI
to be updated before proceeding.
The pattern you've shown (it's similar for Swing) ensures
that the GUI objects are built on the event thread, which is
a Really Good Idea since building an object is a fairly extreme
case of "manipulating" it. Sun themselves didn't fully appreciate
this issue, and some early documentation shows GUI's being built
right from main(). Don't Do That: Use an invokeXxx() method
and build your GUI in AWT's or Swing's own thread.
Even in Java 1.4 you've got that much capability, with AWT
methods or with the SwingUtilities class. In 1.6 you've also got
SwingWorker, which is helpful for common patterns like "GUI button
launches long-running task, which eventually finishes and displays
results in the GUI."
There's some helpful stuff at
http://docs.oracle.com/javase/tutorial/uiswing/concurrency/index.html
.... although it's about Swing rather than unaided AWT. Also, the
version skew since Java 1.4 may be a bit wrenching ...
--
Eric Sosman
esosman@comcast-dot-net.invalid