Context and The Problem.
At my current company, we have a wholesale app designed for tier-2 or tier-3 city Kirana (grocery) stores to purchase goods at wholesale prices. Because this is a B2B integration, there are a lot of offer popups, nudges, notifications, and feedback popups each time a user opens the app. That’s a poor user experience: bombarding the user with multiple things on app startup is not ideal, and doing so all at once is particularly jarring.
To illustrate, imagine you’re using a food-delivery app that needs to show several messages: first asking for location permission, then introducing new features, then asking for a rating—all shown at once. That would be annoying.
What is EventBus ?
That is where EventBus comes into the picture. EventBus helps widgets that are not directly related or screens that aren’t dependents of each other communicate with one another.
For example.
A user completes an action on Screen A (e.g., saving a profile update), and Screen B (e.g., a settings screen) needs to be refreshed or updated to reflect this change. Instead of passing callbacks or using shared ChangeNotifiers that can become unwieldy, Screen A can fire an event, and Screen B can listen for it.
How EventBus was useful for us ?
Because there were multiple popups that were compiled and shown to the user at the same time, using EventBus allowed us to display them in a sequencing order. An additional enhancement was that once a popup is shown, we check whether the next popup in the sequence is available. This prevents the user from waiting for data to fetch for the next popup and allows it to show immediately when ready.
This is like having a smart assistant that presents a series of popup messages on your phone, one after another, in a specific order, waiting for you to close each one before showing the next.
Think of it like a queue at a restaurant where the waiter brings dishes in a specific order. The system has a list of all the popups it wants to show (A, B, C, D), but it’s smart enough to check if each popup is relevant right now. For example, if you’ve already granted location permission, it won’t show that popup again. It only shows popups that make sense for your current situation. When you close one popup, it automatically shows the next one in line, creating a smooth, organised experience instead of bombarding you with multiple popups at once.
I have added a demo implementation of EventBus in this Github repo do check that out.
Different use cases that I can think off
- Changing App Theme
- Scrolling/Refreshing list to top when user clicks on bottom navigation tab bar (WhatsApp, Instagram, many of such social medial app have this functionality)
Limitations of using EventBus
Debugging Complexity - Events can be fired from anywhere and received by multiple listeners anywhere else in the application. This "publish-subscribe" model can make it challenging to trace the exact path an event takes from its origin to all its destinations.
Global State Issues - Because any component can subscribe to any event, it's easy for a component to react to an event it wasn't designed to handle, leading to unexpected behaviour.
When to use EventBus ?
You have truly global, infrequent, and lightweight notifications that affect multiple
When an event can affect a varying number of components, and the publisher doesn't need to manage the list of subscribers.
In larger applications, different modules or features might need to communicate without having direct dependencies on each other.
Alternative to EventBus
Direct Method Calls / Function Callbacks - calling component directly invokes a method or passes a callback function to the component it needs to interact with.
State Management - Provider, BLoC/Cubit etc
Navigation and Route Arguments - When navigating between screens, you can pass data directly as arguments to the new route.
Bottom line: Your app shouldn’t rely solely on EventBus. Use a combination of the alternatives above as appropriate.
Top comments (0)