lmao that comment about rx, whats next, dont write unit tests because only bad devs make bugs? 😄 rx is amazing, general android app code is much better because of it, and actually handles much more, where before race conditions would be yolo and only fixed when bugs reported etc. or doing stuff from callback of something else, that needs certain conditions to happen. before this would be if !conditionsOk return, and yolo most of the time

In many cases, you can do easier (to write and read), an safer with Kotlin #coroutines. Rx, especially RxJava(1&2) is extremely complicated, and non natural when what you want to do is just doing some processing off the main thread, or wrap a few callbacks.

sure..rxjava predates cooroutines, and is superset of cooroutines, so, same thing different api

It depends how deep you know RxJava is.

sure, im. not arguing against cooroutines

@louiscad, RX java isn’t complicated. I think everything is hard until you learn it. Also the use case for RX Java vs Coroutines, is completely different. A better argument would be, Coroutines vs Threads…

oh trust me rx can be complicated 😄 but yea I see what you are saying that most people are using it just as asynctask, such a waste. .. never said rx and cooroutines were the same

@rkeazor Coroutines are about removing callbacks hell, which includes thread switching and concurrency. They allow sequential, yet asynchronous code. A lot of people use RxJava for these very same reasons only, but this ends up in many inefficiencies compared to what they could do with just coroutines (memory-wise, but also regarding effort needed to read and write such code).

@louiscad Ahh, no Corutines are not about removing callbacks lol. Like you wouldn't replace a onClickListener with a coroutine lol. And Rx uses call backs under the hood. . Corutines is all about concurrency.Suspending functions, deferred function, async await, that's all concurrency. They are not the same thing. You do know there is a coroutines extension for Rxjava. They are different. They solve different problems. There is no comparison to be honest. The debate your looking for is between Coroutines and Threads...

I dont see how cooroutines is better perf / memory wise, isnt that just an abstraction thats sitting on top of java threads, sort of like rx schedulers are

Man both RxJava and Couroutine has their respectively advantage. For example A is Rx and B is Couroutine. But both of them can works for same cases. There are cases that we should use Rx and there are cases we should using Couroutine. Under the hood Rx is promoting Observable Stream Chaining, and Couroutine is promoting light weight thread. For example the similarly both Rx and Couroutine are. Rx Publish Subject is equal to Couroutine Channel. Rx Behavior Subject is equal to Couroutine ConflatedChannel. I can give you more examples. But, you should working by using both of them to know how both works.

Right, Both are good for what they do. Rx java is great for manipulating streams of data . Coroutines is way better than Threads and executors

Correct

I dont even know what we are talking about, im avid rx user and wont switch to cooroutines lol, I just reacted to that google nonsense, and how rx improved my code

Use connectable observable @ursus

@rkeazor Actually, I have a function like this:

suspend fun View.awaitOneClick(…)

which has use cases in my codebases, and it sets an on click listener 😉

awesome. @louiscad

@radityagumay well that requires the obs. instance to be placed in some layer above viewmodel. I dont like retaining because then I cannot have any view references or transitive a activity references, which fails horribly when you need like permssions, picture in picture etc.

@ursus yes, you're right

well, having a static layer just to perform rotations, idk how I feel about that

you can use headless fragment tho.

well, I do, but then if I need to do something in activity, i need to emit Command objects

i never had implements of view bind in Activity. Activity only for container for attaching fragment or view

Doesnt matter, pick anthing you need activity for

to be honest never use PIP mode. but, i already use Single Activity Architecture. only navigate to the screen, by using Navigator,goTo(screen)

well yes single activity saves you

just like you using RxBinding

well you cant since it will leak if you retain viewmodel

then disposed it

nah, the observable itself will have reference to view

are you sure if you pass Observable<String> login(): to retained view model, you are not creating a leak?

@ursus as long as you assign it to a subscriber and unsubscribe it on onClear, you can’t create a memory leak.and don’t get me wrong Im not arguing against coroutines, I am saying people are creating the wrong argument. Coroutines is all about concurrency, so you should compare it to other concurrency models,like Threads.. Like you wouldn’t compare Threads to RX java because that wouldn’t make sense lol….

I need to think about this harder but I dont think you are right. If you unsubscribe onClear, from a observable that comes from UI (not other way around), view.onDestory will come sooner than viewmodel.onClear (after rotation there is no onClear and is onDestroy)

If its coming from the UI. You use AndroidSchdulers.mainThread

you are talking about something else. I am talking about observable view -> viewmodel. NOT viewmodel -> view

Than you have AndroidSchdulers.

I dont know what you mean. There is no onPause in viewmodel? The leak is if you have a view reference (whitch has a activity reference) in a retained viewmodel after rotation, because its a hard reference in a viewmodel, so you keep it from GCing

Why would you have a view reference in the viewmodel?

What? I never said rx api causes leaks. Well you could argue rx view binding would be nice in viewmodel. But the main use case is somethimg that requires activity context, but is not a view.. like pip, permissions etc.

@ursus and what I am saying is that your wrong. For one , in the documentation it literally tells you not to directly reference views and context in your viewmodels because it causes memory leaks. Like that literally the disclaimer for using viewmodels. And if you do need context it tells you, to use AndroidViewModel which provides the application viewmodel... Like this is literally in the documentation... So creating this hypothetical about a memory leak, is not a limitation of Rx Java, it's literally just bad coding, and someone not reading the documentation...

Okay I give up. I am debating code design in general to improve how we do things on android, and you are saying I cant because google library docs say I cant, lol

From all perspectives you can’t. From a code design perspective, view related stuff don’t belong in the Viewmodel lol…

Okay clearly you dont get it, dont wanna waste your time anymore, thanks