3.6 Reworked chapter

Author: Froussios

Part 3 - Taming the sequence/6. Hot and Cold observables.md

@@ -1,10 +1,10 @@
 # Hot and Cold observables
 
-Observable sequences come in two flavours that have important differences. They are called "hot" and "cold". In this chapter, we will explain what each type is and what that means for you as an Rx developer.
+Observable sequences come in two flavours, called "hot" and "cold", that have important differences. In this chapter, we will explain what each type is and what that means for you as an Rx developer.
 
 ## Cold observables
 
-Cold observables are observables that run their sequence when and if they are subscribed to. They present the sequence from its start to each subscriber. An example of a cold observable would be `Observable.interval`. Regardless of when it is created and when it is subscribed to, it will generate the same sequence for every subscriber.
+Cold observables are observables that run their sequence when and if they are subscribed to. They present the sequence from the start to each subscriber. An example of a cold observable would be `Observable.interval`. Regardless of when it is created and when it is subscribed to, it will generate the same sequence for every subscriber.
 
 ```java
 Observable<Long> cold = Observable.interval(200, TimeUnit.MILLISECONDS);
@@ -28,17 +28,17 @@ Second: 2
 
 The two subscribers don't receive the same value at the same time, even though they are both subscribed to the same observable. They do see the same sequence, except that each of them sees it as having begun when they subscribed. 
 
-The code samples that we've seen in this guide so far have been cold observables, because cold obserables are easier to reason about. Every observable that is created with the `Observable.create` is a cold observable. That includes all the shorthands that we've seen, such as `just`, `range`, `timer` and `from`. 
+The code samples that we've seen in this guide so far have been cold observables, because cold observables are easier to reason about. Every observable that is created with the `Observable.create` is a cold observable. That includes all the shorthands that we've seen, such as `just`, `range`, `timer` and `from`. 
 
 Cold observables don't necessarily present the same sequence to each subscriber. If, for example, an observable connects to a database and emits the results of a query, the actual value will depend on the state of the database at the time of subscription. It is the fact that a subscriber will receive the whole query from the start that makes this observable cold.
 
 ## Hot observables
 
-Hot observables emit values regardless of subscriptions. They have their own timeline and items are emitted whether someone is listening or not. An example of this is mouse events. A mouse is generating event regardless of whether there is a subscription listening for them. When a subscription is made, the observer receives current events as they happen. You don't receive and you don't want to receive a recap of everything that your mouse has done since you booted your system. When you unsubscribe, it doesn't stop your mouse from generating events either. You're just not receiving them. If you resubscribe, you will again see current events with no recap of what you've missed.
+Hot observables emit values independent of individual subscriptions. They have their own timeline and events occur whether someone is listening or not. An example of this is mouse events. A mouse is generating events regardless of whether there is a subscription listening for them. When a subscription is made, the observer receives current events as they happen. You don't receive and you don't want to receive a recap of everything that the mouse has done since booting the system. When you unsubscribe, it doesn't stop your mouse from generating events either. You're just not receiving them. If you resubscribe, you will again see current events with no recap of what you've missed.
 
 ## Publish
 
-There are ways to transform one into the other. You can transform a cold observable into a hot observable by using `publish()`. 
+There are ways to transform cold observables into hot and vice versa. Cold observables become hot with the `publish()` operator. 
 
 ```java
 public final ConnectableObservable<T> publish()
@@ -88,7 +88,7 @@ Second: 5
 
 ### Disconnecting
 
-As we saw in `connect`'s signature, this method returns a `Subscription`, just like `Observable.subscribe` does. You can use that reference to terminate the `ConnectableObservable`'s subscription. That will stop events from being pushed to observers if `ConnectableObservable` but it will not unsubscribe them. If you call `connect` again, the `ConnectableObservable` will start a new subscription and the old observers will begin receiving values again.
+As we saw in `connect`'s signature, this method returns a `Subscription`, just like `Observable.subscribe` does. You can use that reference to terminate the `ConnectableObservable`'s subscription. That will stop events from being propagated to observers but it will not unsubscribe them from the `ConnectableObservable`. If you call `connect` again, the `ConnectableObservable` will start a new subscription and the old observers will begin receiving values again.
 
 ```java
 ConnectableObservable<Long> connectable = Observable.interval(200, TimeUnit.MILLISECONDS).publish();
@@ -119,7 +119,7 @@ Reconnecting
 ...
 ```
 
