Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Ignacio Baca Moreno-Torres
    @ibaca
    I’m not 100% sure, but we almost never need to debug the rx stack, and we have really few unexpected situation with rx, and I think this is bc we ALWAYS follow this 2 simple rules! this makes composition perfect (subscribe, next, complete, error and cancel signaling chained corretly in any situation) so the code much more predictable too; hehe not sure, but I’m starting to think that most of the people that complaing about rx problems and rx debugging, do not follow this rule, this breaks the chain and requires you to debug the code to find where the [error or cancelation] has gone
    David Karnok
    @akarnokd
    My experience is that pretty often, the code is full of very similar looking flows and the stacktrace listing the involved operators is not enough to locate the problematic flow. This is also apparent when map fails due to null returns and the stacktrace points to the RxJava operator, not the lambda of the developer that returned the null to the operator.
    Ignacio Baca Moreno-Torres
    @ibaca
    yep, this is true, but the solution is reasonable easely… use the “jump to type source” debug action
    image.png
    Dan O'Reilly
    @dano
    that doesn't help you when all you have is a stack trace in a log file :)
    Ignacio Baca Moreno-Torres
    @ibaca
    yep, true hehe I was thinking of that, it must be a reproducible error
    we use stop on exception alot :wink:
    but, all errors must be reproducible, if not, why you even care to fix it :stuck_out_tongue_winking_eye:
    Incubator
    @incube8r
    @ibaca thanks for the help
    k.watanabe
    @hackugyo
    Hi all
    How do you handle warnings of return values of subscirbe() with trello/RxLifecycle? subscirbe() has @CheckReturnValue annotation. Although I handle Disposable by compose(bindToLifecycle()) I must care about return values or suppress each warnings. How can I avoid this?
    Should I use uber/AutoDispose instead of RxLifecycle?
    Ignacio Baca Moreno-Torres
    @ibaca
    I don't use android, but in gwt I use this and I pass the whole Observable instead of subscribing it https://github.com/intendia-oss/rxgwt/blob/2.x/core/src/main/java/com/intendia/rxgwt2/user/RxWidget.java
    This also has the advantage of been able to decide whet it gets subscribes and to reconnect if something goes wrong
    This idea can be trivially applied over RxLifecycle, so the warning will disappear (and other advantages which are even more important), but note that if you do this, then you really should only add binding in your activity constructor to avoid to add duplicate bindings
    k.watanabe
    @hackugyo
    Thanks I will try! @ibaca
    Essentially, what suppress warnings in your suggestion is adding the disposable to class-scope (or, activity-scope) disposable list, I think. RxLifecylce will manage disposables, so perhaps what I need is just a trivial extension methods:
        @SuppressWarnings("CheckReturnValue")
        fun <T> Maybe<T>.subscribeSilently(onSuccess: (T) -> Unit): Disposable? {
            return subscribe(onSuccess)
        }
    Ignacio Baca Moreno-Torres
    @ibaca
    @hackugyo In our case, we add the Observable itself to de lifecycle manager, and it is the manager the responsible of subscribing it when the phase start, and unsubscribe it on finish, so for example if you add an observable to the method onResume(observable) (added one time, recommended to do it in the activty constructor), it will subscribe it in onResume phase, and unsbuscribe it on onPause, this will allow to add some retry to the observable and to caught and handle errors a bit more specific than with the global handler. But yep, to just avoid the warning your solution is easier :+1:
    Luca Looz
    @llooz
    what is the difference between .to and .compose?
    Dayan Ruben Gonzalez
    @dayanruben
    Xcg,
    i
    Vc. BB. BVB BV gy vc gosta m
    Obrigado jmm
    Não. obrigado ZX, não sei como. ,
    Ii,t
    Não
    BBVA ,,,, en o. ,, en. Nn
    Dayan Ruben Gonzalez
    @dayanruben
    K Inc BMW+76.vv mais
    ,V
    L
    Bom , não um mm
    Obrigado ZX kk
    , b
    .
    D
    yusufjk
    @yusufjk
    When is Rx going to add Flowable Interop features of creating an observable from optional or streams
    yusufjk
    @yusufjk
    Yes but this 3rd party. When is Rx going to integrate it?
    David Karnok
    @akarnokd
    If it ever goes Java 8 minimum, I haven't decided yet on RxJava 3. Consider Reactor Core 3+ till then.
    David Stocking
    @dmstocking
    @akarnokd I didn't know about Reactor Core until you mentioned it. But even after reading, I can't quite get what it is trying to do. Is it just trying to be really fast and lightweight? It looks pretty similar to RxJava2.
    David Karnok
    @akarnokd
    The deal is this, RxJava 2 couldn't go beyond Java 6 due to Android and Pivotal/Spring needed something leveraging Java 8. After some R&D and collaboration with the Pivotal guys on an experimental precursor to both, I did most RxJava 2 and contributed a lot of Reactor. They later moved on with additional features such as context.
    Yannick Lecaillez
    @ylecaillez
    Hello !
    While working on a piece of code i discovered that Flowable.concatMap() was invoking upstream.cancel() once inner subscriber is done. What's the reason for that ?
    Flowable.just(Boolean.TRUE)
                    .repeat()
                    .concatMap(token -> Flowable.just("blah").doOnCancel(() -> System.out.println("Cancelled")))
                    .subscribe();
    this seems to be an undesirable(?) side effect of SubscriptionArbiter in ConcatMapInner
    Note that Flowable.flatMap() does not have this issue(?).
    David Karnok
    @akarnokd
    There is no need for that in respect to concat/concatMap but last time I've tried to change that broke a couple of other operators. I have to investigate if we need two arbiter modes or the replace-cancel could be done outside of the arbiter entirely.
    Yannick Lecaillez
    @ylecaillez
    That's not an issue when using Flowable given that cancelling a completed Flowable should be sthg like a no-op.
    The behavior for Completable, Maybe and Single is less obvious to me.
    If i have a Single<Socket> connect(). And this one succeed. Is an invocation of dispose() should close the socket or not ?
    Yannick Lecaillez
    @ylecaillez
    Well ... i think it should not close the socket. Dispose is actually related to the Single, not to the resource forwarded by the Single, isn't it ?
    Yannick Lecaillez
    @ylecaillez
    The difficult part here is to handle race conditions... (i.e: what if the connection is successfully established and forwarded at the exact same time downstream invoked dispose(): the socket might be leaked)
    so this would favor a socket.close() into the dispose() impl ...But then you are subject to operators behaviors (like concatMap() which cancel()/dispose() upstream once completed)
    I would greatly appreciate ideas/opinions on that :)
    Yannick Lecaillez
    @ylecaillez
    (note that for now i've replaced concatMap(foo) by flatMap(foo, 1) but it's probably less efficient ...)
    Yannick Lecaillez
    @ylecaillez
    At the end, i think operators should never cancel() upstream unless they're propagating a downstream cancel() invocation OR if it's the expected behavior of the operator to limit the upstream (i.e: takeWhile()).
    As such, i think the current behavior of concatMap() exposed by my snippet should be considered as a bug.
    WDYT ?