My grandfather used to say: “Makkelijker gezegd dan gedaan” (easier said then done). So when I talked about how HTML5 could be the new platform in-depended development paradigm, in this previous post, I better come with some real world examples instead of only saying it.

So that is exactly what I’ve been doing. My wife is a bit of an apple fan woman. And she has a book that she would like to publish. She couldn’t find a publisher, so the next best thing would be to put her book on an iPad, but you still need an publisher to put something on the iBook store and publishers are still stuck in the dark ages. So we’ve decided to make an application out of her book. Now I’ve written some objective-c code before and I must say it wasn’t the best experience I’ve had. Xcode at that time was awful, it was like writing software 10 years ago. So I started to look for alternatives. It could be a simple html page, but how to create a native iPad application out of that?

I’ve found something that I’m really exited about. Playn is a cross-platform game abstraction library for writing games that compile to multiple platforms one of these is html using gwt. Now if I use this in combination with phonegap then I can create a iPad app that can also run on android based pads. Not only that I could make it interactive add a game to the book and best of all do it in Java.

If you think about it, for companies this makes a lot of sense. Unless your companies key platform is iOS, having developers in-house that have objective-c knowledge is expensive. Also hiring external company to build an iPhone app is expensive and they have to work together with you to integrate your existing architecture. So having something like this where one can use existing knowhow to create a android and iPhone solution that works on both platforms is a huge cost saver.

The future of computing lies in mobile computing, more and more devices come on the market, tablets and phones that will connect through the Internet as technology is getting cheaper and wifi and 3g more common. That means our software will also need to run on these handheld devices, because our clients will want their services on all platforms. This is what Java set out to do 15 years ago, so that we have the ability to write software once and run it everywhere. The problem is these new platforms, that I believe will make up a large part of the future have, until now, no Java. It would be great if we can find something that will give us the ability to write our software only once.

I believe that the technology that is going to deliver us this promise is called HTML5. More and more applications will run inside you browser. I’m typing this article in google docs, which is a perfect example of how applications will evolve. No need to install anything or maintain up to date versions, even an operating system could be very minimalistic (google chrome). So Google is obviously sharing this vision, but also Microsoft is building it’s next version of office on something that is based on their web-browser.

Sadly the development language of HTML5 Javascript and not Java. Java has been around a long time and there are a lot of libraries that people have made. Would be cool if we can still use these, the answer is Googles Web Toolkit. GWT provides a way to code in Java and then translate that code into Javascript. This way we can still use all that great stuff that others made.

A good example of this future is Angry Birds, you have probably heard of this game. To create this game they have taken the java implementation of box2d called jbox2d and created a javascript version of that with the help of GWT. Once that is done you can use HTML5 Canvas to draw the Birds and calculate their positions if they are falling. Now because they have build it this way with HTML5 this game could also work on an iPhone, but even better because android is based on java you could create from this source a android version with only one line of code.

Have a look at some of the great things people are building with the HTML5, be sure that your browser supports it.

1. Drawing program deviantART
2. Old style game with new technology area5
3. Quake GWT HTML5 port

If you read my series on GWT dependency injection (parts: first, second and third), maybe you remember that, in part 3, I mentioned how convenient would be to reduce the boilerplate required to define events in GWT. I also mentioned how elegant I find the event definition in CDI. Wouldn’t it be nice to have a lightweight event model like that in GWT?

Let’s see first how an event is defined and handled in CDI:

public class CDISample {
    @Inject
    private Event<String> event;

    public void handler(@Observes String payload) {
        System.out.println(payload);
    }

    public static void main(String[] args) {
        event.fire("Hello event world!");
    }
}

While exactly this is maybe not doable in GWT (at least not yet), what about something like this?:

public class GWTSample {
    @Inject
    private SampleEvent event;

    public void execute() {
        event.dispatchTo(new Handler<String>() {
            public void onEvent(String payload) {
                Window.alert(payload);
            }
        });

        event.fire("Hello event world!");
    }

    public interface SampleEvent extends Event<String> {
    }
}

public class PingEvent extends GwtEvent<Handler> {
    public static Type<Handler> TYPE = new Type<Handler>();

    @Override
    public Type<Handler> getAssociatedType() {
        return TYPE;
    }

    @Override
    protected void dispatch(Handler handler) {
        handler.onEvent(this);
    }

    public interface Handler extends EventHandler {
        void onEvent(PingEvent event);
    }
}

public interface PingEvent extends Event<Void> {}

• First, the events have the same payload type (Void in this case), and therefore we need explicit types to distinguish the ping event from the pong event. This also happens in CDI where we would define explicit payload types instead.
• Second, in this implementation we will be using GWT’s deferred binding and, during the code generation phase, we need to know the parametrized type. Because of Java generics limitations, for this last it is necessary to define a new parametrized type which captures the payload type in its type parameter (wrapper).

Did I convince you? If I did, let’s go on and see how to use deferred binding and dependency injection to achieve it.

Letting GWT generate the boilerplate

Deferred binding in GWT is a really powerful feature implemented in the GWT compiler to substitute class implementations depending in environment properties like the user agent. This way, while the developer has the illusion of using the same classes independently of the browser, the deferred binding mechanism allows to select the adequate implementation for each browser.

Far from being static, deferred binding allows to generate code on the fly by mean of a generator class. This happens when the developer invokes the “GWT.create()” method on an interface. For the operation to succeed, a generator for the interface must exist. This will be invoked during GWT compilation time and its result (one or more Java classes) will be compiled and linked into the resulting JS application.

