A static EventBus / SimpleEventBus: Pro & Contra

[Alexander Orlov]

EventBus is a really nice mechanism to decouple methods from callbacks by adding corresponding event handlers to an EventBus.

By nature EventBus is something that should be known to both classes, the calling and the called class. So you can

1. pass an EventBus in a constructor or

2. use a static EventBus that can be called from any View

Is there a rule of thumb how you should use an EventBus? So far I saw only constructor usage examples. Are there some significant disadvantages that come with a static EventBus?

[Thomas Broyer]

Injecting an EventBus allows you to pass the one instance you want (SimpleEventBus, ResettableEventBus, CountingEventBus, RecordingEventBus, or your own subtype), and change that between dev, production, and tests.

[Alexander Orlov]

Maybe I've misguided you mentioning the SimpleEventBus implementation of the EventBus interface. The actual question was whether I should use a *static* EventBus that can be defined in a "Common" class and reference this static EventBus from any other view.

E.g. using

MyView() {

    // MyView Constructor

}

Common.myEventBus.fireEvent(new MyEvent()); // the _static_ way

VS.

MyView(final EventBus myEventBus) {

    this.myEventBus = myEventBus;

    // The rest of MyView Constructor

}

myEventBus.fireEvent(new MyEvent()); // the _non-static_ way

On Mon, Nov 7, 2011 at 12:15 PM, Thomas Broyer <t.br...@gmail.com> wrote:

Injecting an EventBus allows you to pass the one instance you want (SimpleEventBus, ResettableEventBus, CountingEventBus, RecordingEventBus, or your own subtype), and change that between dev, production, and tests.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/x7AlvB4OuZkJ.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Thomas Broyer]

I had understood, so that doesn't change my answer.

With the static instance, everyone shares exactly the same. With an injected instance, you can wrap your global singleton eventbus within a ResettableEventBus in some cases (depending on how you manage your classes lifecycle), or some other custom similar eventbus, and/or you can pass a CountingEventBus or RecordingEventBus in your unit tests.

[Jens]

As GIN also supports static injection it seems like there is not much of a difference, but:

1.) Using the static way you somehow hide the fact that a class depends on an event bus

2.) Sometimes its nice to have multiple instances of an event bus. Especially having multiple ResettableEventBus's are pretty handy that wrap that singleon app wide event bus. 

[Thomas Broyer]

Sorry if I didn't make it clear enough: "With the static instance, everyone shares exactly the same [instance]", which means that you cannot choose, for a particular object, to use a different instance (e.g. ResettableEventBus), unless you make that object "depend" explicitly on the other instance (in other words, this is a "everyone *must* use the same instance", not a "everyone uses the same instance by default"). That means you're tightly coupling your objects with the eventbus, when you chose to use an EventBus in the first place to decouple your objects [sic].

(oh, and "injecting" doesn't necessarily mean GIN or a DI framework/tool ;-) )

[objectuser]

Not that it's really what you asked (I agree with the replies you've received), but if you're using the idiom shown in some of the Google presentations/samples/vids, instead of direct references to the EventBus instance (which is a class and not an interface ... I don't know why), you may have something like this:

MyEvent.register(...);

MyEvent.fire(new MyEvent(...));

That's pretty convenient, but suffers from the same problem mentioned in the other replies.

I've gone to something like this:

I inject/construct with instances of a class like MyEventBroker, which looks like:

public class MyEventBroker {

  EventBus eventBus;

  public MyEventBroker(EventBus eventBus) { ... }

  public HandlerRegistration registerEventOneHandler(...) { ... }

  public void fireEventOne(EventOne eventOne) { ... }

  public HandlerRegistration registerEventTwoHandler(...) { ... }

  public void fireEventTwo(EventTwo eventTwo) { ... }

  ...

}

I used to have a lot of events, but since moving to MVP, I have far fewer.  Nevertheless, I find it convenient, while YMMV.

Anyway, most of my classes don't need direct references to EventBus instances, just the MyEventBroker instance.  I never liked the static methods I saw in the Google samples.  Statics always seem to bite me if I am not careful, and messing with my testing seems to be one of the first places.

[Alexander Orlov]

Thank you all for your clarifications!

So there are no particular reasons for not using a static EventBus but I agree with Jens that using a static EventBus, hides the fact that a particular View requires an EvenBus. So I'll use the instance version of the EventBus instead of its static version.

On Monday, November 7, 2011 2:36:32 PM UTC+1, objectuser wrote:

Not that it's really what you asked (I agree with the replies you've received), but if you're using the idiom shown in some of the Google presentations/samples/vids, instead of direct references to the EventBus instance (which is a class and not an interface ... I don't know why),

Indeed, EventBus is an abstract class. I suppose GWT devs haven't used an interfaces because EventBus implementes some functionality in two of its methods.