Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    dwursteisen
    @dwursteisen
    Anyone played with the RxJavaSchedulersHook plugin. With a Executor Service as a scheduler, the "onSchedule" method hook is not called. I don't know if it's expected...
    (my goal is to progragate some MDC key thought my Observable) => http://blog.mabn.pl/2014/11/rxjava-logback-and-mdc-threadlocal.html
    Josh Durbin
    @joshdurbin
    Hey Everyone — I have a very, very specific question.
    I’m using an implementation of a library, david moten’s tree - https://github.com/davidmoten/rtree - in which the tree itself is immutable, thus operations to mutate the tree result in a “view” of that object with the supplied operation result
    I’ve got a basic API that allows insertion and query of the rtree, which supports rx query operations OOTB
    I’ve wrapped the insert commands in a write lock, but i’m at a loss, if you will, how that impacts the read operations (as you’d typically also wrap your ‘read’ logic in read locks)
    Mainly the insertPlace and getPlaces methods.
    Dorus
    @Dorus

    @joshdurbin
    I didn't look at any of that, but i can give you the theory :)

    If the tree is immutable, you do not need locks. Instead, any insert will traverse the tree, and create a new tree. Usually kept efficient by reusing unmodified parts of the old tree. That way, when you modify the tree, you receive a new tree that you then need to communicate to any reader that's consuming the tree. Only once you've communicated the new tree root, they will be able to read your modifications.

    Boy Wang
    @boyw165
    For a most basic observable, there's only one subscriber can subscribe to it at the same time, right?
    Dorus
    @Dorus
    no
    Boy Wang
    @boyw165
    Except PublishSubject, still no?
    Dorus
    @Dorus
    Observables are like function calls, you can call them multiple times but different calls wont affect each other.
    At least for Cold observables
    Hot observables do affect eachother, they share side effects.
    PublishSubject is used to convert a cold observable into a hot one.
    Boy Wang
    @boyw165
    Oh I got it. So how do I build a pub-sub pattern by using observable? I want the observable can do some heavy image process when demand, and emit the result to all subscribers when done.
    Dorus
    @Dorus
    It pretty much already is.
    Mostly you need to make your source hot.
    Boy Wang
    @boyw165
    Cool, HOT is the key. :D
    Dorus
    @Dorus
    Depending on the source, some sources are hot by default (fromEventPattern), others can be made hot with Publish.
    In your case i assume you have something that makes requests to start the image processing, that's your source. And then you have a number of subscribers that want to receive updates.
    Sounds like your source is already hot.
    If your image processing happens inside the observable stream, you need to publish it also.
    Boy Wang
    @boyw165
    I see. So I have to figure out HOT observables.
    Dorus
    @Dorus
    if you push processed images directly into the stream, you don't need that.
    Boy Wang
    @boyw165
    Thanks. I checked out the session of "HOT" and "COLD" observables lately and was confused. Now I know which cases are they for from your kindly answer. :D
    Dorus
    @Dorus
    Oh btw, the easiest way to publish your source would be refCount/share.
    Boy Wang
    @boyw165
    Checking this out. :+1:
    Boy Wang
    @boyw165

    In the jakewharton/rxbinding/view/ViewClickOnSubscribe::call, these codes seems like to unset the OnClickListener when unsubscribe.

        subscriber.add(new MainThreadSubscription() {
          @Override protected void onUnsubscribe() {
            view.setOnClickListener(null);
          }
        });

    I know subscription is the cancelling token returned when an observer subscribe to an observable. And what does it mean by adding a subscription to an observer?

    Artem Zinnatullin :slowpoke:
    @artem-zinnatullin
    @boyw165 added Subscription will be unsubscribed with parent one, add is really bad name, yeah… but it's public api, so we can't change it so easily
    Boy Wang
    @boyw165
    @artem-zinnatullin so the whole traversal of processing observers is actually done in the tree of subscription?
    Artem Zinnatullin :slowpoke:
    @artem-zinnatullin
    @boyw165 depends on what do you mean by traversal of processing observers, basically add(subscription) used only for releasing resources
    Derek Perez
    @perezd
    Newb here, I have a merged collection of observables that are all doing async work and ultimately emit objects that have a consistent tag (like: thingA, thingB) but have unique values associated with those tags. Ultimately, I'd like to have a Map that has thingA->[data,data], thingB->[data,data]
    I should also mention I am using buffers
    so I have mergedIo.buffer(100).somethingThatMovesThroughBufferThatIsMapFriendly()
    need help with that last part :)
    buffer is semi-reducing here.
    which I don't really want.
    window might be better, but I can't really tell.
    Any thoughts?
    I basically want buffers of maps
    that I subscribe to
    maps will have n keys that point to m values per buffer from the thing I'm subscribed to.
    the root issue is, the buffer is ambiguous, it contains objects with thingA and thingB and I want to split them out into their respective map keys
    Dorus
    @Dorus
    Perhaps you can split thingA and thingB before you call buffer? GroupBy might help.
    Then buffer the grouped observables, apply the reduce function to the result and merge it back together.
    Derek Perez
    @perezd
    so I can buffer a GroupBy? I am having a hard time understanding what GroupBy does in practice...it feels right but this GroupedObservable thing is messing meup
    so, if I buffer after a groupBy does it make a buffer per group?