RxJava Ninja: Observable Factories Part 1

Photo by SpaceX on Unsplash

This article is a part of the RxJava Ninja series. The complete list of the articles for this series can be found at the end of this article (and will be updated as more articles become available).

Today, we will learn about the different observable factories in RxJava2 at our disposal (finally). We already discussed Observable.create in one of the previous articles and frankly speaking, that is the most complicated one so if you think you had no problem following that, the rest should be pretty easy for you as well. Let’s start by revisiting our old friend, just.

Note: The factory methods are also treated as operators since it transforms an input to an Observable. This means they can be represented with marble diagrams.

Observable.just

Observable.just is a pretty straightforward operator. It wraps you input as an observable and returns them as items. Below is the marble diagram.

Image from rx docs

The just operator can accept a minimum of 1 and a maximum of 10 inputs. Note that the type of inputs should be the same. Let’s see an example.

Note: In other platforms, Observable.just is equivalent to Observable.Return. However in Java, methods are camel-case and return is a keyword so it was changed to just.

The output of this one would be

Person1
Person2
Person3

One important thing that you should be aware of is that the input can contain expressions like Observable.just(10 + 1). If for some reason, an exception happened in the input expression, it will not be propagated through the onError channel because it is evaluated first before invoking just. This means you can encounter runtime exception when using just.

Observable.fromIterable

The Observable.fromIterable belongs to the family of from operators. The from marble diagram is shown below.

Image from rx docs

As the name suggests, it accepts an iterable sequence input an emits the items in the sequence individually.

The code above will output

Mazda
BMW
Toyota

This operator is useful in cases wherein your input is a collection and you need to operate on each of the items individually without spreading the list explicitly.

Observable.fromArray

Observable.fromArray is similar to fromIterable but it accepts a variable number of arguments instead. This is what is used by just when used with more than 1 parameter.

This will have the same output as fromIterable example.

Observable.fromCallable

Observable.fromCallable is a very powerful operator. It accepts an instance of Callable<V> as input. This callable will not be invoked until subscription and is therefore lazy. Also, since the call method of the Callable<V> is invoked during subscription, any exception encountered will be propagated through the onError channel. Let’s demonstrate both cases.

The code above prints the current time before and after subscribe. The output of this is

15:27:05.182651
15:27:10.275867

If this is not lazy, the time should have been resolved at the declaration of the observable and should be pretty close to each other. But since it is lazy, it was actually resolved at subscription hence the 5 seconds gap. Now let’s look at the error propagation.

This will output

onError: Forced error

which is expected since all exceptions will propagate in the onError channel.

This operator is also a part of the Start family. The start family emits the return value of a function as an item. The marble diagram of the start family is as follows.

Image from rx docs

Observable.fromFuture

Unfortunately, this observable did not travel through time to get included in RxJava’s list of operators. This is a converter for Future types.

This will output the message below (which is confusing because we already established that it is not from the future).

I am from the future

Observable.fromPublisher

This operator serves the same purpose as Observable.create but is readily compatible with Reactive-Streams’ Publisher type. It is generally used for potentially unbounded sequences.

This will output an infinite sequence of I am infinite strings.

That concludes the family of from operators. Let us now discuss a very “limited” family of operators. They do not offer much aside from testing or combination with other observables. We will not demonstrate their behavior anymore. I leave it up to you to check them for yourselves.

Observable.Empty

This operator does not emit anything and will go straight to sending the complete notification.

Image from rx docs

Observable.Never

This operator never emits anything, not even the complete notification.

Image from rx docs

Observable.error

This operator does not emit anything and sends an error notification.

Image from rx docs

Observable.Range

This operator emits a sequence of integers starting from start and until count is reached. If integer is not enough, there is a variant that emits long named rangeLong.

Image from rx docs

The above code will output

0
1
2
3
4

Be careful not to interpret the second parameter as the final item value. This operator is useful for indexing or as an alternative and reactive approach to for loops. There is another variant of range that is time based and we will discuss that in the next part since it has some interesting properties.

This should be enough for the Part 1. On the next article, we will discuss more operators that creates observables.

Check out the other articles in this series.

1. Introduction to Reactive Programming
2. Building your first Observables and Observers
3. In Depth Observables and Observers
4. Marble Diagrams and Operators
5. Observable Factories Part 1
6. Observable Factories Part 2
7. Single, Maybe and Completable
8. Hot and Cold Observables
9. Filtering Operators Part 1
10. Filtering Operators Part 2