Multicasting
Multicasting is sending the same emissions to multiple observers. This done through the use of hot observables, such as the ConnectableObservable returned from the publish method. When using hot observables, there is a key point that needs to be understood, and that is that a hot observable does not stay hot with subsequent calls in the chain. This means that if the publish method is called in the middle of a call chain, then the emissions up to the point where the publish call was made will be shared between all observers, but any further changes or transformations to the emissions past the publish point will redone for each observer, even if they're sharing the same code.Generally speaking, it is best to keep Observables cold, unless you have a reason to make them hot. Reasons to do this include "to increase performance, reducing memory and CPU usage, or simply because your business logic requires pushing the same emissions to all Observers."
A ConnectableObservable won't start sending emissions until the connect call is made, And you'll typically want to make sure that all Observers are subscribed before calling connect so that the Observers don't miss any emissions. There are a number of convenience methods to make connecting more straightforward under the right circumstances.
autoConnect()
The autoConnect method will automatically connect after the specified number of Observers have subscribed. It defaults to one if no number is given. You can also specify zero if you want it to connect immediately without waiting for subscribers. Also note that autoConnect will persist it's connection, even when there are no subscribers, and it will not resubscribe to the Observable if it is disposed.refCount() and share()
refCount() is similar to autoConnect(1), but with the difference that when there are no more Observers, it will dispose of itself, and resubscribe if future Observers subscribe, essentially starting over for the new subscriber. The share() method is essentially a shortcut to writing publish().refCount().replay() and cache()
The replay operator allows you to store emissions within certain parameters so that they can be replayed for future Observers. replay() with no parameters specified will store all emissions, and for future Observers it will immediately replay all emissions until it is caught up, and then start sending it emissions as they come. This has the potential to be very memory intensive.If you only care about the last handful of emissions, you can specify a buffer size or a time window or both.
the cache() operator is essentially just a shortcut for replay().autoConnect(). It is meant for storing all emissions indefinitely.
Subjects
Subjects are an advanced tool that really shouldn't be used unless you've ruled out other possibilities first. They are a mix between an Observer and an Observable, and are frequently used for bridging the gap between reactive and imperitive programming. Another use case is to "use Subjects to eagerly subscribe to an unknown number of multiple source Observables and consolidate their emissions as a single Observable." There are also some possible use cases in decoupling.A subject can be subscribed to by Observers, and it can subscribe to other Observables, and you can manually call onNext(), onError(), and onComplete() on them. Note that the first Observable to call onComplete on the Subject will cease further emissions from other Observables, as well. It is also important to note that the onSubscribe(), onNext, onError() and onComplete() methods on a Subject are not threadsafe. If you're not careful, you could easily "break the Observable contract, which demands that emissions happen sequentially."
