Are there any advantages to switch to Otto from Broadcast events

Question

I stumbled upon Otto, and it looks like it's used as a replacement for Broadcast events. I read the doc but, I don't understand if there are much advantages to use Otto.

Chevrette

Answer 1

Otto should rather be compared to LocalBroadcastManager. This is because the both Otto and LocalBroadcastManager do not support inter-process communication.

Otto's pros:

• Much less code and more readable code.
• Complex objects can be passed through (no object serialization is required).
• Instant value callback via @Producers.

Otto's cons:

• Otto uses reflection, that is why it might be slower than LocalBroadcastManager if you, for instance, send integer values very frequently.

Hornstone

The reflection is memoized so you only pay 90% of the penalty up front. On ICS and up this penalty is basically insignificant. – Templin

Hi Jake, could you be more specific on that? There's some guys at my team said reflection is proved to be slow on Android, thus, Otto shouldn't be used while I'd like to bring Otto's benefits to solve our problems. Is reflection on Otto a problem we should care? – Throwaway

@ThuyTrinh Android reflection was really slow before Android 4. Since then it became much faster. But still, it might slow down your app, if you heavily rely on it. For instance using reflection based injection frameworks will notably slowdown application start up time. In Otto most of heavy reflection lookups are down only once and then cached. Thus Otto is optimized on that regards. However, if you are going send hundreds or thousands events per second you might need to reconsider your design. This is not what Otto was initially designed for. – Hornstone

Answer 2

It may not matter depending on the structure of your app, but Otto also doesn't require having a Context handy to send events or register listeners.

Metaphor

Which means Otto needs to be gained from a a static singleton, which is a pattern still being under discussion. – Muscle

That all depends on scope, I suppose. If your need for a message bus is confined to a subsystem and you're mostly trying to avoid messy and elaborate wiring within it, you may not need a static singleton. – Metaphor

Answer 3

What I don't like about using Otto instead of native instrumentation is that it requires a singleton or the ugly fetch from App's context to obtain an instance. This doesn't change when using a DI framework like dagger. Saving so much code by using annotation and using class based events instead of string based actions is a huge benefit.

Muscle