how is that less boilerplate? a simple map is one line

@asyncsec @tschuchort @jw @thomasnield Also, without a

flatMap

all subsequent requests would be made on the same thread (they can't be parallelized), as this would break Observable contract.

Wouldn't both map and flatmap be executed on IO in this example?

I guess that if

source

is a Subject then it can be something other than

io

it will be the thread on which you call

subject.onNext

imo

Oh and if it were an Observable?

then if you are not doing anything weird like manually calling onNext on different thread then it should be

io

Cool

No

Also, thanks to @thomasnield : http://tomstechnicalblog.blogspot.com/2015/11/rxjava-achieving-parallelization.html

What I said above is correct but map and flatMap won’t execute in parallel.

They will be both executed on io thread one after another

so in this example

operation()

and

show()

would run on the same thread?

No,

operation()

will run on

io

thread and

show()

on

ui

thread.

then what's the problem with using

map

in the original question of Joseph?

in his example both map and flatMap are below

subscribeOn(IO)

and above

observeOn(MainThread)

but operation should still execute on io and show on ui, right?

yup

then what's the problem with using map here, which is much less boilerplate, instead of flatMaping a single value? the only reason I see to ever use flatMap in such a scenario is if you want another flatMap operation to start while the previous one hasn't finished yet

In this case if your request fails (throws an exception) then the whole stream will be terminated and you will have to subscribe again. You could use

flatMap

and return a new observable which can also do

onErrorResume..

. https://medium.com/@jagsaund/5-not-so-obvious-things-about-rxjava-c388bd19efbc look at point 4 in this post.

@tschuchort @mzgreen I encourage you to read Thomas's article. He explains everything in details.

@User uploaded a file: Untitled

@tulio No, this doesn't make sense to me 😕 You should never subscribe in the middle of chain. Instead, you should combine the streams, and subscribe only at the end of the chain.

Not sure what you're trying to achieve actually. Can you explain what's the plan?

If you want to make a remote call only if there's no data in cache, then here's the trick:

@User uploaded a file: Untitled

If you also wan't to save the fresh data into the cache, then something like this should work:

@User uploaded a file: Untitled

@gregd my plan for now is to return local data and always fetch remote data after that, saving it locally