Canceling Events only work partly

If you call EventBus.cancelEventDelivery() the ‘event’ won’t be canceled completely. Only subscribers, who have subscribed to exactly that event class (and not a parent one of that) won’t get notified. If you have e.g. an onEvent(Object ev) listener and canceling sending of MyCustomEvent in an onEvent(MyCustomEvent) the onEvent(Object) method will still receive it. This is (imho) pretty unexpected behavior.

The error lies here: https://github.com/greenrobot/EventBus/blob/master/EventBus/src/de/greenrobot/event/EventBus.java#L482

Your break only break out the inner loop (subscribers for this class) and not the outer loop (all parent classes of the current event). You should also break out of the outer for loop.

Didn’t know if you wish a labeled loop or putting the abort to the for condition, that’s why I didn’t send a pull request (and because it’s anyway such a small change).

Unfortunately I didn’t find a workaround till this is fixed, to really cancel an event. It seems like you have to keep an own list of canceled events if you use event hierarchy.

I hope the fix can be published soon 😃 Thanks guys for the great lib.

[william-ferguson-au]

It sounds like you are either a) attempting to have an Event represent two or more discrete events b) have created a Swiss army knife consumers that is trying to respond to an event multiple times in distinct ways.

The first is solved by separating your Event into the underlying Events it actually represents and post them each in turn.

The second is solved by combining the functionality in the multiple subscriber methods in your consumer is a single subscriber for the concrete Event class.

I wouldn’t be (and we don’t) use Event inheritance at all. Instead all subscriptions are for a concrete Event class. It makes it very easy to determine who the producers and who the consumers are when you want to start aggressively refactoring.

You also gain certainty about execution order, because you are never wondering which subscriber is called before another as there is only one subscriber (in a consumer) for an Event.

There’s more, but those are the highlights.

[Panthaaaa]

I don’t think to solution to a buggy feature is to just stop using it. IMHO it’s really helpful to use event inheritance in larger applications (i.e. complex event hierachies) to manage the complexity.

I will add a pull requests with a fix, so this could be integrated into one of the next versions.