Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
> Also, using the HTTP handler's thread to process business logic _blocks that thread_ and makes it unavailable until the logic is done running - which could take a long time
This is true.
> if your users in Bangladesh are using cheap $20 Android phones over 3G connections you still have the same problem and you won't be anywhere near 32ms.
This is of course the crux of the issue. In my opinion, either wait until the infrastructure catches up, or don't write an interactive networked service, for that audience.
Anyway, to at least advance the conversation, I searched for some big open source projects that use EventBus. (https://grep.app/search?q=org.greenrobot&filter[path.pattern...). Signal for Android is a good example (https://grep.app/search?q=org.greenrobot&filter[repo][0]=sig...).
Let's just take a look at the first class that appears in search results. "SqlCipherMigrationConstraintObserver." Okay, how in practice does this random thing get registered on the EventBus?
Oh look, it's a file that is just instantiating a bajillion classes: (https://github.com/signalapp/Signal-Android/blob/master/app/...) Because dependency injection is stupid on GUI applications, and it messes with all sorts of benefits of direct invocation, ... they do direct calling anyway. Except, instead of just like, calling whatever it is they need in SqlChiperMigrationConstraintObserver (or I don't know, just using a Subscription, it's literally called an Observer), they do the same exact work just in a more puzzling way, via instantiating in one class and invoking in... who knows where.
Again, this is why I say toxic. You're going to poke around the repos of what's going on when people actually use EventBus, and you'll discover, in the long term, that people will end up doing O(~direct invocation) work anyway, but stringly typed (or in this case, annotatively typed).
1. I'm happy to see that EventBus has made this change. Let's hope the long overdue AndroidX migration (we're three years into AndroidX, folks) follows close on its heels.
2. Event buses are really, really bad. (At least, this kind of event bus is) The Android community has some battle scars on this, so I'll drop a little history for the broader audience here.
Event buses were an architectural fad that were briefly explored to address the challenges of communicating in the immature application architectures of the era. The maintenance lifetime of Otto, a competing event bus, is a good reference point for when they might have been considered reasonable practice: 2012 through 2015: https://github.com/square/otto/tags
This tool was abandoned by leading edge shops when they saw how rapidly it could make a complete hash of any thoughtfully laid out architecture. Connections made in an EventBus based application tend to be many-to-many, without the sender of an event having a direct reference to its recipient or vice versa. This is incredibly irritating to debug, and breeds communication patterns that are challenging even in a disciplined codebase. In an _undisciplined_ codebase they can be breathtakingly byzantine, even in small scale development.
Instead of using this, many leading edge shops started switching to RxJava at around 2016. RxJava is a powerful tool with sharp edges and a steep learning curve, but the need was so imminent and the failings of the existing EventBus-style tools so clear that it caught on. Indeed, while Google understandably felt it RxJava was too complex to recommend as an introductory tool, their first party LiveData tool released a few years later was essentially RxJava with the edges sanded off.
Of course, we're not even further down the road than that. Kotlin coroutines presents its own paradigm shift to contend with, but it's a clear step up from all the other solutions, and has Google's blessing as well. There's not much reason to start new development on top of anything except coroutines.
So where does that leave EventBus?
EventBus is at this point about as legacy as you can get without going all the way back to AsyncTask. Anytime I'm doing a code audit and see this dependency, red flags immediately go up: not only is it a sign that this code is far behind the times, but it's also a flag that I'm going to find some truly unfortunate and problematic design decisions.
People need what they need, and it's of course good to see critical dependencies for legacy applications get upgrades. But I can't recommend strongly enough to avoid this tool.
> But since you own the code, you own 100% of the source in your GUI application, why would you need indirection?
So what is your proposed non-indirection way? I'm assuming you meant the traditional listener/observable way of registering event producers and event listeners together, in which case this FAQ explains pretty well their downsides compared to an event bus:
https://github.com/google/guava/wiki/EventBusExplained#faq