EventBus 3.1 with plain Java support
Calling methods via strings where you control all the source code to your own application is pretty toxic.<p>Since there are no network or persistence boundaries - it&#x27;s a local app the developer owns 100% of - there are no engineering constraints that require the kind of decoupling of an event bus.<p>The execution boundary thing (&quot;post messages to other threads&quot;) is also pretty dumb. There are a dozen simpler ways to coordinate between a UI and background &#x2F; business logic thread. Since most application&#x27;s long-running behavior is <i>only</i> HTTP calls, today&#x27;s developer doesn&#x27;t have to think about it at all - the callback or promise (CompleteableFuture) returned by their URL fetcher forces them to do the right thing.<p>RxJava is almost always the better choice to be more expressive about UIs. Otherwise, an Android developer should adopt Kotlin for coroutines. Or, frankly, reduce timeouts for HTTP calls to be closer to frame rendering times (16-32ms), pay the extra pennies to serve networked services better, and focus on low-latency remote APIs.