-When you restart by calling `connect` again, a new subscription will be created. If the source observable is cold, that means that the whole sequence is restarted, even though the resulting observable is hot.
+When you restart by calling `connect` again, a new subscription will be created. If the source observable is cold, that means that the whole sequence is restarted.
 
 If instead of terminating the connection, you want to unsubscribe from the hot observable, you can use the `Subscription` returned by the `subscribe` method.
 
@@ -129,7 +129,7 @@ Subscription s = connectable.connect();
 
 Subscription s1 = connectable.subscribe(i -> System.out.println("First: " + i));
 Thread.sleep(500);
-Subscription s2 = connectable.subscribe(i -> System.out.println("Seconds: " + i));
+Subscription s2 = connectable.subscribe(i -> System.out.println("Second: " + i));
 
 Thread.sleep(500);
 System.out.println("Unsubscribing second");
@@ -140,11 +140,11 @@ Output
 First: 0
 First: 1
 First: 2
-Seconds: 2
+Second: 2
 First: 3
-Seconds: 3
+Second: 3
 First: 4
-Seconds: 4
+Second: 4
 Unsubscribing second
 First: 5
 First: 6
@@ -245,7 +245,7 @@ ConnectableObservable<T> replay(long time, java.util.concurrent.TimeUnit unit)
 
 They are different ways of providing one or more of 3 parameters: `bufferSize`, `selector` and `time` (plus `unit` for time).
 * `bufferSize` determines the maximum amount of items to be stored and replayed. Upon subscription, the observable will replay the last `bufferSize` number of items. Older items are forgotten. This is useful for conserving memory.
-* `time`, `unit` determines how old an element can be before being forgotten. Uopn subscription, the observable will replay items that are newer than `time`.
+* `time`, `unit` determines how old an element can be before being forgotten. Upon subscription, the observable will replay items that are newer than `time`.
 * `selector` will transform the replayed observable, in the same way that `publish(selector)` works.
 
 Here's an example with `bufferSize`
@@ -288,7 +288,7 @@ Output
 
 ## cache
 
-The `cache` operator has the same purpose as `replay`, but hides away the `ConnectableObservable` and removes the managing its subscriptions. The internal `ConnectableObservable` is subscribed to when the first observer arrives. Subsequent subscribers have the previous values replayed to them from the cache and don't result in a new subscription tp the source observable. 
+The `cache` operator has a similar function to `replay`, but hides away the `ConnectableObservable` and removes the managing of subscriptions. The internal `ConnectableObservable` is subscribed to when the first observer arrives. Subsequent subscribers have the previous values replayed to them from the cache and don't result in a new subscription to the source observable. 
 
 ```java
 public final Observable<T> cache()
@@ -320,7 +320,7 @@ First: 4
 Second: 4
 ```
 
-In this example, we see that the sequence begins not when the observable was created, but when the first subscriber arrived 500ms after. The second subscribers caught up with earlier values upon subscription and received future values normally.
+In this example, we see that the sequence begins not when the observable was created, but when the first subscriber arrived 500ms later. The second subscribers caught up with earlier values upon subscription and received future values normally.
 
 An important thing to note is that the internal `ConnectableObservable` doesn't unsubscribe if all the subscribers go away, like `refCount` would. Once the first subscriber arrives, the source observable will be observed and cached once and for all. This matters because we can't walk away from an infinite observable anymore. Values will continue to cached until the source terminates or we run out of memory. The overload that specifies capacity isn't a solution either, as the capacity is received as a hint for optimisation and won't actually restrict the size of our cache.
 
@@ -347,14 +347,14 @@ Unsubscribed
 4
 ```
 
-In this example, `doOnNext` prints the values as they are produced and cached from the source observable, while `doOnSubscribe` and `doOnUnsubscribe` show the subscribers after the caching. We see that the emission of values begins with the first subscription but disregards the fact that we unsubscribed.
+In this example, `doOnNext` prints the values as they are produced and cached from the source observable, while `doOnSubscribe` and `doOnUnsubscribe` show the subscribers after the caching. We see that the emission of values begins with the first subscription but ignores the fact that we unsubscribed.
 
 
 
 
 ## Multicast
 
-The `share` method is an alias for `Observable.publish().refCount()`. It allows your subscribers to share a subscription. The subscription is kept for as long as there are subscribers.
+The `share` method is an alias for `Observable.publish().refCount()`. It allows your subscribers to share a subscription, which is kept for as long as there are subscribers.
 
 ![](https://raw.github.com/wiki/ReactiveX/RxJava/images/rx-operators/publishRefCount.png)