EventBus vs Callbacks, which to use when?

I would go with the EventBus because of the loose coupling and cleaner code. Also, the fact that using an EventBus such as Greenrobot automatically does all the boilerplate for me and allows me to register & deregister observers right from Activity Lifecycle methods (onStart and onDestroy|onStop) is great. Implementing callbacks and still managing to control Activity lifecycle management for those callbacks is an unnecessary headache and involves a lot of unnecessary boilerplate.

Also, apparently all garbage collectors think weak reference is great-Event bus gives your observers and components exactly that. Its the basis of the Observer pattern.

You should check if your event is globally unique on the semantic view. Either an subscriber is interested in the event or not. If not he shouldn't subscribe.

Event-Bus mechanism is right if you really have a publisher-subscriber relationship. The event must be totally independent of the receiver.

So a subscriber that discard the event for any reason of responsibility ("I am not responsible the event even if I am registered") is a strong indicator that using an Event-Bus is wrong. Then you should consider using dedicated listeners.

I disagree with @nnuneoi's answer.

Event bus has just one single advantage: it allows for communication between components which are "unaware" of each other's existence.

And there are several disadvantages:

1. The components become loosely coupled by dependency on both event bus and specific event type
2. The coupling described in #1 above is not strong
3. The coupling described in #1 above is not evident
4. Event bus introduces performance overhead over simple callbacks
5. If event bus holds a strong reference to subscribers (as is the case with e.g. GreenRobot's EventBus), then unregistered subscribers will cause memory leaks

Given all these disadvantages, simple callbacks should be the default implementation choice.

Event bus should be used only when direct coupling is not desired or hard to implement. For example:

1. Sending events from Service to Activity
2. Exchanging events between independent Fragments
3. Application wide events (e.g. user login/logout)

If the communicating components are already "aware" of each other's existence, there is no need for them communicating via event bus.

Benefits of using EventBus:

• Your code will look much more clean
• Your code will become more modular which will allow you to easily create test case for your code
• Avoid memory leaks from bad object references which lock the object and does not allow Garbage Collector to clean it up
• Could have more than one receiver a time, that it much like broadcasting
• Simplify multiple interfaces into a single one, EventBus
• In an interface class, you need to override every single method in the class that is inherited. With EventBus, you can listen for just an event that you really want

But bad part is you might be a little bit more headache with the function declaration since IDE couldn't help you with auto-complete.

My suggestion is, if you find that you have to create a custom listener, then please consider EventBus, it might be a better choice for most of (if not all) of your requirements/cases.

Anyway, it is all your choice after all =)