Added ThreadMode.MAIN_ASYNC to queue event delivery for a future loop of the Main UI Thread.

[william-ferguson-au]

Added ThreadMode.MAIN_ASYNC to allow a subscriber to declare that it wants to be called in the Main UI thread but the event should be queued for delivery by a future Main UI loop.

Ie MAIN_ASYNC subscribers never received delivery directly from the poster's thread, even if it is the Main UI thread.

This ensures that events sent to MAIN_ASYNC subscribers are delivered in the order in which they are posted, regardless of the poster's thread. Extremely useful for ensuring that events that denote steps in a process (eg beginning, end) and are used to present UI state are delivered in the order in which they are created.

This is a solution for #307 that allows existing behaviour to continue.

[william-ferguson-au]

The intent of an EventBus is to decouple event emitter from event consumer. By posting an event on the same thread as the emitter you are coupling the emitter to the consumer based on execution context. It is overriding the execution context explicitly defined by the subscriber.

The contract that the emitter has with the EventBus is that the EventBus will accept delivery of an event. The emitter expects this to be a quick operation and is not expecting their thread of execution to be highjacked by some unknown subscriber that happens to want the notification in the same type of thread.

The contract that a subscriber has with the EventBus is that it receives the events in the order in which they were posted to the EventBus.

IMHO there should only be 2 delivery modes MAIN_ASYNC and ASYNC. This would greatly simplify the EventBus. It would also simplify the semantics of emitters and subscribers.

[greenrobot]

We'll look into this.
Tests for this behavior are missing, @greenrobot-team can look into that.

[patton73]

Thanks a lot for your effort.
I would say that If order of events is not guaranteed then the bus has a real problem. Hope this will be fixed as well.
Thanks.

[greenrobot-team]

This is now also part of the plain-java-new branch, including a test. This is expected to be in the 3.1.0 release, we welcome your feedback. -ut