To configure which generator should be used for which interface, it is necessary to add a new “generate-with” entry in the GWT module descriptor. In the case of the demo application, the following code has been added to the “PingPong.gwt.xml” file:

...
    <generate-with class="com.canoo.gwt.events.server.eventsfwk.EventGenerator">
        <when-type-assignable class="com.canoo.gwt.events.client.eventsfwk.Event"/>
    </generate-with>
...

The contents of the “Event” and “EventGenerator” classes are the following:

public interface Event<T> {
    public void fire(T payload);

    public void dispatchTo(Handler<T> callback);

    public interface Handler<T> {
        public void onEvent(T payload);
    }
}

public class EventGenerator extends Generator {
    private static final String EVENT_IMPL = "EventImpl";
    private static final CodeTemplate GWT_SIMPLE_EVENT_TEMPLATE = new GwtSimpleEventTemplate();
    private static final CodeTemplate EVENT_IMPL_TEMPLATE = new EventImplTemplate();

    @Override
    public String generate(TreeLogger treeLogger, GeneratorContext generatorContext, String typeName) throws UnableToCompleteException {
        TypeOracle typeOracle = generatorContext.getTypeOracle();

        JClassType parentEventType = typeOracle.findType(Event.class.getName());
        JClassType eventType = typeOracle.findType(typeName);
        JClassType payloadType = findPayloadType(eventType, parentEventType);

        String gwtSimpleEventImplName = generateGwtSimpleEvent(treeLogger, generatorContext, eventType, payloadType);
        String eventImplTypeName = generateEventImpl(treeLogger, generatorContext, eventType, payloadType, gwtSimpleEventImplName);

        return qualifyInGwtEvents(eventImplTypeName);
    }

    private static JClassType findPayloadType(JClassType eventType, JClassType parentEventType) {
        JClassType interfaces[] = eventType.getImplementedInterfaces();
        for (JClassType anInterface : interfaces) {
            if ((anInterface instanceof JParameterizedType) && (anInterface.getErasedType() == parentEventType.getErasedType())) {
                JParameterizedType parametrizedType = (JParameterizedType) anInterface;
                return parametrizedType.getTypeArgs()[0];
            }
        }
        throw new IllegalStateException("Payload type not found for: '" + eventType + "'.");
    }

    private String generateGwtSimpleEvent(TreeLogger treeLogger, GeneratorContext generatorContext, JClassType eventType, JClassType payloadType) {
        String gwtSimpleEventImplName = getGwtSimpleEventImplName(eventType);

        PrintWriter gwtSimpleEventPrintWriter = generatorContext.tryCreate(treeLogger, getEventsPackageName(), gwtSimpleEventImplName);
        GWT_SIMPLE_EVENT_TEMPLATE.generate(gwtSimpleEventPrintWriter, getEventsPackageName(), gwtSimpleEventImplName, payloadType.getName());
        generatorContext.commit(treeLogger, gwtSimpleEventPrintWriter);

        return gwtSimpleEventImplName;
    }

