Need to explicitly remove event handlers manually?

[macagain]

Is it required or even good practice to manually remove event handlers
(say, on detach or unload)? I.e. keep the handlerRegistration around
when returned from addHandler, then later call
handlerManager.removeHandler().

Of course in the old world of manually managing listener collections,
one had to do it, but in the new world of HandlerManagers?

[rjcarr]

If you no longer need the handler then yeah, you should remove it,
because you don't want to execute code blocks (onClick()) that are no
longer needed or used.

But it certainly isn't required.

[Brian Reilly]

I'd say that cleaning up no longer needed handlers is just as
important as closing open files when you're done or freeing memory
that you've allocated. You won't notice the effects at first, but
eventually you will. How soon depends on the cases under which your
application creates handlers). Eventually, you'll see event delivery
taking longer and longer because your event bus is busy notifying
handlers that you don't care about anymore.

There's a reason why the handler manager goes to the trouble of
returning a handler registration. There's no way for it to know that
you're done with the handler. This is one of those cases where garbage
collection wouldn't even help you because the handler manager has to
hold a reference to the handler (unless you use weak references, but
I'm pretty sure we don't have those in the JDK emulation layer). 

It's not too difficult to keep track of handler registrations. I often
make a collection to hold them. Just add them all to the collection in
your bind method and unregister everything (and clear the collection)
in your unbind method.

-Brian

[Tsukasa]

This really is one more useful point which would make closures nice
but we should wait for JDK 7 or later for this.

I already ran into some of issues according handlers I missed to
unbind. Therefore it would be nice to find a way to avoid this
destructor-like (java uncommon) coding pattern. I think there should
be an easy way, but actually I haven't had enough time to figure it
out yet and provide an idea for a soultion.

[Paul Stockley]

I've stepped through the code and there is no requirement to
unregister handlers explicitly. Each widget has a handler manager (as
member variable) that manages its handlers. If a widget is removed
from its parent or its parent explicitly clears it then the registered
handlers will get cleaned up by normal garbage collection.

This is not the case if you are using a global handler manager for say
an event bus. If handlers are added that are specific to a particular
presenter then the presenter needs to remove the handlers when it is
destroyed. I implemented a Place Manager that takes care of all of
this automatically along with history support.

[Tsukasa]

exactly that is what my workaround was ... on any place change I call
unbind() on the active presenter before changing to the new one. But
what I intend to have is no need for any unbind() method at all.
In my opinion its the eventbusses concern to recognize that the
eventHandler should be detached, when its presenter is not existent
anymore. But perhaps this is way to much functionality or the wrong
layer of abstraction I expect of something like the HandlerManager