ConnectableObservable [http://reactivex.io/RxJava/javadoc/io/reactivex/observables/ConnectableObservable.html] does not care when you subscribe to it; instead, it only begins its work when connect() is called. With that in mind, what is the output of the following? val connectableObservable = Observable.just("Hello!").publish() connectableObservable .subscribeOn(

Hello. This is Dan Lew. You may or may not know me as the author of RxLifecycle [https://github.com/trello/RxLifecycle/tree/2.x]. Here’s why I’ve started pulling back from using my creation. Origins When Trello first started using RxJava [https://github.com/ReactiveX/RxJava], we

Multicasting is a key method for reducing duplicated work in RxJava. When you multicast an event, you send the same event to all downstream operators/subscribers. This is useful when you're doing an expensive operation like a network request. You don't want to repeatedly execute identical

repeatWhen [http://reactivex.io/RxJava/javadoc/rx/Observable.html#repeatWhen(rx.functions.Func1)] and retryWhen [http://reactivex.io/RxJava/javadoc/rx/Observable.html#retryWhen(rx.functions.Func1)] are fairly baffling at first glance. For starters, they are serious contenders for "most confusing marble diagrams": They're useful

RxJava makes error handling a snap. Just use onError, right? That's fine and dandy if you're the subscriber, but what about exceptions that occur inside your operators? How do you ensure that an Exception in, say, flatMap() gets passed along to onError? And what if you

I've grown fond of RxJava's defer() [http://reactivex.io/documentation/operators/defer.html] as a tool for ensuring Observable code runs when subscribed (rather than when created). I've written about defer() before [http://blog.danlew.net/2014/10/08/grokking-rxjava-part-4/#oldslowcode] but I'

Suppose I have some Data that I query from the network. I could simply hit the network each time I need the data, but caching the data on disk and in memory would be much more efficient. More specifically, I want a setup that: 1. Occasionally performs queries from the

In part 1 [https://blog.danlew.net/2014/09/15/grokking-rxjava-part-1/], I went over the basic structure of RxJava. In part 2 [https://blog.danlew.net/2014/09/22/grokking-rxjava-part-2/], I showed you how powerful operators could be. But maybe you're still not sold; there isn't

In part 1 [https://blog.danlew.net/2014/09/15/grokking-rxjava-part-1/] I went over the basic structure of RxJava, as well as introducing you to the map() operator. However, I can understand if you're still not compelled to use RxJava - you don't have much to

RxJava [https://github.com/ReactiveX/RxJava] is the new hotness amongst Android developers these days. The only problem is that it can be difficult to approach initially. Functional Reactive Programming is hard when you come from an imperative world, but once you understand it, it's so awesome! I&