-
Notifications
You must be signed in to change notification settings - Fork 28
Allow unregistering of handlers on a per-event class basis #4
Comments
If we let you to remove handlers by event then the next thing will be to provide an API to add them back. |
Yeah, I agree with Goktug here. It's a lot easier to reason about how your class will work when either all @eventhandler methods are active or none of them are. Selectively removing handlers can make for really frustrating debugging when you're trying to figure out why one of your handlers isn't working and the rest all are. If you want to be able to remove an individual handler, there's no reason you can't add it directly to the event bus and manage it outside of EventBinder - mixing @EventHandlers with normal calls to addHandler works fine. That way you can remove individual registrations while still having confidence that things declared as @EventHandlers will continue to work reliably. Does that solution work for you? |
My opinion is different, it is not unusual to have visibility handlers that are added and removed automatically depending if something is shown or not. I've made the proposition into a post to be able to specify the EventBinder on wich a EventHandler can be bound simply by adding a parameter inside the annotation that takes the .class of the EventBinder to register the events. |
@christiangoudreau, can you provide more concrete examples for your use cases? |
Dynamic places, Dynamic tabs (linked to places), other cases when you want only the visible presenters to update when an event is thrown. (Servers update) Etc. Doesn't happen often in simple apps though |
According to EventBinderTest, when
presenter.handlerRegistration.removeHandler()
is called, all handlers are unregistered, regardless of the event's type.It would be awesome if one could unregister only handlers of a particular event type, e.g.:
presenter.handlerRegistration.removeHandler(SecondEvent.class);
The text was updated successfully, but these errors were encountered: