https://kotlinlang.org logo
Join Slack
Powered by
What’s the point of the ‘observation’ here
# rx
a
What’s the point of the ‘observation’ here
z
what type of data are you trying to fetch with yourobservable?
or from your API, rather?
a
It’s not about the data he wants to fetch
He wants his retrofit adapter to observe the locally saved credentials and every time they change the adapter shall ‘save them internally’ as well to use them for the next calls
z
lol I guess he doesn't want to come here
r
sorry
z
nice
lol
r
I wasn't aware of this new thread feature 🙂
z
yeah it's poorly implemented
the point of Rx is to represent values over time
r
aren't credentials a value over time? First, it doesn't exist, then the user enters some and maybe they change them later?
z
correct
I only use okhttp interceptors to modify things that are always present
a
Still, having your network adapter observe the credentials to use them sounds just wrong to me.
r
So you don't do calls without credentials, huh? Well, I thought about it this way: Say you have a call that gives you a list of stuff that you show in your activity but because you don't have credentials there is nothing in your list. You then enter your credentials and when you save them, the data propagates through all these observables and you see your list of stuff without hitting refresh.
Wait, that doesn't work because I don't know which calls I need to trigger when I get new credentials...
z
your use case could technically still work, you just wouldn't be observing the value from that 
UserDb
. you would want a synchronous 
Single
with a 
blockingValue()
r
Could I postpone calls until I have credentials?
z
yes
r
So the GUI wants to display a list of foo, that call blocks, then I enter the credentials, the credentials flow into the blocked call, it executes and the foo list appears in the GUI?
z
userDb.logginInUser().filter{user -> user == User.Authenticated}
just filter the stream as you see fit
the above stream I just posted would only return authenticated users now^^
r
That's amazing.
z
it's a hard way of thinking because we are taught the "do this then that" mentality, instead of "react to this by doing that"
the latter is infinitely more flexible
but I find that by representing my UI as a single state, I can do so much more with it. just apply mutations to that state over time and your application can react beautifully
r
It's really neat. I have the infinite list of the most recent and all future valid credentials, I flatMap that with a call and then I have a sort of blocking call observable that will update the GUI only after the first valid credentials were entered.
z
you probably want to switchmap more than flatmap, btw
that was a big gotcha for me
r
Never heard of that, what is it?
z
switchmap unsubscribes from the previous source, replacing it with a new one
if you flatMap you may be observing two sources
which get "flattened" into a single stream"
it's non-blocking though, that's the cool part 😛
r
yeah, I didn't mean literally blocking the main thread, I just meant that it doesn't actually make a call until the credentials appear.
z
yup, it's sweet
r
Ah, my guests arrived! Thank you all for your help, it clarified a lot 🙂
z
awesome, feel free to ask anytime!
r
...though I feel like Rx is much bigger than I thought. Guess I'll be back soon.
Have a good day, bye!
4 Views
Open in Slack
PreviousNext
Powered by