3 ms·

I find your comment overly dismissive of EventBus and I respectfully disagree with you on not needing to decouple components for a local app. I've worked with

I find your comment overly dismissive of EventBus and I respectfully disagree with you on not needing to decouple components for a local app. I've worked with GreenRobot's EventBus on a large (100M+ installs) app years ago. I worked with RxJava as well. I've also worked with more feature-rich proprietary solutions to EventBus. EventBus is a library with a straightforward API that junior developers can use with little issues. "Launch this event and add this annotation to make sure it gets processed off the main thread". This is a very real practical advantage, that is not unique to EventBus, but it works well for large teams and does not require you to rewrite methods to return Observable objects just to be able to chain some things together. Does EventBus lead to some eventual problems? Yes. Are they manageable? Yes. On the other hand, RxJava is a framework and, once it's in, it starts spreading Observables through all the classes in the codebase. Most developers need significant time to ramp up to become productive with it. I used to work with 30+ developers on an Android app. The app I work on now at a different company has thousands of developers working on it. People at these companies collectively concluded that RxJava doesn't bring sufficient benefits to these large teams. Both companies have ripped it out pretty quickly after the initial excitement wore off and the downsides started kicking in. Kotlin made things much better in the recent years, but it doesn't mean that EventBus is now 'dumb' or 'toxic'. Coroutines on Android weren't widely used in these large apps a few years ago, before Google announced official support, so people were calling "new Thread()", using AsyncTask or, more likely, having ExecutorService threads created by various components in the design without any regard to CPU contention or priority of execution, and instantiating "new Runnable" all over the place. 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. Boundaries for execution are absolutely required, unless you're working on a small app that doesn't need to care about these issues and where pretty much anything goes. You want to have control over which logic runs on which thread, otherwise you'll needlessly spend time debugging race conditions and deadlocks in production, like me. HTTP threads for delivering HTTP results, image threads for processing images, database threads for writing to the database, and you want to set priority for background, I/O and foreground threads. That last point you have about reducing timeouts to be closer to frame rendering times is also incredibly narrowly useful. You can invest a ton of time and have the server respond in microseconds but 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.

an_opabinia 5y ago
> 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][0]=.gradle 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]=signalapp/Signal-Android 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/src/main/java/org/thoughtcrime/securesms/jobs/JobManagerFactories.java 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 invocation 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). RxJava has its significant downsides. It's still indirect, it's very hard to debug call stacks with them! RxJava call stacks are meaningless. This is the right criticism. The wrong criticism is, "Bad developers can't handle it."
- randiRando 5y ago
  I agree with your take on event busses but I feel like it describes RxJava pretty well too. > RxJava has its significant downsides. It's still indirect, it's very hard to debug call stacks with them! RxJava call stacks are meaningless. This is the right criticism. The wrong criticism is, "Bad developers can't handle it." How about "It's still indirect, it's very hard to debug call stacks with them! RxJava call stacks are meaningless" and because of that bad developers can't handle it ? Context: Have worked with RxJava (1&2) for about 6 years on different products and I agree that Rx is powerful but it's incredibly easy to over-use and abuse to the point of being a net-negative for a codebase. I think it takes a very disciplined developer to work with Rx. I love/hate Rx

an_opabinia 5y ago

> 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][0]=.gradle 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]=signalapp/Signal-Android 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/src/main/java/org/thoughtcrime/securesms/jobs/JobManagerFactories.java 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 invocation 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). RxJava has its significant downsides. It's still indirect, it's very hard to debug call stacks with them! RxJava call stacks are meaningless. This is the right criticism. The wrong criticism is, "Bad developers can't handle it."

randiRando 5y ago
I agree with your take on event busses but I feel like it describes RxJava pretty well too. > RxJava has its significant downsides. It's still indirect, it's very hard to debug call stacks with them! RxJava call stacks are meaningless. This is the right criticism. The wrong criticism is, "Bad developers can't handle it." How about "It's still indirect, it's very hard to debug call stacks with them! RxJava call stacks are meaningless" and because of that bad developers can't handle it ? Context: Have worked with RxJava (1&2) for about 6 years on different products and I agree that Rx is powerful but it's incredibly easy to over-use and abuse to the point of being a net-negative for a codebase. I think it takes a very disciplined developer to work with Rx. I love/hate Rx