Skip to main content

Handling LWUIT Dialogs created by a background thread

2 replies [Last post]
Joined: 2012-12-14

I have written an application in LWUIT targeted for a J2ME phone (Sprint DuraXT). The application is for pickup and delivery van drivers. It receives dispatches from a back-end dispatching system that describe pickups and delivers the driver must make. As the drivers, execute the pickups and deliveries, the driver enters status information that is sent back to the dispatching system.

Now, during the processing of a pickup or delivery, the driver may be presented with error dialogs (incorrect field entry), yes/no confirmation dialogs (confirming some action) and information dialogs (indicating some status the driver should be aware of).

In addition, there is a background thread listening for dispatches coming from the back-end server. In the current implementation, this background thread can also create yes/no confirmation dialogs and information dialogs. These dialogs are more like an alert as they have an associated sound, but they are simply dialogs.

As long as these two dialogs do not occur

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2011-09-05

hi, you could actually create dialogs 'off' the edt iff you wish.
All you need do is ensure that the show() is synced on the edt.
used to xperience the race condtion before also, before i realised
a better way of handling it.
if u create a dialog in a separate thread, ensure that any of its show
method you call is synced with the edt.
you call sync anything on a separte thread with the edt by calling
lwuit callSerially() found on display.getInstance() class and
wrapping the action in its run method.

so generally I wud say;
you just need to sync on the edt when you show or change a current showing ui.
I would say every method that you expect to change something on the UI you are currently viewing.
for example:
if you have a Label on screen calling setText on that Label should be synced, if the Label is not currently on screen it doesn't matter.

Joined: 2012-12-14

I actually hit upon the solution you suggested after a bit of experimentation. I was happy to have you confirm it. I my case, the actions are more complicated than simple Dialogs and I found I had to wrap the whole action in a class which implements the Runnable interface. As you suggested, I run this via Display.getInstance().callSeriallyAndWait(runnable).

So others may benefit from this discussion, here is a example of one of these classes with the action embedded in the run method.

   private class CancelOrder implements Runnable {

        private KWMap order;

        public CancelOrder(KWMap order) {
            this.order = order;

        public void run() {
            String orderNum = getString(order, OrderTable.ORDER_NUM);
            if (legStatusTable.isOrderStarted(orderNum)
                    && !orderTable.isOrderComplete(order)) {
                String msg = "You received a cancellation message for Order "
                        + orderNum
                        + " which has been started but is not finished."
                        + "\nDo you want to keep it?";
                if (app.yesNoDialog(msg, "Yes", "no")) {
                    sendCancelResponse(order, "Yes", "");
                } else {
                    sendCancelResponse(order, "No", "");
            } else {
                // order has neither been started nor completed.
                sendCancelResponse(order, "Yes", "");
                app.alertDialog("Dispatcher cancelled Order "
                        + orderNum);

The key thing here is that the action contains logic depending on how a user responds to a yes/no Dialog and there are operations on an underlying database and messaging subsystem as well. Except for the Dialogs, nothing in this action blocks the EDT for more than a few 100s of milliseconds, so the application runs very smoothly.

Thanks for suggesting and confirming this approach