Otto vs LocalBroadcast:

Question

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

Cowhide

Answer 1

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.

Zahavi

Yep I stand corrected,there is no sendOrderedBroadcast() on LBM , Its the way i register the receivers . Will take a look at greenrobot's EventBus as well . Thanks for the tip – Cowhide

GreenRobot seems really interesting especially the post sticky part. do you recommend it is used to solve orientation changed problems? fo example to make sure the activity will always get the result from a service after recreation is done? a simple example would be to add a service call to a queue using volley to retrieve some data, after that i rotate device ... then result from volley is returned and posted using greenrobot as a sticky broadcast, while my activity is not created yet(being restart) the activity restarts and then can retrieve the data needed. u think this seems legit ? – Valentinavalentine

@NaderAyyad: If the activity would be receiving this data from the service via EventBus messages anyway, then sticky events may be useful for configuration changes. – Zahavi

@Zahavi yeah its good for that, but would it be useful to use to after orientation changed to check if the result has been sent from the service or not? since at a certain point a service can return the data for the activity but the activity will not be there. using sticky will make sure , if the activity is not ther to keep the data for when the activity is recreated, did u ever use it that way? and are u able to remove the sticky after u consumed it? – Valentinavalentine

The release and recreation of the activity will happen one after the other in the event queue, so the event from an external source won't be processed in between the two. – Bratwurst

@Zahavi What would you use now? Since RxJava and RxAndroid is also another option(Otto is also deprecated in favor of it). LBM vs EventBus vs RxJava? – Bivalent

@VishalKale: Ah, I missed Otto's deprecation, thanks! The "bus" implementation in Rx described in the blog post linked to from the Otto repo is limited. I have not researched alternative event bus implementations in the Rx space. So, I am not qualified to say whether there is a quality Rx alternative to the classic event buses. At the moment, I still use greenrobot's EventBus. – Zahavi

Answer 2

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

I've found that registering Otto events are quite expensive, sometimes it takes more than 16 milliseconds to register event subscribers (That means you drop 1 FPS!). That's somewhat expected, as event subscribing in Otto is done by reflection. While for LBM, it only takes a few hundred µs only for registering, which is almost 32x faster. (Result from traceview, Samsung Galaxy S4)

But of course, using Otto can write less code, there's a trade off.

Administer

Answer 3

1. otto makes code cleaner, smaller
2. otto makes testing easier

Shandrashandrydan