https://kotlinlang.org logo
Join Slack
Powered by
Question for those who use *RxBindings* - I notice...
# android-architecture
a
Question for those who use RxBindings - I noticed the following warning while moving to add the library to a new app I'm working on:
Warning: The created observable keeps a strong reference to 
view
. Unsubscribe
* to free this reference. Since we're not supposed to hold hard references to an activity or fragment or view in a 
ViewModel
from the architecture components, should we avoid passing an observable produced via RxBindings into a 
ViewModel
?
👌 1
☝🏻 1
c
I’m probably doing it wrong, but I pass RxBindings into the ViewModel. If that’s not how we should do it then definitely want to follow this thread
I haven’t noticed any issues so far though if that helps at all.
a
I'm going to do a test today and see if the activity is leaked on rotation when using rxbindings
I'll keep you posted!
c
🙏🏻
d
Any strong references to anything attached to the view in a ViewModel is a bad idea.
c
Recommendations for letting the ViewModel observe on user events?
@alexsullivan114 - once you finish up with your testing would you be able to respond to this question as well? https://github.com/JakeWharton/RxBinding/issues/503 I figure that way it gives a more definitive answer outside of the Slack channel as well
d
There is a couple of ways to do it. You can inject an a CommandBus into the 
ViewModel
. Another way to do it is by having a method on the 
ViewModel
you call. Use an intermediate object that subscribes to the bindings and calls the method on the 
ViewModel
A presenter on your view can grab the Rx stream from the view and communicate them to the 
ViewModel
Personally I prefer the CommandBus option.
c
You use the CommandBus along with RxBindings in production?
d
No I don't lol I don't us Rx at all.
I use coroutines.
But you can make a CommandBus with Rx
c
Gotcha
d
In principal you need an intermediary object that facilitates communication.
How ever you go about it you need to prevent hard references to anything in the view inside of your 
ViewModel
The docs say that too.
MVI using RxJava has good examples of the kind of behavior you need.
c
There are tons of MVI references out there so if you’d like to share the ones you’ve looked at that’d be 👌🏻
d
Java or Kotlin?
c
Either
d
Ok, one sec
🙏🏻 2
a
If I'm being honest, using an intermediary object is extremely disappointing. That adds a lot of boilerplate to what was approaching a concise flow
☝🏻 1
d

https://youtu.be/PXBXcHQeDLE?t=1339▾

This is beter then a blog post

https://youtu.be/8JewfcZl5TQ▾

This is very good too.
Concise is nice but sometimes inflexible.
I am not gospel though.
This is a ll just my opinion.
I like to write code so I don't mind writing a tool to do the job I need.
c
Yeah it is rather disappointing, especially given this talk which has RxBinding mapping into a network call with a promise that it could be retained between states 🤷🏻‍♂️

https://www.youtube.com/watch?v=0IKHxjkgop4▾

a
That video also comes years before 
ViewModel
was a thing so
c
When that video came out people referenced Relays which I think end up being a similar concept to ViewModels or at least the concerns would be the same
d
Honsetly I think some sort of event handling system would be nice for Androids next Architecture component.
We have cross component communication issues.
Another solution would be the ability to replay events to synthesize the current state when needed.
But now we are getting into Event sourcing and CQRS inside Android lol.
I have written an app that does that before though and I liked it a lot.

https://youtu.be/8JewfcZl5TQ?t=929▾

.takeUntil(Observable)
seems to be a nice solution.
Take until you get the view stopping or destroying event then you can dispose of your connection to the views event stream.
IDK maybe you would use a 
CompositeDisposable
for this kinda usecse.
Also you need to ensure your team knows how to uses these contructs incase someone other then youself is going to build out a new view.
I like Command/Event/Query busses for this because they are simple to understand.
Plus you can build them once and then inject them.
a
I mean we've moved very far out of the initial scope of questioning.
☝🏻 1
d
Yep
It's called a rabbit hole lol
I will shutup now.
Have a good day.
a
You too, thanks for the input!
u
@dewildte and if you want to get a return value when using a commands observable, you are screwed
d
You could embed a callback into the command
I don't know why you would ever need that though.
u
activity.enterPictureInPictureMode()) : Boolean for example
d
Nice code, care to add some context?
u
piece of code where you need a return value of "view" function, in which command pattern is impotent since its a two way comunication not just firing events
a
Update on this: I've come to realize that passing observables creates via rxbindings into your view model is just a bad move altogether. First of all it leaks, second of all when the user rotates the phone a new view is created and thus the old observable you're holding onto won't fire anymore. Unless you expose setters for those observables than you'll be SOL.
c
Yeeeeeah it seems like in general you’d want a light framework for consistent communication between View/ViewModel with RxBindings which is very disappointing
s
@alexsullivan114 I ran into something similar esp dealing with an EditText and its debounce. I just have the UI (activity/fragment) subscribe to it and relay it to ViewModel with a regular function which in turn feeds it a PublishSubject which is chained to backend (network and database)
a
@Sam That's exactly what I'm doing now. It's an unfortunate bit of boilerplate but it works for now. I wonder if there's a small library that could be used that alleviates some of this noise. You'd have to expose something that your view sort of "rebinds" to whenever the view is created that could then feed through to the view model. Anyways, thanks for the input!
s
There are some implementations of Uni Directional Flow that makes it a bit easier.
c
So one of my co-workers may have found an elegant solution for this using class delegation. We’re going to run through some tests internally but if that works I’m going to get them to write about on Medium
👍 1
a
oh dope!
3 Views
Open in Slack
PreviousNext
Powered by