CODEWITHSUNDEEP
javamultithreadingswingconcurrencyevent-listener
Johnydep
Johnydep

Reputation: 6277

making efficient implementation of this Java MouseListener Logic

I have a MouseListener Thread where this method is called each time there is a click: 

public void mousePressed(MouseEvent event){

    //my Logic here

}

Now what happens is that there are so many clicks in little time, while my logic here, takes more time to process. What i was expecting is that further clicks will be discarded and this method will continue on the latest upcoming clicks.

But what is happening that while the logic is processing, the incoming clics are queued and even when clicking is stopped, qued clicks keep calling this mousePressed method, as a result i have multiple delayed executions.

Unfortunatelly i do not have control over the Listener (why it ques and keep sending delayed clicks), so in such a scenario, can you tell me what is the efficient way of handling such that i do not make a que due to delay in my processing.

I think the most obvious way would be using another thread, but i am wondering this might trigger so many threads in little time, or is there any way i can lock just one thread while the rest of clicks just go through empty loop?

Upvotes: 3

Views: 866

Answers (2)

Philipp Wendler
Philipp Wendler

Reputation: 11433

One solution would be to access the component on which the user clicked and disable it during the processing of the MouseListener. This way it doesn't accept new clicks. This would have the additional benefit of giving the user visual feedback that he is not supposed to click on the component at this time.

You can access the component through the MouseEvent:

public void mousePressed(MouseEvent event) {
  event.getComponent().setEnabled(false);
  try {

    // ....

  } finally {
    event.getComponent().setEnabled(true);
}

In general though you shouldn't do too much computation in the Swing event listener thread, because Swing also needs it for processing other events and painting. You should use separate Threads for doing actual work and just start them in the MouseListener. You can also use an ExecutorService to simplify this. It would still be a good idea to disable the gui component during the whole computation in order to give the user feedback.

Edit: This solution of course depends on Swing. Any similar solution depends on the details of your GUI library, so if you use your own GUI library, you are one your own.

You can of course use a general solution involving separate threads for doing the work. I really recommend an ExecutorService here, were you don't need to care about the details and just submit tasks to execute. You can then have a simple volatile boolean variable which indicates whether the action is currently being executed and new clicks should be ignored.

Upvotes: 1

calebds
calebds

Reputation: 26228

Updates: See Phillip's comments as to why this doesn't work for Swing!

It's unfortunate that you don't have access to the eventListener. The ideal solution would be to unregister the callback while it is being executed.

Here's a solution that emulates unregistering the callback function while it is being executed, assuming you want queued clicks to go away:

private AtomicBoolean engaged = new AtomicBoolean(); // thread-safe boolean

public void mousePressed(MouseEvent event){
    if (!engaged.get()) {
        engaged.set(true);

        // your logic here

        engaged.set(false);
    }
}

The AtomicBoolean acts as a test-and-set lock preventing multiple threads concurrently running the pressed event callback. Queued presses will be dissipated during the lock.

Upvotes: 2

Related Questions