用Java编写自己的事件的正确方法是什么

Question

I'm student and I'm working on project with few of my friends. My task is to make something like class library. Classes in this library should provide API for my friend who must make GUI part of application. GUI could be made by any toolkit (Swing, JavaFX, SWT, AWT, all should work, in fact, it should work even if there is no GUI). I need to make class that waits for data to arrive from network. I don't know when data will arrive, and UI must be responsive during waiting, so I put that in different thread. Now problem is how to make GUI respond when data arrive. Well, I tought that this is asynchronous event and GUI should register event handlers, and I should call that methods when event happens. I proposed this solution:

interface DataArrivedListener{
    void dataArrived(String data);
}

class Waiter{
    private DataArrivedListener dal;
    public void setDataArrivedListener(DataArrivedListener dal){
        this.dal = dal;
    }

    void someMethodThatWaitsForData(){
        // some code goes here

        data = bufRdr.readLine();

        //now goes important line:

        dal.dataArrived(data);

        // other code goes here

    }


}

My question is: Should I replace "important" line with something like this:

java.awt.EventQueue.invokeLater(new Runnable(){
    @Override
    public void run(){
        dal.dataArrived(data);
    }
});

Or something like:

javafx.Platform.runLater(new Runnable(){
    @Override
    public void run(){
        dal.dataArrived(data);
    }
});

Or maybe I should do something completely different?

Problem is that I'm not sure which of this will work for any type of UI. If it's GUI, dataArrived() could potentialy make changes to GUI and no matter what type of GUI it is, this changes should be drawn on screen properly. I also think that it is better if I do "invoke this code later" so that my someMethodThatWaitsForData() method could trigger event and continue on with it's on work.

I appreciate your help.

Answer 1

Here's an Event Listener article I wrote a while back. The article explains how you write your own event listeners.

You're correct in that you want to write your own event listeners if you want your library to work with any GUI.

I'm most familiar with Swing, so yes, you'll have GUI code that looks like this:

button.addActionListener(new ActionListener(){
    @Override
    public void actionPerformed(ActionEvent event){
        dal.buttonPressed(data);
    }
});

Answer 2

If you want it to be completely agnostic to what GUI is being used the only real solution is to let the receiver handle it in dataArrived . Since every toolkit has its own implementation all you can really do to make it work with any toolkit is to disregard it. Otherwise what you will actually end up with is a list of "supported toolkits" and a case for each one.

If you just want dataArrived to be executed away from someMethodThatWaitsForData then you could make your own dispatch thread or make a new thread each time.

Answer 3

If you want to be truly independent of any front-end system, I would recommend creating two threads. The first is your Waiter , which will just listen for events and put them into a Queue of some sort (see the "All Known Implementing Classes" section). The second will invoke the data listener or listeners whenever the queue is not empty.

Answer 4

The concept of invoking a Runnable in the background is kind of deprecated since the invention of the concurrent package. The main reason that this was done in earlier days, is that the GUI code needs to be executed in a different thread, to guarantee that it stays responsive, even if the main thread is busy doing some calculations, but actual multi-threading was still in its very early days. The resulting invokeLater concept works, but comes with a strong creation overhead. This is especially annoying if you frequently have to do minor things, but each time you need to create an entire new Runnable, just to get that event into the Swing thread.

A more modern approach should use a thread-safe list, like a LinkedBlockingQueue. In this case any thread can just throw the event into the queue, and other listener/GUI-Event-handlers can take them out asynchronously, without the need of synchronization or background Runnables.

Example:

You initialize a new Button that does some heavy calculation once it is pressed.

In the GUI thread the following method is called once the button is clicked:

void onClick() {
  executor.submit(this.onClickAction);
}

Where executor is an ExecutorService and the onClickAction a Runnable. As the onClickAction is a Runnable that was submitted once during Button creation, no new memory is accessed here. Let's see what this Runnable actually does:

void run() {
  final MyData data = doSomeHeavyCalculation();
  dispatcher.dispatch(myListeners, data);
}

The dispatcher is internally using the LinkedBlockingQueue as mentioned above (the Executor uses one internally as well btw), where myListeners is a fixed (concurrent) List of listeners and data the Object to dispatch. On the LinkedBlockingQueue several threads are waiting using the take() method. Now one is woken up as of the new event and does the following:

while (true) {
  nextEvent = eventQueue.take();
  for (EventTarget target : nextEvent.listeners) {
    target.update(nextEvent.data);
  }
}

The general idea behind all this, is that for once you utilize all cores for your code, and in addition you keep the amount of objects generated as low as possible (some more optimizations are possible, this is just demo code). Especially you do not need to instantiate new Runnables from scratch for frequent events, which comes with a certain overhead. The drawback is that the code using this kind of GUI model needs to deal with the fact that multi-threading is happening all the time. This is not difficult using the tools Java gives to you, but it is an entire different way of designing your code in the first place.