    private String generateEventImpl(TreeLogger treeLogger, GeneratorContext generatorContext, JClassType eventType, JClassType payloadType, String gwtSimpleEventImplName) {
        String eventImplTypeName = getEventImplTypeName(eventType);
        String eventTypeName = getEventTypeName(eventType);

        PrintWriter eventPrintWriter = generatorContext.tryCreate(treeLogger, getEventsPackageName(), eventImplTypeName);
        EVENT_IMPL_TEMPLATE.generate(eventPrintWriter, getEventsPackageName(), eventType.getQualifiedSourceName(), eventImplTypeName, eventTypeName, gwtSimpleEventImplName, payloadType.getName());
        generatorContext.commit(treeLogger, eventPrintWriter);

        return eventImplTypeName;
    }

... (some methods omitted)

While the “Event” class contains the interface definition for our events and lives in the “client” package of our GWT application, the “EventGenerator” is a GWT specific class that resides in the “server” package of our GWT application. In order to compile the code, we will need to add a new dependency to our project: “gwt-dev-<version>.jar”.

This generator class, by mean of some templates included in the source code, generates the boilerplate classes and saves us the tedious work of writing these classes. If you want to see this in detail, please refer to the “eventsfwk” packages in the client and server part of the application (source code here).

Using GIN to bring everything together

Following what I mentioned until now, it seems that if we define an interface extending the “Event” interface (ex: “SampleEvent”) and we use the generator to generate and wire the code by mean of “GWT.create(SampleEvent.class)”, we should be able to use the result as shown in the “GWTSample” execute method. Not really.

One piece that is missing in the puzzle is which event bus should the underlying GWT events use. We could create an own one without loosing functionality but a better thing that we can do is to provide an injection point and provide a mechanism to make our events participate in the application’s dependency injection context and use the application’s event bus instead of an own instance.

To achieve this, we have created a GIN module in the “eventsfwk” package:

public class EventsModule extends AbstractGinModule {
    @Override
    protected void configure() {
        requestStaticInjection(GwtSimpleEvent.class);
    }
}

This module should be installed in the application’s dependency context and it will inject an static field in the “GwtSimpleEvent” class which is the event bus used for our improved events. To install it in our application, the injection module has been modified like this (note the line “install(EventsModule.class);”):

@GinModules(Module.class)
public interface Injector extends Ginjector {
    public static class Module extends AbstractGinModule {
        @Override
        protected void configure() {
            bind(EventBus.class).to(SimpleEventBus.class).in(Singleton.class);

            install(new EventsModule());
            install(new GinFactoryModuleBuilder().build(Factory.class));

            bindConstant().annotatedWith(named("PingText")).to("Ping");

... (code omitted)
}

This means that, when the dependency injection module is initialized at the beginning of the application execution, the previously configured event bus will be statically injected in the “GwtSimpleEvent” class used by all the generated event classes.

I can not read minds, but maybe you are also wondering why the event fields annotated with “@Inject” get generated and injected. All in all, we don’t call anywhere “GWT.create()” to use the generator class.

Well, we are not doing it but GIN does. Whenever GIN finds a dependency (something annotated with “@Inject”) and that dependency has not explicitly been configured (bound in the GIN modules), GIN invokes “GWT.create()” as fallback strategy. This simple mechanism allows us to generate and inject our event in only one step.

Wow! This post has been “hardcore” GWT, don’t you think? Maybe even too “hardcore”. Please, just let me know if you like it and what do you think about the approach.

See you in a future post!

The source code for the initial version of the application can be downloaded here. The final version here. To see any of the applications working, unzip the corresponding file, change to the folder where the Maven pom file is stored and type the command: “mvn clean gwt:run”. After the GWT “Development mode” application starts, click on the “Launch Default Browser” button.

This is the third part of a series about Dependency Injection in Google Web Toolkit using GIN. If you have not yet read the first and second parts, you maybe should do it before reading this third and last article.

In this article, we will introduce two GIN features: “constants binding” and “static injection”.
To do this with an example, let’s refactor the “serve button” in the “Simulator” main class of the second part into an own class:

...
        final Button button = new Button("Serve!");
        button.addClickHandler(new ClickHandler() {
            public void onClick(ClickEvent event) {
                button.setVisible(false);
                injector.getRacket().serve();
            }
        });
...

Here the new extracted “ServeView” class:

public class ServeView extends Button {
    @Inject
    public ServeView(final Racket racket, @Named("ServeText") String serveText) {
        super(serveText);
        addClickHandler(new ClickHandler() {
            public void onClick(ClickEvent event) {
                setVisible(false);
                racket.serve();
            }
        });
    }
}

As you can see, the constructor of this new class is annotated with the “@Inject” annotation and receives two parameters. One of them is the racket and the other is the button’s label. In the case of the racket, it is already defined as an injectable dependency in the injector interface and in the case of the button’s label, it should be a configurable constant.
GIN, by mean of “constants binding”, performs the binding of injectable dependencies to constants.
Because the type of the “serveText” is String, we need to be more specific here and therefore we have annotated this dependency with the “@Named” annotation. To configure the constant value to bind to, we need to add the following line into our “InjectorModule” class:

...
        bindConstant().annotatedWith(named("ServeText")).to("Serve!");
...

To let the other constants in the application be configured in the same way and to introduce the last GIN feature (“static injection”), let’s now modify the “Simulator” main class as follows:

public class Simulator implements EntryPoint {
    @Inject
    static ServeView SERVE_VIEW;

    @Inject
    static AssistedInjectionFactory FACTORY;

    @Inject
    @Named("PingText")
    static String PING_TEXT;

    @Inject
    @Named("PongText")
    static String PONG_TEXT;

    public void onModuleLoad() {
        initInjection();
        RootPanel.get("buttonSlot").add(SERVE_VIEW);
        RootPanel.get("pingSlot").add(FACTORY.createPingPongView(PING_TEXT, PingEvent.class));
        RootPanel.get("pongSlot").add(FACTORY.createPingPongView(PONG_TEXT, PongEvent.class));
    }

