you can use the commented code to control the buffering, if you have a single, that looks that it is actually a completable as you are ignoring its unique element, you can call .ignoreElement() and the again .toFlowable()

another, maybe more “natural” approach is to use a ConnectableFlowable and connect it manually, so it start buffering at that moment… but then you need to control the disconnect of this ConnectableFlowable, the example is longer so I use this weird previous example bc atleast the subscriptions are handled automatically

James Fleming

@Flemingjp

I'm trying to implement an OrderBook system where there is a snapshot (the Single) and updates to the snapshot (which is a Flowable) Im wanting to make it as self managed as possible

Hi everyone, I have a question:ServiceReturnObservable1.getData() .flatMap(r -> serviceReturnObservable2.getSomeData(r.getValue())) .flatMap( here I want to work with ServiceReturnObservable1.getData() and serviceReturnObservable2.getSomeData(r.getValue()))

Pulkit Kumar

@pulkitkumar

@neeeserviceReturnObservable2.getSomeData(r.getValue()) should emit an object which has everything you need to chain it further. Since it is already accepting value emitted by ServiceReturnObservable1, you should be able to add those values to the object emitted by ServiceReturnObservable2 .

Dan O'Reilly

@dano

@neee i usually .map to a tuple type inside of the first flatMap call, or nest the second flatMap call inside the first

i have a bunch of helpers for automatically "chaining" the second emitted value into a tuple with the previous emitted value, and then unpacking the tuple in the next call

Or I have to change the Single<Boolean> to something else that will be able to get the FileObject and pass it one.onSuccess?

Ignacio Baca Moreno-Torres

@ibaca

Something eles? Hehe just use Single<FileObject>

_

Incubator

@incube8r

I also need to get the boolean status

so I have to create a POJO to have both Boolean and FileObject at the same time?

Ignacio Baca Moreno-Torres

@ibaca

Boolean status? It is always true, this is not a status

Incubator

@incube8r

the method entity.setBlobProperty emits isSuccess which is the status either true or false

Ignacio Baca Moreno-Torres

@ibaca

You are also adding a listener and never removing it, use the rxgwt utilities for observing event which handle that correctly

Oh I see, and this is an Observable? Remember, never ever subscribe inside another subscription, use flap Map instead

RxJava is like callback on steroids, so whenever you see a callback you can trivially wrap it as a RxJava type, readasdataurl has a callback, so wrap it as a rxtype and flatMap too (when I say flatMap, you can use the one you need, flatMap, concatMap, switchMap...)

Incubator

@incube8r

problem here is that Event.setEventListener blocking that chain

I mean I can't do return Observable... inside that anonymous class

I could flatMap outside but the typed return would change

Ignacio Baca Moreno-Torres

@ibaca

use RxGWT, then flapMap the event with the ReadAsDatUrl Observable wrapper

Incubator

@incube8r

can you show me how to do this the right way using the RxGWT utilities?

@incube8r so the important conclusion is this 2 points! apply in order, bc the scond condition should be applied after the first point has been resolved

always use rx types, if you add a callback, promise, completablefuture or any alternative async structure, wrap it with a rx type, rx compose only with other rx types, and you use rx bc it can be composed (I like to think that rxjava is like a callback unifier), this will assert that rxjava chain errors and cancelation correctly too, wich is the the mayor difference with raw callback and other alternatives

never subscribe into a subscription, always compose the rx types, there are really a lot of operator, but atleast use on of flatMap, concatMap or switchMap. this is critical to allow rx to chain errors and cancelation correctly, if you subscribe into a subscription, then you are just callback-programming, and IMO if you mix rx and callback-programing is going to be an absolute hell, with just the disvantages of both sides

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

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 allHow 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?