Handling Events with Listeners

    By far the easiest and the most common way to handle events in Java 6 and 7 is to use anonymous local classes. It encapsulates the handling of events to where the component is defined and does not require cumbering the managing class with interface implementations. The following example defines an anonymous class that inherits the Button.ClickListener interface.

    Java

    See the on-line example.

    Local objects referenced from within an anonymous class, such as the Button object in the above example, must be declared final.

    Most components allow passing a listener to the constructor, thereby losing a line or two. However, notice that if accessing the component that is constructed from an anonymous class, you must use a reference that is declared before the constructor is executed, for example as a member variable in the outer class. If it is declared in the same expression where the constructor is called, it doesn’t yet exist. In such cases, you need to get a reference to the component from the event object.

    Java

    2.   new Button.ClickListener() {
    3.     @Override
    4.     public void buttonClick(ClickEvent event) {
    5.         event.getButton().setCaption("Done!");
    6.     }
    7.   });

    Java 8 introduced lambda expressions, which offer a replacement for listeners. You can directly use lambda expressions in place of listeners that have only one method to implement.

    For example, in the following, we use a lambda expression to handle button click events in the constructor:

    Java

    See the .

    Java 8 is the future that is already here, and as Vaadin API uses event listeners extensively, using lambda expressions makes UI code much more readable.

    Directing events to handler methods is easy with method references:

    1. public class Java8Buttons extends CustomComponent {
    2.     public Java8Buttons() {
    3.         setCompositionRoot(new HorizontalLayout(
    4.             new Button("OK", this::ok),
    5.             new Button("Cancel", this::cancel)));
    7.     public void ok(ClickEvent event) {
    9.     }
    11.     public void cancel(ClickEvent event) {
    12.         event.getButton().setCaption ("Not OK!");
    13.     }
    14. }

    See the on-line example.

    The following example follows a typical pattern where you have a Button component and a listener that handles user interaction (clicks) communicated to the application as events. Here we define a class that listens to click events.

    Java

    See the .

    If an application receives events of the same type from multiple sources, such as multiple buttons, it has to be able to distinguish between the sources. If using a regular class listener, distinguishing between the components can be done by comparing the source of the event with each of the components. The method for identifying the source depends on the event type.

    Java

    1. public class TheButtons extends CustomComponent
    2.        implements Button.ClickListener {
    3.     Button onebutton;
    4.     Button toobutton;
    6.     public TheButtons() {
    7.         onebutton = new Button("Button One", this);
    9.         // Put them in some layout
    10.         Layout root = new HorizontalLayout();
    11.         root.addComponent(onebutton);
    12.         root.addComponent(toobutton);
    13.         setCompositionRoot(root);
    14.     }
    16.     @Override
    17.     public void buttonClick(ClickEvent event) {
    18.         // Differentiate targets by event source
    19.         if (event.getButton() == onebutton)
    20.             onebutton.setCaption ("Pushed one");
    21.         else if (event.getButton() == toobutton)
    22.             toobutton.setCaption ("Pushed too");

    Other techniques exist for separating between event sources, such as using object properties, names, or captions to separate between them. Using captions or any other visible text is generally discouraged, as it may create problems for internationalization. Using other symbolic strings can also be dangerous, because the syntax of such strings is checked only at runtime.