* Translating iterables to observables, just for the sake of working on the through an Rx library.

Rx is based around two fundamental types, and several others that expand the functionality around them. Those two types are the `Observable` and the `Observer`. we will introduce those, as well as `Subject`s, which ease the learning curve.

Rx builds upon the [Observer](http://en.wikipedia.org/wiki/Observer_pattern) pattern. It is not unique in doing so. Event handling already exists in Java (e.g. JavaFX's EventHandler). These simpler approaches suffer in comparison to Rx:

[Observable](http://reactivex.io/RxJava/javadoc/rx/Observable) is the first core element that we will see. Since Java does not support extension methods, this class contains a lot of the implementation in Rx. We will be examining it step by step throughout this book. For now, we must understand the `Subscribe` method. Here is one key overload of the method:

This is the method that you use to receive the values emitted by the observable. As the values come to be pushed (through policies that we will discuss throughout this book), they are pushed to the subscriber, which is then responsible for the behaviour based on this example. The `Subscriber` here is an implementation of the `Observer`.

We already saw one abstract implementation of the [Observer](http://reactivex.io/RxJava/javadoc/rx/Observer.html), `Subscriber`. `Subscriber` implements some extra functionality and we will see why it is needer later. For now, we should understand the simpler interface.

Those three methods are the behaviour that is executed every time the observable pushes a value. The observer's will have its `onNext` called zero or more times, optionally followed by an `onCompleted` or an `onError`. No calls happen after a call to `onError` or `onCompleted`.

You'll see a lot of the `Observable`, but not so much of the `Observer`. While it is important to understand the `Observer`, you'll be using a lot of method overloads that hide it.

You could manually implement `Observer` or extend `Observable`. In reality that may be unnecessary, since Rx provides all the building blocks you need. It is also dangerous, as interaction between parts of Rx includes conventions and internal plumming that are not obvious. It is both simpler and safer to use the many tools that Rx gives you for generating the functionality that you need.

To subscribe to an observable, it is not necessary to provide instances of Observer at all. There are overloads to `subscribe` that take the functions to be executed for `onNext`, `onError` and `onSubscribe`, hiding the creation of instances. It is not even necessary to provide each of those functions. You can even provide a subset of them, i.e. for `onNext` or for `onNext` and `onError`.

The introduction of lambda functions in Java 1.8 makes these overload very convenient for our examples.

Subjects are an extension of the `Observable` that also implements the `Observer` interface. The idea may sound odd at first, but they make things a lot simpler in some cases. They can have events pushed to them, which they then push further to their own subscribers. This makes them ideal entry points into Rx code: when you have values coming in from outside of Rx, you can push them into a `Subject`, turning them into an observable. You can think of them as entry points to Rx code.

`Subject` has two parameter types: the input type and the output type. This is not because `Subject` is the right place transform your values. There are transformation operators to do that, which we will see later.

`ReplaySubject` has the special feature of caching all the values pushed to it. When a new subscription is made, the event sequence is replayed from the start for the new subscriber.

ReplaySubject<Integer> s = ReplaySubject.create();

s.subscribe(v -> System.out.println("Early:" + v));

s.onNext(0);

s.onNext(1);

s.subscribe(v -> System.out.println("Late: " + v));

s.onNext(2);

Our late subscriber now missed the first value, which fell off our buffer of size 2.

ReplaySubject<Integer> s = ReplaySubject.createWithTime(150, TimeUnit.MILLISECONDS, Schedulers.immediate());

`BehaviorSubject` only remembers the last value. It is similar to a `ReplaySubject` with a buffer of size 1. An initial value can be provided on creation, therefore guaranteeing that a value will be available immediately on subscription.

An initial value is available if anyone subscribes before the first value is pushed

`AsyncSubject` also caches the single last value. The difference now is that it doesn't emit anything until the sequence completes. Its use is to emit a single value and immediately complete.

As we already mentioned, there are contracts in Rx that are not obvious in the code. An important one is that no events are emitted after a termination event (`onError` or `onCompleted`). The implemented subjects respect that:

`subscribe()` consumes events but performs no actions. The overloads that take an `Action1` construct a `Subscriber` with the functions that you provide, or doing nothing where the action is missing.

If we do not provide a function for error handling, an `OnErrorNotImplementedException` will be *thrown* at the point where `s.onError` is called. It happens here that the producer and the consumer are side-by-side, so you could do a try-catch. However, on a compartmentalised system you won't receive the exception unless you provide a handler to `subscribe`.

boolean isUnsubscribed()

void unsubscribe()

Unsubscribing one observer does not interfere with other observers

`onError` and `onCompleted` mean the termination of a sequence. An observable that complies with the standard will not emit anything after either of those events. This is something to note both when consuming in Rx and when implementing your own observable.

A `Subscription` can be tied to the resources it uses. For that reason, you should remember to dispose of subscriptions. You can create that binding a `Subscription` with the necessary using the [Subscriptions](http://reactivex.io/RxJava/javadoc/rx/subscriptions/Subscriptions.html) factory.

The `Subscriptions` factory has more methods, which allow you to compose the use of resources into a single `Subscription`. `Subscription` itself has several implementations.

We will see some more later on.