RxJava VS simple-stack

3. RxJava This repository contains the source code for ReactiveX, a library used to create asynchronous and event-based programs with observable sequences. https://github.com/ReactiveX/RxJava

Is this similar RxJava, the reactive extensions library for https://github.com/ReactiveX/RxJava ? I have made that work in Clojure in production.

Since you mentioned java, there is RxJava and RxAndroid. Google general recommendation now is to use kotlin coroutines if you're considering writing your app with that.

It's very quick though. In terms of the correctness of the syntax, I've never seen an issue while translating a single file or a single function. When I took the entire RxJava code base 5 years ago, right clicked on the source folder and converted to Kotlin, I found lots of problems. File by file I've never seen any issues though, but I also haven't done it much.

You all beat me to MapStruct and Testcontainers. Honorable mention to RxJava, which I use in Desktop apps.

RxJava with RxRelay (and rx-combinetuple-kt)

RxJava2

More information about rxJava, check it out here: (HERE)[https://github.com/ReactiveX/RxJava]

Concurrency: Kotlin coroutines for general use, Rx or Flow for reactive programming (you can technically use Rx for regular concurrency as well, but not really what it's meant for)

If you're just looking at making a service call on a regular interval and notifying the user when there's an actual change in data, you can also look into RxJava https://github.com/ReactiveX/RxJava. From here you can "subscribe" to your service call, and then every time you make your service call you can have it look for changes compared to the previous emission .distinctUntilChanged() and then only notify it's subscribers when it notices an actual change. From there you can trigger a local notification and push to a LiveData (assuming MVVM) or otherwise update the UI to match as well.

As someone who had been using single-activity since 2015 (a'la Flow) and eventually just rewrote the whole thing to fix all the bugs we had with it in 2017, I find it sad that the single-activity approach was questioned not because it was harder, but because people made their own lives harder. And then Google made their lives harder.

I've been using single-activity but with Simple-Stack since 2016 and never deprecated it because Navigation just has these quirks that impede you a lot. I know how to use it but wouldn't really pick it.

This is why we've been using https://github.com/Zhuinden/simple-stack and it was never deprecated. We've been using it for 6 years, I'd say there was a critical bug but it was fixed in 2.3.1...

I mean, we use Simple-Stack because it makes things easier, if it didn't we'd have ditched it long ago https://github.com/Zhuinden/simple-stack

Agreed. I also added support for it 2 weeks ago.

I don't, because we use this and it's better than activities+intents 😅

We've been making single activity apps with https://github.com/Zhuinden/simple-stack and it has been easier than multi-activity.

I still use https://github.com/Zhuinden/simple-stack to this day, although I still use it with fragments.

I have been using Fragments instead of compound viewgroups lately with simple-stack as the navigator for the single-activity, although I need to figure out how to switch to use onBackPressed+onBackInvokedCallback and not just onBackPressed.

You can think of Simple-Stack as a direct successor of Mortar+Flow.