https://kotlinlang.org logo
Join Slack
Powered by
lmao that comment about rx, whats next, dont write...
# android
u
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
l
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.
u
sure..rxjava predates cooroutines, and is superset of cooroutines, so, same thing different api
r
It depends how deep you know RxJava is.
u
sure, im. not arguing against cooroutines
r
@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…
RX Java and Coroutines are not the same The only similarity they have is that you can specify the thread operations run on … Coroutines is dealing purely with concurrency.. RX java is dealing with event driven observable sequencing. You can argue that you can achieve some of the same sequencing with kotlin functions. But to say they are the same API or one could replace would be incorrect, would be incorrect. Its like me trying to say, RX Java could replace threads lol
u
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
what I meant is that rx made handlign difficult scenarios easy, so ..they get handled, same as when you have faster computer, you do more computing
but if it is complicated for noobs, cooroutines will do as well, better than yoloing raceconditions etc.
l
@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).
r
@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...
Rxjava, is the best for what It does. Why do you think its recognized by so many dev's.
u
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
r
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.
r
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
👌 1
🙂 1
r
Correct
u
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
cant someone just tell me how to restore observable chains supscriptions etc so I dont need to retain viewmodel / presenter? 😄
r
Use connectable observable @ursus
I believe you know about replay(), autoConnect(), publish(), refCount(), share(), and how to use cross those factories.
Even you no need view model to retain. Under the hood view model is just a fragment with retainInstance = true, and additional sugar. Old Android API which is Loaders also will survive when device orientation changed.
@ursus I am also avid rx users, btw. But, I do keep learning something new and trying to compare with existing stack. If new stack is make sense to replace existing, I will use that. If no, absolutely will not replace.
l
@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 😉
r
awesome. @louiscad
u
@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.
r
@ursus yes, you're right
u
well, having a static layer just to perform rotations, idk how I feel about that
r
you can use headless fragment tho.
u
well, I do, but then if I need to do something in activity, i need to emit Command objects
like Command.GoToFooActivity
bit if you need something like activity.enterPipMode which returns boolean, you are screwed
r
i never had implements of view bind in Activity. Activity only for container for attaching fragment or view
u
Doesnt matter, pick anthing you need activity for
or a view, like webview..
r
to be honest never use PIP mode. but, i already use Single Activity Architecture. only navigate to the screen, by using Navigator,goTo(screen)
u
well yes single activity saves you
what about views, id like to pass textViewObservsblr as to viewmodel ctor
or something async like textureView where you need to listen to onAvailable callback
r
just like you using RxBinding
u
well you cant since it will leak if you retain viewmodel
you need to do a silly dance if relays
or do it in view
r
then disposed it
in appropriate callback
u
nah, the observable itself will have reference to view
if you pass to val of viewmodel
r
Copy code
interface SignInView {
  // Produces.
  Observable<String> login();
  Observable<String> password();
  Observable<Object> signInClicks();
  
  // Consumes.
  Function<Observable<Boolean>,      Disposable> signInEnable();
  Function<Observable<SignInResult>, Disposable> signInResult();
}
i used to did like this
u
are you sure if you pass Observable<String> login(): to retained view model, you are not creating a leak?
r
@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….
u
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)
hence you creating a leak
youd need to attach to VM in on View.onCreate(or vm ctor whatever) and detach it from VM in View.onDestroy, only this I THINK wont create a leak
r
If its coming from the UI. You use AndroidSchdulers.mainThread
but if your using Lifecycle component , you can handle all of in the viewmodel
You just need to unsubscribe at the right place… If you don’t assign the observable to a subscriber, you will get a leaked subscriptions warning
if RX is use properly there won’t be memory leaks. Its not like the API has a memory leak feature lol
u
you are talking about something else. I am talking about observable view -> viewmodel. NOT viewmodel -> view
r
Than you have AndroidSchdulers.
I don’t see the problem.
or just unsubscribe in onPause and onStop
Theoretically speaking, your view shouldn’t be inside your ViewModel. So if your using RXandroid you just need to set it to a subscription and unsubscribe when needed
u
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
r
Why would you have a view reference in the viewmodel?
a view belongs in the View of MVVM, not in the VM
Thats not a issue with RX , thats a issue with the architecture lol…
The main idea ,is that RXJava doesn’t cause memory leaks. There is no underling issue with the API. Bad Code causes memory leaks '
Like I can sit here and think of a thousand and one ways to create a memory leak with Coroutines. It doesn’t mean Coroutines causes memory leaks, it just mean my code did
u
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.
which you cannot have the reference to in a retained viewmodel so please dont repeat that onPause disposal thing
r
@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...
And what I'm saying about onPause is that, if you use RxAndroid in your *activity *(not viewmodel) that you should assign it to a subscriber and unsubscribe when needed. Like during onPause... which is correct. Like if you don't do that you literally get a Leaked Subscriptions warning lol. I don't know why we are even debating about this
u
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
r
From all perspectives you can’t. From a code design perspective, view related stuff don’t belong in the Viewmodel lol…
Android Jetpack is the improvement on how we do things. But ya still got to follow the rules 😂
u
Okay clearly you dont get it, dont wanna waste your time anymore, thanks
Open in Slack
PreviousNext
Powered by