Experiences using event bus

[Gordan Krešić]

I would like to ask for any advice/idea on how to use event buses in GWT. So
far I'm using GWT's own com.google.gwt.event.shared.EventBus, but wouldn't
have issues migrating to other implementations.

My concern goes to very cumbersome and error prone handling when to
unregister subscribers to allow them to be garbage collected. I'm aware of
ResettableEventBus, but it doesn't solve problems when I don't have clear
events to unregister whole classes of subscribers (if I'm not mistaken, it
was designed to be used inside single Activity and unregister all
subscribers when activity stops, but that flow doesn't work for me, because
I need subscribers active even when they are not in current activity).

When possible, I'm subscribing to events in "onLoad" event and unsubscribing
in "onUnload", but that also doesn't work in not-that-uncommon corner cases
when I need subscribers active even when detached from DOM.

Only "solution" that works is manually unregistering when I'm sure
subscriber is going away, but as I said, that is very error prone (and beats
the purpose of having a garbage collected language).

WeakReference(s) are not supported. Is there any implementation trying to
utilize JS's WeakMap?

Any other ideas?

-gkresic.

[Thomas Broyer]

WeakMap and WeakSet aren't iterable, you cannot discover what they contain, you have to know and can only check if it's in the map/set and for a map get its associated value. This is of no use for an event bus wanting to keep weak references to its handlers.

A WeakRef would be the only way, other than implementing explicit reference-counting.

[Gordan Krešić]

On 30. 08. 2020. 02:19, Thomas Broyer wrote:
>
> A WeakRef would be the only way, other than implementing explicit
> reference-counting.

Bump, didn't even know for WeakRef, tnx.

Support isn't great:

https://caniuse.com/#search=WeakRef

but at least it opens a door for better bus implementation in (hopefully)
not-too-distant future.

-gkresic.

[lofid...@gmail.com]

My favorite for EventBus is this framework: https://github.com/google/gwteventbinder 

In combination with the video, IMHO is the easiest framework for EventBus: Google I/O 2013 - Demystifying MVP and EventBus in GWT

[Gordan Krešić]

On 31. 08. 2020. 23:06, lofid...@gmail.com wrote:
> My favorite for EventBus is this framework:
> https://github.com/google/gwteventbinder

If I'm looking at it correctly, it provides just syntactic sugar on top of
GWT's own EventBus, right? Benefits are obvious, but it looks like they are
limited to reducing code boilerplate.

From what I can see, problem with "ghost" references in event bus which
would prevent subscribed objects from being garbage collected is still there.

-gkresic.

[Jens]

If I'm looking at it correctly, it provides just syntactic sugar on top of
GWT's own EventBus, right?

Thats true,´.

 

 From what I can see, problem with "ghost" references in event bus which
would prevent subscribed objects from being garbage collected is still there.

Right.

But what I don't get is why you don't want to explicitly clean things up? If you rely on WeakRef or anything similar you depend on garbage collection, which isn't really great since you never know when GC will happen and behavior is different between browsers. So if you have an EventBus that uses some weak references it is likely designed as "if nobody has a strong reference to a registered event handler, then remove that event handler from the event bus". The problem is that you can not control GC and as long as GC does not run, these handlers will still get events, regardless if your app still uses these classes or not. So you have overhead until the browser decides to run GC and clean these weak references.

I would try to refactor code to make explicit event bus registration and deregistration easier and less error prone. For example take GWT Activities. The EventBus you get in its start() method is automatically cleaned up as soon as the activity stops. I am pretty sure there are options to build some classes around your existing ones to better deal with EventBus.

-- J.

[Gordan Krešić]

On 01. 09. 2020. 10:42, Jens wrote:
>
> But what I don't get is why you don't want to explicitly clean things up? If
> you rely on WeakRef or anything similar you depend on garbage collection,
> which isn't really great since you never know when GC will happen and
> behavior is different between browsers. So if you have an EventBus that uses
> some weak references it is likely designed as "if nobody has a strong
> reference to a registered event handler, then remove that event handler from
> the event bus". The problem is that you can not control GC and as long as GC
> does not run, these handlers will still get events, regardless if your app
> still uses these classes or not. So you have overhead until the browser
> decides to run GC and clean these weak references.

Exactly what I would like to have, for the same reason I have garbage
collector: opportunity to have less (fragile) code.

Explicit resource deallocation too often leads to resource leaks. Maybe I'm
(and the rest of the team) sloppy, I don't know, but it's simply my
experience. What you described is exactly what we are currently doing, but
in big enough project it becomes more and more difficult to trace lifetime
of objects.

Having weak subscriptions to event bus would require adopting some new
patterns (like just "invalidating" subscriber upon event and do actual
compute in onAttach or some other point in time when it's acknowledged that
results from caller are actually needed), but from my current experience I'm
confident enough it would result in more robust code base.

I'm not saying that I might not be wrong, but I would like to try.

> I would try to refactor code to make explicit event bus registration and
> deregistration easier and less error prone. For example take GWT Activities.
> The EventBus you get in its start() method is automatically cleaned up as
> soon as the activity stops. I am pretty sure there are options to build some
> classes around your existing ones to better deal with EventBus.

We tried that, too, didn't like that background activities are cut of from
event bus and also propagating ResettableEventBus instances to every single
one of widgets used in that activity results in lots of boilerplate.

-gkresic.