    private void initInjection() {
        GWT.create(Injector.class);
    }
}

And our “InjectorModule” like this:

public class InjectorModule extends AbstractGinModule {
    @Override
    protected void configure() {
        bind(EventBus.class).to(SimpleEventBus.class).in(Singleton.class);

        install(new GinFactoryModuleBuilder().build(AssistedInjectionFactory.class));

        bindConstant().annotatedWith(named("PingText")).to("Ping");
        bindConstant().annotatedWith(named("PongText")).to("Pong");
        bindConstant().annotatedWith(named("ServeText")).to("Serve!");

        requestStaticInjection(Simulator.class);
    }
}

The “static injection” allows us to inject the static fields of a class. This happens by mean of the method “requestStaticInjection” of the GIN module class and, in our application, we use it to inject the static dependencies of the “Simulator” class.

This way, even when the “Simulator” class does not participate in the dependency injection context, its static members will be injected making the explicit references to the injector not required.

This has the side-effect of making the “Injector” getters no more necessary leaving our injector interface “empty”:

@GinModules(InjectorModule.class)
public interface Injector extends Ginjector {
}

Please note that, in order to get the dependency injection context configured and initialized, it is required to instantiate the “Injector” interface by mean of the “GWT.create()” method as part of the application initialization. This is done in our case within the “initInjection” method in the “Simulator” main class.

Conclusions

If you have read the 3 articles of this series, maybe you can remember how our demo application looked like at the beginning. While the functionality and appearance has not changed at all, the intern structure of the application is completely different.

In my opinion, dependency injection allows a much cleaner structure, enables configuring the application in an elegant and easy way and, when used together with an event bus, produces low-coupled high-modular applications.

Of course, “there is no free lunch” and using GIN means also that the development team has to learn new concepts and introduce a new framework in the application. Anyway, dependency injection is an already proven concept and GIN is being intensively used in most of the new GWT projects and GWT frameworks.

While some minimal application structure optimizations could still be applied to the application, the thing that I still find improvable in it is the verbosity of the GWT events definitions. This requires writing some boilerplate classes to ensure the type safety (event handlers), and also the definition of the own event classes is too verbose, being possible to generate them automatically in most of the cases by using either GWT’s deferred binding or a JDK 6 annotation processor. If you know how the events in CDI are defined, very probably you will agree with me that such an approach would be much more elegant and concise.

A solution for that, even when it requires dependency injection, is more related to other topics and therefore a subject for a different thread. If you got curious, stay tuned for a future post on code generation in GWT!

The source code of the application can be downloaded here. To see the application working, unzip the file, change to the folder where the Maven pom file is stored and type the command: “mvn clean gwt:run”. After the GWT “Development mode” application starts, click on the “Launch Default Browser” button.

As always, I hope that you enjoyed reading this series of articles as much as I did writing it and hope to see you soon in a future post!

This is the second part of a series about Dependency Injection in Google Web Toolkit using GIN. If you have not yet read the first part, there we explained how to integrate GIN in an existing GWT sample application. In this second part, we will continue enhancing the sample application while explaining other types of injection supported by GIN.

Encapsulating the event bus

In the first part of this series, we configured the GWT event bus used in the original application to be injected in some of the application elements. Using an event bus is a “best practice” that helps communicating the different components in the application while keeping a low coupling between them. The point here was to show how to declare and configure a first dependency using the “injector” and the “module”. Because the class “SimpleEventBus” is provided by GWT, it was not possible to annotate the code of the class with “@Singleton” to set the “injection scope”. Instead, we use the Java DSL provided by GIN.
In order to see how to do the same with annotations, let’s use now an application class (instead of a framework class) where we can use the annotations.
As you probably noticed, we are using the event bus to emulate the “ping-pong” strokes. Instead of such a technical artifact, let’s create a “racket”:

@Singleton
public class Racket {
    private final EventBus fEventBus;

    private GwtEvent<?> fLastEvent;

    @Inject
    public Racket(EventBus eventBus) {
        fEventBus = eventBus;
    }

    public void serve() {
        fLastEvent = null;
        hit();
    }

    public void hit() {
        fEventBus.fireEvent(getNextEvent());
    }

    private GwtEvent<?> getNextEvent() {
        if (fLastEvent == null || fLastEvent instanceof PongEvent) {
            fLastEvent = new PingEvent();
        } else {
            fLastEvent = new PongEvent();
        }
        return fLastEvent;
    }

    public void onStroke(Class<?> pingPongEvent, final Command command) {
        if (pingPongEvent == PingEvent.class) {
            fEventBus.addHandler(PingEvent.TYPE, new PingEventHandler() {
                public void onEvent(PingEvent event) {
                    command.execute();
                }
            });
        } else {
            fEventBus.addHandler(PongEvent.TYPE, new PongEventHandler() {
                public void onEvent(PongEvent event) {
                    command.execute();
                }
            });
        }
    }
}

@GinModules(InjectorModule.class)
public interface Injector extends Ginjector {
    public static final Injector INSTANCE = GWT.create(Injector.class);

    public Racket getRacket();

    public PingView getPingView();

    public PongView getPongView();
}

public class PingView extends Label {
    @Inject
    public PingView(final Racket racket) {
        racket.onStroke(PongEvent.class, new Command() {
            public void execute() {
                setText("Pong");

                new Timer() {
                    public void run() {
                        setText("");
                        racket.hit();
                    }
                }.schedule(1000);
            }
        });
    }
}

public class Simulator implements EntryPoint {
    public void onModuleLoad() {
        final Injector injector = Injector.INSTANCE;
        RootPanel.get("pingSlot").add(injector.getPingView());
        RootPanel.get("pongSlot").add(injector.getPongView());

        final Button button = new Button("Serve!");
        button.addClickHandler(new ClickHandler() {
            public void onClick(ClickEvent event) {
                button.setVisible(false);
                injector.getRacket().serve();
            }
        });
        RootPanel.get("buttonSlot").add(button);
    }
}

• GIN allows to define “injectors” by mean of interfaces (“Injector” interface) that can be configured using one or more “modules” each (“InjectorModule” class).
• If we need to configure an injection aspect we can use annotations in the class code or the Java DSL in the module.
• In at least one point of the application we will need to access the “injector” to retrieve a top-level injected object (ex: “Racket”, “PingView”, “PongView” ). For these objects to be accessible through the injector, we need to declare them in the “injector” interface.
• Any other dependency that is declared to be injected (annotated with @Inject) will be resolved by GIN using the algorithm described in the first part of this series and does not need to be declared in the “injector” interface (ex: “EventBus”).

If you are familiar with GUICE, you probably already know other ways of configuring dependencies and injection. Let’s see in the next point how to avoid the repetition in the views by using “assisted injection”.

Using assisted injection to avoid code repetition

One of the main applications of dependency injection is to avoid coding factory classes and singletons and also centralizing the application’s configuration values. This is a very powerful tool to configure application-wide objects like services, which typically are either “singletons” or “prototypes” and scarce.

When working with data, persistency tools like JPA assist us with the task of generating Java objects for our numerous domain model entities. These objects have normally no behavior or just a little which is typically coded in the “entity” classes. But, what happens if we want to inject our services in some of these entities to have a richer domain model? Normally, we have to tackle this task ourselves and inject the services by hand. This happens because such objects do not by default participate in the injection context (unless we are using JEE or weaving).

While this not a difficult task, it is a purely programmatic one and breaks one of the principles of dependency injection: declarative dependencies definition.
In GUICE (and therefore in GIN) there is a concept called “assisted injection” that helps us to create objects which require dependencies from the injection context but also instance specific property values. Basically, it consists of using a factory interface with methods to instantiate the objects as managed beans (injected objects) receiving each method only the object’s specific properties as parameters. The object constructors receive of course not only the object properties but also the dependencies who should be retrieved from the dependency injection context.

Because an image is worth a thousand words, let’s see this with an example. What we would like to achieve here is to have only one view class (“PingPongView”) instead of two specific ones that have almost the same code. If we inspect both view classes, the differences are: to which event each reacts and which text each shows. If we refactor these values as constructor parameters, we have the following resulting class:

public class PingPongView extends Label {
    @Inject
    public PingPongView(final Racket racket, @Assisted final String text, @Assisted Class<? extends GwtEvent> eventClass) {
        racket.onStroke(eventClass, new Command() {
            public void execute() {
                setText(text);

                new Timer() {
                    public void run() {
                        setText("");
                        racket.hit();
                    }
                }.schedule(1000);
            }
        });
    }
}

public interface AssistedInjectionFactory {
    public PingPongView createPingPongView(String text, Class<? extends GwtEvent> eventClass);
}

public class InjectorModule extends AbstractGinModule {
    @Override
    protected void configure() {
        bind(EventBus.class).to(SimpleEventBus.class).in(Singleton.class);

        install(new GinFactoryModuleBuilder().build(AssistedInjectionFactory.class));
    }
}

@GinModules(InjectorModule.class)
public interface Injector extends Ginjector {
    public static final Injector INSTANCE = GWT.create(Injector.class);

