Otto vs LocalBroadcast:

Chris picture Chris · Apr 4, 2014 · Viewed 8.8k times · Source

I am a huge fan of open source contributions square has done to the Android community and was looking into their latest contribution Otto (event bus )

http://square.github.io/otto/

Digging deeper I see that Otto uses reflection and there is no ordered broadcast ( a pattern where a unconsumed message is handed down from one receiver to the next receiver listening on the same type of event ) Otto believes in more of a fire and forget model .

Now android has LocalBroadcastManager (LBM ) in its v4 support library which serves the same purpose , though it's more bulkier and has more restrictions on the objects that are passed . But on the brighter side it does support ordered broadcast and its more akin to the normal broadcast.

Both Otto and LBM are within the same process space so in terms of speed I guess both would be same. The only real difference I could see is that Otto allows you to define custom events and you do not have to serialize/Parcel the Objects .

Hence my real question is when would you use Otto if LBM does the same things .

References :

http://nick.perfectedz.com/otto-event-system/

Using Intents or an event bus to communicate within the same app

https://plus.google.com/107049228697365395345/posts/6j4ANWngCUY

Answer

CommonsWare picture CommonsWare · Apr 4, 2014

But on the brighter side it does support ordered broadcast

Not really. There is no sendOrderedBroadcast() on LocalBroadcastManager, and the priority on the IntentFilter does not appear to be used. If you mean "the broadcasts will be delivered in the order that I registered the receivers", that might be the current behavior, but there is no guarantee that it will stay that way.

Both Otto and LBM are within the same process space so in terms of speed i guess both would be same

They would be similar, though probably not identical.

Hence my real question is when would you use Otto if LBM does the same things

Comparing those two, Otto has a cleaner API, IMHO.

Personally, I'd use greenrobot's EventBus over either of those, because it offers more flexible threading models.