I am planning to add Otto event bus to decouple my communications. One of the things I want use event bus for is to communicate between a button click handler and the activity.
The idea is that the button click (from my custom view) would generate a text submission event which would notify the activity. The activity would then decide what to do with it. If the activity deems it proper, it would send the text to a service for upload or whatever.
Is this a proper way to use an event bus?
Also, what are some good practices when using event buses?
I still think this question should be closed as not proper for the StackOverflow model.
But for anyone looking on how on can organize user events around a Bus, that's kinda of how we've done on the place I work.
Remember, that type of structure only makes sense if you're creating a big project where achieving a high level of separation makes the life of a team of developers easier. For small, quick projects or test apps that's too much effort.
PS.: all the code below is typed 100% by heart without checking any real code, so there will be typos and small errors, but should be enough to get an idea of the approach. I also didn't write any annotation like
@override
, too lazy for it.First: Activity overrides
getSystemService
to supply a Bus via Context and register/unregister event handlers as needed.Then: You have all the
RecyclerView.ViewHolder
(or custom widget) to be the click listener and dispatch appropriate events. For example in a ViewHolder for a photo item.and the last of course: is to create those events objects and add all the events to your appropriate handlers.
finally, handling events
a handler for navigating:
a handler for analitics:
I agree with some of the comments that it's possible to create a huge, weird spaghetti code when having "tap" events going through the bus. But if from the start a good structured approach is defined and all the developers follow it, you can achieve a project that is easy to follow and with a very clear separation of responsibilities.