    public Racket getRacket();
    public AssistedInjectionFactory getFactory();
}

...
    public void onModuleLoad() {
        final Injector injector = Injector.INSTANCE;
        final AssistedInjectionFactory factory = injector.getFactory();
        RootPanel.get("pingSlot").add(factory.createPingPongView("Ping", PingEvent.class));
        RootPanel.get("pongSlot").add(factory.createPingPongView("Pong", PongEvent.class));
...

In this article, we have applied new dependency injection recipes to our GWT demo application. I hope that they can help you give a better structure to your GWT applications and also learn dependency injection features and its “best practices”.

The source code of the application can be downloaded here. To see the application working, unzip the file, change to the folder where the Maven pom file is stored and type the command: “mvn clean gwt:run”. After the GWT “Development mode” application starts, click on the “Launch Default Browser” button.

The other parts of this series can be found here and here.

I hope that you enjoyed reading this article as much as I did writing it.
See you soon!

Dependency Injection is already a well-known and discussed topic in the Java world and there are a good number of well established frameworks and libraries supporting this concept. While for many developers it is a must, some others seem not to be so convinced and think that it does not bring that much value to a project. Of course, it depends on the project, but with the time, it seems that its benefits have been widely accepted and support for it has been incorporated in almost every piece of software where it seemed to make sense.

This is also the case of Google Web Toolkit where GIN provides dependency injection support on the client side.
GIN is a mainly a GWT-based version of the Google’s homegrown dependency injection framework GUICE. But because the GWT applications run on top of the browser JavaScript engine instead of on the JVM, some of the GUICE features are not available in GIN. On the other hand, GWT provides some poweful features for code generation that have enabled a meaningful subset of the GUICE features to be implemented in GWT.

Instead of writing an introduction tutorial to the GIN capabilities, the purpose of this article series is to illustrate some of the GIN features while applying some recipes to an existing application.

Maybe you already know this little screencast where Hamlet D’Arcy explains how to decouple GWT components by mean of an “event bus” in a little “ping-pong” simulation. If not, maybe you would like to spend five minutes watching the screencast and, once you are done, read on and learn how to apply some dependency injection techniques to improve this little application.

The source code of the application can be downloaded here. To see the application working, unzip the file, change to the folder where the Maven pom file is stored and type the command: “mvn clean gwt:run”. After the GWT “Development mode” application starts, click on the “Launch Default Browser” button.

Adding GIN to the application

In order to start using GIN in the sample application, the first task that we should accomplish is adding the GIN dependencies to the project. Because the build of the application is Maven-based, we need simply to add the following dependency to the Maven pom file:

<dependency>
    <groupId>com.google.gwt.inject</groupId>
    <artifactId>gin</artifactId>
    <version>1.5.0</version>
    <scope>compile</scope>
</dependency>

Ok, and what now? First, let’s have a look at the “main” class of our GWT application, the “Simulator” class:

public class Simulator implements EntryPoint {
    public void onModuleLoad() {
        final EventBus bus = new SimpleEventBus();
        RootPanel.get("pingSlot").add(new PingView(bus));
        RootPanel.get("pongSlot").add(new PongView(bus));

        final Button button = new Button("Serve!");
        button.addClickHandler(new ClickHandler() {
            public void onClick(ClickEvent event) {
                button.setVisible(false);
                bus.fireEvent(new PingEvent());
            }
        });
        RootPanel.get("buttonSlot").add(button);
    }
}

@GinModules(InjectorModule.class)
public interface Injector extends Ginjector {
    public static final Injector INSTANCE = GWT.create(Injector.class);

    public EventBus getEventBus();
}

public class InjectorModule extends AbstractGinModule {
    @Override
    protected void configure() {
        bind(EventBus.class).to(SimpleEventBus.class).in(Singleton.class);
    }
}

Let’s see now how to use the injector in the “Simulator” class to perform the injection:

public void onModuleLoad() {
    final Injector injector = Injector.INSTANCE;   
    RootPanel.get("pingSlot").add(new PingView(injector.getEventBus()));
    RootPanel.get("pongSlot").add(new PongView(injector.getEventBus()));

    final Button button = new Button("Serve!");
    button.addClickHandler(new ClickHandler() {
        public void onClick(ClickEvent event) {
            button.setVisible(false);
            injector.getEventBus().fireEvent(new PingEvent());
        }
    });
    RootPanel.get("buttonSlot").add(button);
}

@GinModules(InjectorModule.class)
public interface Injector extends Ginjector {
    public static final Injector INSTANCE = GWT.create(Injector.class);
    public EventBus getEventBus();
    public PingView getPingView();
    public PongView getPongView();
}

public class Simulator implements EntryPoint {
    public void onModuleLoad() {
        final Injector injector = Injector.INSTANCE;
        RootPanel.get("pingSlot").add(injector.getPingView());
        RootPanel.get("pongSlot").add(injector.getPongView());

        final Button button = new Button("Serve!");
        button.addClickHandler(new ClickHandler() {
            public void onClick(ClickEvent event) {
                button.setVisible(false);
                injector.getEventBus().fireEvent(new PingEvent());
            }
        });
        RootPanel.get("buttonSlot").add(button);
    }
}

To make the application work, add the “@Inject” annotation to the constructors of both view components as shown in this example:

...
    @Inject
    public PongView(final EventBus bus) {
...

With these changes in the sample application, we have learnt:

• how to configure GIN using an injector interface and a module class.
• How to define a first dependency: the event bus.
• How to select an implementation for the dependency: the “SimpleEventBus” class.
• How to bind this dependency to a context: the application context in this case (also referred sometimes as “singleton scope”).
• And finally, how to get the dependency injected in a constructor (what is only one of the many ways of doing dependency injection in GIN).

For this series of articles, we chose intentionally a simple application where to apply some simple dependency injection recipes. If you are not yet convinced of its benefits, don’t abandon yet! We have just started and in the following articles, we will explore some other possibilities and use cases.

I hope that you enjoyed reading the article and also to see you in the next part.

The other parts of this series can be found here and here.

The source code of the dependency-enabled application can be downloaded here. To execute the application, simply follow the same steps described above for the initial version.

Wheee! I made a screencast. Happy Friday to you too.

One of the newest features introduced in Google Web Toolkit 2.0 is the “UiBinder“. This new way of building views allows the developer to use a declarative approach when doing the layout of a GWT application.

In case you have not heard about it, GWT is a set of tools that enables Java developers to develop “rich web applications” in the Java language. The term “rich web application” implies two things:

• Desktop-like interaction, where a user action has immediate feedback (e.g.: input validation, search box terms suggestions, results highlighting, etc) without requiring a server round-trip (executing an HTTP request with the result of reloading the page being browsed). In the world of web applications, this is typically accomplished using Ajax (what is also what GWT does).
• An application running within a browser, but using native browser technologies (HTML, CSS and JavaScript). If we were talking about applications held in browser plug-ins and running out-of-process within their own virtual machines or by mean of run-times, I would prefer to use the more general term “rich internet applications”. These are launched from a web browser but behave as black boxes for other user agents (e.g.: web crawlers).

GWT allows us is write Ajax-based “rich web applications” using the Java language instead of the traditional JavaScript. GWT takes your Java code and compiles into JavaScript, HTML, and CSS. So while you write the program in Java, it is translated into a traditional web application.

Building user interfaces in GWT

The most common approach to building desktop application interfaces is using visual components called “widgets”. For developers with Swing experience, GWT seems a marvellous step forward because it allows you to leverage most of your knowledge with far less effort than the alternatives. I say seems because this can also be of disadvantage, as I’ll show with an example.
If we had to create a web interface for a simple web search application, the most common way of doing the interface would be an HTML form for submitting the query and an HTML list to show the results:

<html>
<head>
    <title>Search application</title>
</head>
<body>
<div id="searchBox">
    <h2>Search:</h2>
    <form action="">
        <label for="queryInput">Query:</label>
        <input id="queryInput" type="text"/>
        <input type="submit" value="Go!"/>
    </form>
</div>
<div id="searchResults">
    <h2>Results:</h2>
    <ul id="results">
        <li>Result 1</li>
        <li>Result 2</li>
        <li>Result 3</li>
    </ul>
</div>
</body>
</html>

public class SearchGwt implements EntryPoint {
    public void onModuleLoad() {
        Widget searchBox = createSearchBox("Query:", "Go!");
        Panel searchResults = createSearchResults();

        VerticalPanel mainContainer = new VerticalPanel();
        mainContainer.add(new Label("Search:"));
        mainContainer.add(searchBox);
        mainContainer.add(new Label("Results:"));
        mainContainer.add(searchResults);

        RootPanel.get().add(mainContainer);
    }

    private Widget createSearchBox(String inputLabel, String buttonLabel) {
        HorizontalPanel searchBox = new HorizontalPanel();
        searchBox.add(new Label(inputLabel));
        searchBox.add(new TextBox());
        searchBox.add(new Button(buttonLabel));
        return searchBox;
    }

    private Panel createSearchResults() {
        VerticalPanel searchResults = new VerticalPanel();
        for (int i = 1; i <= 3; i++) {
            searchResults.add(new Label("Result " + i));
        }
        return searchResults;
    }
}

<html>
<head>
    <title>Search GWT application</title>
</head>
<body>
<!-- GWT script and iframe tags omitted -->
<div>
    <div class="gwt-Label">Search:</div>
    <table cellspacing="0" cellpadding="0">
        <tbody>
        <tr>
            <td align="left" style="vertical-align: top;">
                <div class="gwt-Label">Query:</div>
            </td>
            <td align="left" style="vertical-align: top;"><input type="text" tabindex="0" class="gwt-TextBox"/></td>
            <td align="left" style="vertical-align: top;">
                <button type="button" tabindex="0" class="gwt-Button">Go!</button>
            </td>
        </tr>
        </tbody>
    </table>
    <div class="gwt-Label">Results:</div>
    <div>
        <div class="gwt-Label">Result 1</div>
        <div class="gwt-Label">Result 2</div>
        <div class="gwt-Label">Result 3</div>
    </div>
</div>
</body>
</html>

Mixing HTML and Widgets

So how can we mix widgets and html properly? Before GWT version 2.0, the most common way was to use “RootPanel.get(‘someId’)” to access an HTML element in the application host page, and then create an object there to attach the widgets to (ie. a “RootPanel”). If we need to embed only a few widgets in the host page, this technique suffices. But doing this in a real application with a large number of widgets becomes complex and slow.
UiBinder scales better because it does not inject widgets into the HTML of the host page. Instead, you declare your layout in a stand-alone HTML file that can be composed with other components as many times as necessary to build more complex interfaces. Composition entails componentization, allowing the developer to create subparts of the user interface (UI components) that can be packaged, re-used and tested in isolation.
But let us see how with an example:

public class SearchGwt implements EntryPoint {
    public void onModuleLoad() {
        SearchComponent searchComponent = new SearchComponent();
        RootPanel.get().add(searchComponent);
    }
}

<ui:UiBinder xmlns:ui='urn:ui:com.google.gwt.uibinder'
                xmlns:g='urn:import:com.google.gwt.user.client.ui'>
    <g:HTMLPanel>
        <div id="searchBox">
            <h2>Search:</h2>
            <form action="">
                <label for="queryInput">Query:</label>
                <input id="queryInput" type="text"/>
                <input type="submit" value="Go!"/>
            </form>
        </div>
        <div id="searchResults">
            <h2>Results:</h2>
            <ul id="results">
                <li>Result 1</li>
                <li>Result 2</li>
                <li>Result 3</li>
            </ul>
        </div>
    </g:HTMLPanel>
</ui:UiBinder>

public class SearchComponent extends Composite {
    interface Binder extends UiBinder<Widget, SearchComponent> {
    }

    private static Binder uiBinder = GWT.create(Binder.class);

    public SearchComponent() {
        initWidget(uiBinder.createAndBindUi(this));
    }
}

<ui:UiBinder xmlns:ui='urn:ui:com.google.gwt.uibinder'
                xmlns:g='urn:import:com.google.gwt.user.client.ui'>
    <g:HTMLPanel>
        <div id="searchBox">
            <h2>Search:</h2>
            <form action="">
                <label for="queryInput">Query:</label>
                <g:TextBox ui:field="queryInput"/>
                <input type="submit" value="Go!"/>
            </form>
        </div>
        <div id="searchResults">
            <h2>Results:</h2>
            <ul id="results">
                <li>Result 1</li>
               <li>Result 2</li>
               <li>Result 3</li>
            </ul>
        </div>
    </g:HTMLPanel>
</ui:UiBinder>

public class SearchComponent extends Composite {
    interface Binder extends UiBinder<Widget, SearchComponent> {
    }

    private static Binder uiBinder = GWT.create(Binder.class);

    @UiField
    TextBox queryInput;

    public SearchComponent() {
        initWidget(uiBinder.createAndBindUi(this));
    }
}

<ui:UiBinder xmlns:ui='urn:ui:com.google.gwt.uibinder'
                xmlns:g='urn:import:com.google.gwt.user.client.ui'>
    <g:HTMLPanel>
        <div id="searchBox">
            <h2>Search:</h2>
            <form action="">
                <label for="queryInput">Query:</label>
                <g:TextBox ui:field="queryInput"/>
                <input type="submit" value="Go!"/>
            </form>
        </div>
        <div id="searchResults">
            <h2>Results:</h2>
            <ul ui:field="results"/>
        </div>
    </g:HTMLPanel>
</ui:UiBinder>

public class SearchComponent extends Composite {
    interface Binder extends UiBinder<Widget, SearchComponent> {
    }

    private static Binder uiBinder = GWT.create(Binder.class);

    @UiField
    TextBox queryInput;
    @UiField
    UListElement results;

    public SearchComponent() {
        initWidget(uiBinder.createAndBindUi(this));
        queryInput.getElement().setId("queryInput");
        for (int i = 1; i <= 3; i++) {
            results.appendChild(createResultsItem("Result " + i));
        }
    }

    private Element createResultsItem(String value) {
        LIElement result = Document.get().createLIElement();
        result.setInnerHTML(value);
        return result;
    }
}

public class SearchGwt implements EntryPoint {
    public void onModuleLoad() {
        Panel searchResults = new FlowPanel();
        Widget searchBox = createSearchBox("Query:", "Go!", searchResults);

        FlowPanel mainContainer = new FlowPanel();
        mainContainer.add(new Label("Search:"));
        mainContainer.add(searchBox);
        mainContainer.add(new Label("Results:"));
        mainContainer.add(searchResults);

        RootPanel.get().add(mainContainer);
    }

    private Widget createSearchBox(String inputLabel, String buttonLabel,
                                   Panel searchResults) {
        HorizontalPanel searchBox = new HorizontalPanel();
        searchBox.add(new Label(inputLabel));
        searchBox.add(new TextBox());
        searchBox.add(new Button(buttonLabel,
                      createClickHandler(searchResults)));
        return searchBox;
    }

    private ClickHandler createClickHandler(final Panel searchResults) {
        return new ClickHandler() {
            public void onClick(ClickEvent event) {
                for (int i = 1; i <= 3; i++) {
                    searchResults.add(new Label("Result " + i));
                }
            }
        };
    }
}

<ui:UiBinder xmlns:ui='urn:ui:com.google.gwt.uibinder'
             xmlns:g='urn:import:com.google.gwt.user.client.ui'>
    <g:HTMLPanel>
        <div id="searchBox">
            <h2>Search:</h2>
            <label for="queryInput">Query:</label>
            <g:TextBox ui:field="queryInput"/>
            <g:Button ui:field="searchButton" text="Go!"/>
        </div>
        <div id="searchResults">
            <h2>Results:</h2>
            <ul ui:field="results"/>
        </div>
    </g:HTMLPanel>
</ui:UiBinder>

public class SearchComponent extends Composite {
    interface Binder extends UiBinder<Widget, SearchComponent> {
    }

    private static Binder uiBinder = GWT.create(Binder.class);

    @UiField
    TextBox queryInput;
    @UiField
    Button searchButton;
    @UiField
    UListElement results;

    public SearchComponent() {
        initWidget(uiBinder.createAndBindUi(this));
        queryInput.getElement().setId("queryInput");
    }

    @UiHandler("searchButton")
    void buttonClick(ClickEvent event) {
        for (int i = 1; i <= 3; i++) {
            results.appendChild(createResultsItem("Result " + i));
        }
    }

    private Element createResultsItem(String value) {
        LIElement result = Document.get().createLIElement();
        result.setInnerHTML(value);
        return result;
    }
}

Session title: RIA Security: Broken by Design
From: Joonas Lehtinen, CEO IT Mill

IT Mill is the creator of Vaadin: A 100% Java tool for RIA.

Joonas outlines a spectrum of complexity from Basic site to 3D games examples:
Web Sites (Wikipedia), AJAX Sugar (Facebook), Full RIA

He divides „Full RIA“ divide into client side vs. Server driven. Gives a crash course in GWT.

Vaadin: Apparently 100% Java and server driven, which sounds an awful lot like ULC at this stage… But here’s a difference: It builds on GWT and relies on JavaScript on the client-side.

He goes on to present a bunch of development rules:

Rule #1: Don’t trust the browser
Rule #2: Complexity is a hiding place for bugs
Rule #3: Large surface give more opportunities for attack. This surface has increased with Web 2.0.

Difference between GWT and Vaadin architectures is that GWT relies on the client invoking a server-side Web Service API, whereas Vaadin renders the client’s view on the server.

Erm… he then offers the cures for the problems (Rules above)… which I miss because the explanation is compressed into around 5s.

I’m starting to dislike this presentation at this point. Because here comes another artificial security issue scenario… which guess which product solves. And I thought product placement in Hollywood movies was irritating.

The issues he raises are legitimate, but the lack of objectivity is obscuring the message. And as I write the presenter is debugging JavaScript which depends on analysing the DOM on the client side – I’m not sure if he’s now analysing the problem or trying to fix it!?

I am formally declaring myself lost at this stage. At least I hope the other attendees are getting something out of this presentation, which has lost focus IMO.

He continues with a discussion about attacking at the transport level, inserting new data on the fly. But come on: A secure transaction in this technical setting will operate under HTTPS, which in most instances will deal with this kind of attack. Unless, of course, that’s something else I missed.

I think I need a coffee!!!

Here is a link to an older Computerworld.ch article comparing Google Web Toolkit and Canoo’s Java RIA library, UltraLightClient (in German only).

Google Web Toolkit und Ultra Light Client

Die Anbindung an das Internet und ein Browser gehören heute zur Standardausrüstung eines jeden Arbeitsplatzrechners oder Heim-PCs.

Stefan Thomas

Viele neue Anwendungen werden darum als HTML-basierte Web-Anwendungen implementiert, die leicht verteilt und aktualisiert werden können und von überall, zu jeder Zeit genutzt werden können. Durch den Einsatz von AJAX-Technologien konnte die Benutzerfreundlichkeit der Oberflächen in den letzten Jahren deutlich gesteigert werden, allerdings bei gleichzeitig wachsender Komplexität in der Anwendungsentwicklung. Bibliotheken, Toolkits und Frameworks versprechen hier eine Erleichterung. Beispielsweise durch die Abstraktion der unterschiedlichen JavaScript-Implementierungen der Browser oder durch vorgefertigte, komplexere Bedienelemente wie Menübalken, Tabreiter oder Baumstrukturen.

The article was written by UltraLightClient customer Dr. Stefan Thomas. Dr. Thomas is an independent consultant, that has developed two large corporate web applications with Canoo’s UltraLightClient for a global retailer.

GWT vs. ULC:

Comparing the two is a bit like comparing apples and pears (the article discusses this). On the other hand, the two widget libraries can be used for similar web applications. And both of them address Java developers.

See also the corresponding product websites:
Google Web Toolkit
Canoo UltraLightClient