https://kotlinlang.org logo
Join Slack
Powered by
can someone help me refactoring this to `using`? `...
# rx
u
can someone help me refactoring this to 
using
?
Copy code
contentObservable(resolver, uri, handler)
                .flatMapSingle {
                    Single.fromCallable { resolver.query(uri, projection, selection, selectionArgs, sortOrder) }
                }
                .map<Optional<Contact>> { optionalOf(mapContact(it)) }
where that fromCallable returns Single<Cursor>, so obviously it will not close the cursor if stream gets unsubscribed after that and before mapContact where I actually close the cursor (now), therefore leaking the cursor right?
a
Easiest way to do that would be to avoid 
Cursor
being emitted
Copy code
contentObservable(resolver, uri, handler)
  .flatMapSingle {
    resolver
      .query(uri, projection, selection, selectionArgs, sortOrder)
      .use { 
          it.let { mapContact(it) }
       }
}
However, realistically, chances of situation when Cursor is emitted but stream disposed before Cursor was consumed is small and 
AbstractCursor
(which most Cursors extend) closes itself in its 
finalize
method, so while not perfect, it won’t leak
u
I see, I tried to refactor it to 
using
, however its the same problem, first lambda takes should create the Cursor, then its all okay, but obviously if Cursor is coming from upstream, i.e. already was created
so yea thanks ill do it synchronously, its just that query was supposed to be a general method, and mapping to a certain pojo is specific to a given method call, but ill add a lambda mapper to query as a parameter, should be okay, thanks!
a
np! I still think the problem is unlikely to happen and if it happens AbstractCursor saves the day 🙂 (talking from experience of developing and supporting users of StorIO which also exposes Cursors as rx streams)
u
right, but finalizer has its problems, but better than nothing
a
It'll only kick in in that rare case when you emit Cursor and stream is disposed before cursor is consumed
u
yea yea, btw have you solved your RxUi issue with even new android mainthread scheduler being async?
ive talked to Jake and he said its unsolvable, i.e. viewmodel should have the observerOn before relaying to relay you are actually exposing as observable to the ui, therefore upon rotation its synchronous (behavior relay)
a
Um, that's totally different issue :) Also, yes, I think I solved it in Domic https://github.com/lyft/domic/issues/14
u
okay I dont totally remember it, but rxui proposed basically observeOn in View, right?
a
RxUi yes
u
how is it different issue then 😄
a
Domic is a bit different but still achieves same goal of making main thread an implementation detail while propagating cancelation properly
Domic is different, that's how :) it has custom rendering and doesn't use observeOn(mainThread)
u
right, also workaround would be publish { first just, others observeOn }
a
Sure, there are workarounds to observeOn
u
btw that are those virtual doms about? will I be able to MVI all the things and it will do diffing for me?
a
By different issue I meant that you switched from discussing Cursor to main thread lol
u
yea, im a rebel 😄
a
Yep, pretty much
u
hooraay, btw in current project im simply creating a cache of previous and current emits, and do diffing manually
a
You can read readme of Domic or watch talk about it where it is explained what problem does it solve and what's the point of its existence

https://youtu.be/Ce6phlHfKR8▾

u
if(prevState.foo != newState.foo) redraw(foo)
a
Yeah it's not that simple lol, in the talk I explain rendering and diffing in very great detail, you may find it interesting
u
yes its from where I know about it, but then in the same conference Jesse said something about emitting views
something along those lines, had me confused
a
yea that’s the eventual design goal, on each processing cycle (Redux, MVI, etc) emit single object that represents view hierarchy and data in it so that something like Domic could process and render it efficiently
similarly to how React works on web
u
what about transient stuff like dialogs, snackbars, toasts? should everything be in hierarchy?
those always mess MVI up
a
dialogs are ~fine, toasts and similar dissapearing stuff is more complicated yea
different Redux-ish libraries handle it differently, they often allow side-effects like this that are not stored as part of new state
I personally think that they should be part of state, but that’s just me
from the virtual dom perspective, toast won’t be part of it at least right now, dialog can be tackled as its own layout so that’s ok
u
im kind of split on it, i think its kind of a same thing as animation is in mvi
i.e. you diff, and if it changed cancel it, else just let it run out
okay now I see thats not the point lol sry
its more of a behavior subject vs publish subject, right
a
yeah, because old state participates in calulation of new one and for things like rotation or state restore some people like to avoid temporary things like toasts being displayed again, I personally as a user would actually like that because it makes it clear in which state app is in
u
well depends how far in past the event happened, but yea, its arguable
thats why I sometimes emit Started, Success, Error states and sometimes end with Idle as well to "flush"
a
fair enough yea, I tend to decouple Virtual DOM from libs/frameworks just for that reason to allow flexibility in decisions like this
2 Views
Open in Slack
PreviousNext
Powered by