2

I've been using Otto event bus for a while and it's been great. Can you think of any disadvantages to using it over a BroadcastReceiver implementation within a package, or over a more traditional interface listener pattern?

For example, Google recommends having the host activity for fragments implement an interface from which the child fragment can call on its host activity. This is great, except it's even easier to do with Otto. The only thing I can think of that having an interface can force some events to be implemented, but based on the ease of use of Otto I don't really mind just being careful to listen to what I want.

SIr Codealot
  • 5,331
  • 9
  • 33
  • 45
  • Well, there are alternatives for Otto but beyond that I see no reason not to use it if it works for you. – harism Feb 17 '15 at 15:57

1 Answers1

3

Google suggest that because they can't just suggest people to use other libraries. Their suggestions are always based on how it can be done inside Android OS without any extra libraries (apart the support libraries).

There's a fraction of a performance hit (really small) because otto uses reflection instead of compiled code, but, Otto also caches the reflected "stuff" so this tiny performance hit only applies to the first time a certain event class gets fired.

As you mention, there's contract enforcement that a interface do, but considering the ease of use of Otto, it pays to just code a bit extra careful.

LocalBroadcastReceivers could be an alternative, but considering all the code to create the intent, intent filters, etc, it's just not worth it.

So IMHO, yeah, go forward and use Otto everywhere (we're doing it on the app I currently work on that have avg 920K active users a month)

Budius
  • 39,391
  • 16
  • 102
  • 144