Hi all, A while ago there was someone asking about eventbus libraries and all answers were about not using any kind of eventbus libraries, I want to know what should we use instead of eventbus libraries.

This doesn't seem like a topic that's specific to Kotlin

@jw Where should I ask like these questions? Knowing that the person who asked the question asked here on kotlinlang workspace

#android-architecture ? Might be more helpful to describe problem you are attempting to solve

there’s nothing wrong with using an event bus, i think years ago people in the community were burnt by the libraries because they were using them for things that didn’t require a bus

GreenRobot’s EventBus (https://github.com/greenrobot/EventBus) works really well, but it’s not kotlin-specific. In a kotlin-world, callbacks are so easy to create that you could probably make one yourself perfect for your needs in just a few lines of code. However, I would strongly suggest you try to make a solution based on normal Kotlin callbacks, coroutines, or some other mechanism. Event-bus architectures tend to get messy and hard to follow the flow of data, which makes it hard to maintain.

event bus doesn't scale past 1 class. avoid.

surely it scales past 1 class, the whole point is communicating between classes

i spent 2013 telling people to use event busses and using it myself. it's the single biggest architecture mistake i've ever made and it took years to fix it. avoid.

I 100% agree with Jake, and I’ve been in a similar situation. Looked great at first but didn’t take long to start causing a lot of problems. My team is still working to remove the event bus from our app, but it’s pretty hard to remove once it’s there. You can kinda make a half-decent event-bus-based system if you’re very disciplined and don’t overuse them, but they are just too tempting and make it too easy to not implement proper abstractions. They will get out of hand, and it’s best to just avoid the temptation altogether. Event busses can pretty much always be replaced by something better, you just might have to think a bit more about the problem you’re trying to solve.

For the majority of things it'd be overkill, yes. Blanket statements about event buses being bad are inaccurate though. It's like any other tool, if you need a hammer when you needed a screwdriver you're going to have a bad time

event busses are a hammer pointed at your face. it offers nothing that semantic streams of events which are directly connected and managed globally in a service locator or dependency injector or even as big ugly static variables in your Application subtype don't do better. Put a public static LiveData variable for each semantic event type in your application class and you're already doing better than an event bus. they are the worst qualities of callbacks, streams, and service locators rolled into one. the whole is worse than the sum of its parts. avoid.

How about LocalBroadcastReceiver

well that's an event bus which uses intents instead of types which is pretty horrendous from a developer UX perspective

@jw I am currently using an event bus for communicating from a service to an activity. What would you recommend as a replacement for that?

I will suggest to have shared view model with live data to share data across activity to fragment and fragment to fragment, if your working with service you can have a live data there as well and access it though ibinder/messenge API , for activity to activity using intents parselable would be fine.

@kevindmoore I'd recommend a

ConflatedBroadcastChannel

, or a

BroadcastChannel

.

You almost certainly want something lifecycle-aware