RxJava bindings for JavaFX

Last update: Dec 27, 2022

Related tags

Overview

RxJavaFX: JavaFX bindings for RxJava

Read the free eBook Learning RxJava with JavaFX to get started.

RxJavaFX is a lightweight library to convert JavaFX events into RxJava Observables/Flowables and vice versa. It also has a Scheduler to safely move emissions to the JavaFX Event Dispatch Thread.

NOTE: To use with Kotlin, check out RxKotlinFX to leverage this library with extension functions and additional operators.

Master Build Status

Documentation

Learning RxJava with JavaFX - Free eBook that covers RxJava from a JavaFX perspective.

Learning RxJava - Packt book covering RxJava 2.0 in depth, with a few RxJavaFX examples.

1.x Binaries

Binaries and dependency information for Maven, Ivy, Gradle and others can be found at http://search.maven.org.

Example for Maven:

<dependency>
    <groupId>io.reactivex</groupId>
    <artifactId>rxjavafx</artifactId>
    <version>1.x.y</version>
</dependency>

Gradle:

dependencies {
	compile 'io.reactivex:rxjavafx:1.x.y'
}

2.x Binaries

RxJavaFX 2.x versions uses a different group ID io.reactivex.rxjava2 to prevent clashing with 1.x dependencies. Binaries and dependency information for Maven, Ivy, Gradle and others can be found at http://search.maven.org.

Example for Maven:

<dependency>
    <groupId>io.reactivex.rxjava2</groupId>
    <artifactId>rxjavafx</artifactId>
    <version>2.x.y</version>
</dependency>

Gradle:

dependencies {
	compile 'io.reactivex.rxjava2:rxjavafx:2.x.y'
}

Features

RxJavaFX has a comprehensive set of features to interop RxJava with JavaFX:

Factories to turn Node, ObservableValue, ObservableList, and other component events into an RxJava Observable
Factories to turn an RxJava Observable or Flowable into a JavaFX Binding.
A scheduler for the JavaFX dispatch thread

Node Events

You can get event emissions by calling JavaFxObservable.eventsOf() and pass the JavaFX Node and the EventType you are interested in. This will return an RxJava Observable.

Button incrementBttn = new Button("Increment");

Observable<ActionEvent> bttnEvents =
        JavaFxObservable.eventsOf(incrementBttn, ActionEvent.ACTION);

Action Events

Action events are common and do not only apply to Node types. They also emit from MenuItem and ContextMenu instances, as well as a few other types.

Therefore, a few overloaded factories are provided to emit ActionEvent items from these controls

Button ActionEvents

Button incrementBttn = new Button("Increment");

Observable<ActionEvent> bttnEvents =
        JavaFxObservable.actionEventsOf(incrementBttn);

MenuItem ActionEvents

MenuItem menuItem = new MenuItem("Select me");

Observable<ActionEvent> menuItemEvents = 
        JavaFxObservable.actionEventsOf(menuItem);

Other Event Factories

There are also factories provided to convert events from a Dialog, Window or Scene into an Observable. If you would like to see factories for other components and event types, please let us know or put in a PR.

Dialogs and Alerts

Alert alert = new Alert(AlertType.CONFIRMATION);
alert.setTitle("Confirmation");
alert.setHeaderText("Please confirm your action");
alert.setContentText("Are you ok with this?");

JavaFxObservable.fromDialog(alert)
    .filter(response -> response.equals(ButtonType.OK))
    .subscribe(System.out::println,Throwable::printStackTrace);

Emitting Scene Events

Observable<MouseEvent> sceneMouseMovements =
     JavaFxObservable.eventsOf(scene, MouseEvent.MOUSE_MOVED);

sceneMouseMovements.subscribe(v -> System.out.println(v.getSceneX() + "," + v.getSceneY()));

Emitting Window Hiding Events

 Observable<WindowEvent> windowHidingEvents =
    JavaFxObservable.eventsOf(primaryStage,WindowEvent.WINDOW_HIDING);

windowHidingEvents.subscribe(v -> System.out.println("Hiding!"));

ObservableValue

Not to be confused with the RxJava Observable, the JavaFX ObservableValue can be converted into an RxJava Observable that emits the initial value and all value changes.

TextField textInput = new TextField();

Observable<String> textInputs =
        JavaFxObservable.valuesOf(textInput.textProperty());

Note that many Nodes in JavaFX will have an initial value, which sometimes can be null, and you might consider using RxJava's skip() operator to ignore this initial value.

ObservableValue Changes

For every change to an ObservableValue, you can emit the old value and new value as a pair. The two values will be wrapped up in a Change class and you can access them via getOldVal() and getNewVal(). Just call the JavaFxObservable.changesOf() factory.

SpinnerValueFactory<Integer> svf = new SpinnerValueFactory.IntegerSpinnerValueFactory(0, 100);
Spinner spinner = new Spinner<>();
spinner.setValueFactory(svf);
spinner.setEditable(true);

Label spinnerChangesLabel = new Label();
Subscription subscription = JavaFxObservable.changesOf(spinner.valueProperty())
        .map(change -> "OLD: " + change.getOldVal() + " NEW: " + change.getNewVal())
        .subscribe(spinnerChangesLabel::setText);

ObservableList, ObservableMap, and ObservableSet

There are several factories to emit many useful ObservableList, ObservableMap, and ObservableSet events as Observables. These all can be found as static factory methods in the JavaFxObservable static class.

Factory Method	Parameter Type	Return Type	Description
emitOnChanged()	ObservableList<T>	Observable<ObservableList<T>>	Emits the entire `ObservableList` every time it changes
additionsOf()	ObservableList<T>	Observable<T>	Emits additions to an `ObservableList`
removalsOf()	ObservableList<T>	Observable<T>	Emits removals from an `ObservableList`
updatesOf()	ObservableList<T>	Observable<ListChange<T>>	Emits every item that was the result of a change to an `ObservableList`, with an `ADDED`, `REMOVED`, or `UPDATED` flag
distinctChangesOf()	ObservableList<T>	Observable<ListChange<R>>	Emits only distinct addtions and removals to an `ObservableList`
distinctMappingsOf()	ObservableList<T>, Func1<T,R>	Observable<ListChange<R>>	Emits only distinct additions and removals to an `ObservableList` and emits the mapping
distinctChangesOf()	ObservableList<T>, Func1<T,R>	Observable<ListChange<R>>	Emits only distinct additions and removals to an `ObservableList` based on a mapping
emitOnChanged()	ObservableMap<K,T>	Observable<ObservableMap<K,T>>	Emits the entire `ObservableMap` every time it changes
additionsOf()	ObservableMap<K,T>	Observable<Map.Entry<K,T>>	Emits every `Map.Entry<K,T>` added to an `ObservableMap`
removalsOf()	ObservableMap<K,T>	Observable<Map.Entry<K,T>>	Emits every `Map.Entry<K,T>` removed from an `ObservableMap`
changesOf()	ObservableMap<K,T>	Observable<MapChange<K,T>>	Emits every key/value pair with an `ADDED` or `REMOVED` flag.
emitOnChanged()	ObservableSet<T>	Observable<ObservableSet<T>>	Emits the entire `ObservableSet` every time it changes
additionsOf()	ObservableSet<T>	Observable<T>	Emits every addition to an `ObservableSet`
removalsOf()	ObservableSet<T>	Observable<T>	Emits every removal to an `ObservableSet`
changesOf()	ObservableSet<T>	Observable<SetChange<T>	Emits every item `ADDED` or `REMOVED` item from an `ObservableSet` with the corresponding flag

Binding

You can convert an RxJava Observable into a JavaFX Binding by calling the JavaFxObserver.toBinding() factory. Calling the dispose() method on the Binding will handle the unsubscription from the Observable. You can then take this Binding to bind other control properties to it.

Button incrementBttn = new Button("Increment");
Label incrementLabel =  new Label("");

Observable<ActionEvent> bttnEvents =
        JavaFxObservable.eventsOf(incrementBttn, ActionEvent.ACTION);
        
Observable<String> accumulations = bttnEvents.map(e -> 1)
        .scan(0,(x, y) -> x + y)
        .map(Object::toString);
        
Binding<String> binding = JavaFxObserver.toBinding(accumulations);

incrementLabel.textProperty().bind(binding);

//do stuff, then dispose Binding
binding.dispose();

It is usually good practice to specify an onError to the Binding, just like a normal Observer so you can handle any errors that are communicated up the chain.

incrementLabel.textProperty().bind(binding, e -> e.printStackTrace());

Lazy Binding

The toBinding() factory above will eagerly subscribe the Observable to the Binding implementation. But if you want to delay the subscription to the Observable until the Binding is actually used (specifically when its getValue() is called), use toLazyBinding() instead.

Binding<String> lazyBinding = JavaFxObserver.toLazyBinding(myObservable);

This can be handy for data controls like TableView, which will only request values for records that are visible. Using the toLazyBinding() to feed column values will cause subscriptions to only happen with visible records.

CompositeBinding

You also have the option to use a CompositeBinding to group multiple Bindings together, and dispose() them all at once. It is the JavaFX equivalent to CompositeSubscription.

Binding<Long> binding1 = ...
bindings.add(binding1);

Binding<Long> binding2 = ... 
bindings.add(binding2);

//do stuff on UI, and dispose() both bindings
bindings.dispose();

JavaFX Scheduler

When you update any JavaFX control, it must be done on the JavaFX Event Dispatch Thread. Fortunately, the JavaFxScheduler makes it trivial to take work off the JavaFX thread and put it back when the results are ready. Below we can use the observeOn() to pass text value emissions to a computation thread where the text will be flipped. Then we can pass JavaFxScheduler.platform() to another observeOn() afterwards to put it back on the JavaFX thread. From there it will update the flippedTextLabel.

TextField textInput = new TextField();
Label fippedTextLabel = new Label();

Observable<String> textInputs =
        JavaFxObservable.valuesOf(textInput.textProperty());

sub2 = textInputs.observeOn(Schedulers.computation())
        .map(s -> new StringBuilder(s).reverse().toString())
        .observeOn(JavaFxScheduler.platform())
        .subscribe(fippedTextLabel::setText);

JavaFX Interval

There is a JavaFX equivalent to Observable.interval() that will emit on the JavaFX thread instead. Calling JavaFxObservable.interval() will push consecutive Long values at the specified Duration.

Observable<Long> everySecond = JavaFxObservable.interval(Duration.millis(1000));

Differences from ReactFX

ReactFX is a popular API to implement reactive patterns with JavaFX using the EventStream. However, RxJava uses an Observable and the two are not (directly) compatible with each other.

Although ReactFX has some asynchronous operators like threadBridge, ReactFX emphasizes synchronous behavior. This means it encourages keeping events on the JavaFX thread. RxJavaFX, which fully embraces RxJava and asynchronous design, can switch between threads and schedulers with ease. As long as subscriptions affecting the UI are observed on the JavaFX thread, you can leverage the powerful operators and libraries of RxJava safely.

If you are heavily dependent on RxJava, asynchronous processing, or do not want your entire reactive codebase to be UI-focused, you will probably want to use RxJavaFX.

Notes for Kotlin

If you are building your JavaFX application with Kotlin, check out RxKotlinFX to leverage this library through Kotlin extension functions.

Bugs and Feedback

For bugs, questions and discussions please use the Github Issues.

LICENSE

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Comments

Build Failing

This is not yet building ... someone who works with JavaFX needs to figure this out.

I can make it build with Java 8, but there must be a way to get the correct JavaFX dependencies or build config for Java 7?

Also, when building with Java 8 some unit tests fail.

opened by benjchristensen 27
Lazy BindingSubscriber

There should be an option to make the RxJavaFX Binding implementation lazy. That way it delays subscribing to the Observable until the Binding is first called for the value.

Maybe there needs to be two implementations: EagerBindingSubscriber and LazyBindingSubscriber. The first one is what exists currently as BindingSubscriber.

opened by thomasnield 15
CompositeBinding Implementation

I'm thinking of creating a CompositeBinding in the same spirit as CompositeSubscription. This way multiple bindings created off Observable items can quickly be disposed as a group.

opened by thomasnield 15

emitOnChanged() emits values on JavaFx thread

When using JavaFxObservable.emitOnChanged outside of the running application (specifically - to unit-test my view models with JUnit) I've experienced the unexpected "Toolkit not initilized exception" on the first emission. The following sample code throws the exception:

    private ListProperty<String> listProperty = new SimpleListProperty<>(FXCollections.observableArrayList());

    @Test
    public void test() {
        JavaFxObservable.emitOnChanged(listProperty)
                //.subscribeOn(Schedulers.io())
                .subscribe(list -> {
                    Observable.fromIterable(list).subscribe(s -> System.out.println(s));
                });


        listProperty.add("list");
    }

The walkaround for the issue is to subscribe on a specific non-JavaFx scheduler (see the commented line).

opened by morincer 13

JavaFxScheduler broken on (at least) 8u112
Currently the JavaFxScheduler depends on the keyframe finish callback of JavaFX animations. But animations with a duration of zero will never start, thus the callback (of the keyframe) will not be called. See javafx.animation.Animation.java (JDK 8u112):

boolean impl_startable(boolean forceSync) { return (fromDuration(getCycleDuration()) > 0L) || (!forceSync && clipEnvelope.wasSynched()); }

One possible solution is to use the finish callback of the timeline instead: timer.setOnFinished(executeOnce);
opened by protogenes 12
Planning for RxJava 2.0

I read the documentation on the release candidate of RxJava 2.0, and it is pretty clear disruptive (but good) changes are on the horizon that directly affect RxJavaFX.

https://github.com/ReactiveX/RxJava/wiki/What's-different-in-2.0

I haven't dived deep into this yet or even messed with the released candidate, but it does seem a major refactoring is necessary since RxJava was basically rewritten from scratch with the coming 2.0 release.

I'll investigate this further, but it seems RxJavaFX would want to use the Flowable rather than the Observable. I am not a backpressure expert, but my understanding is backpressure cannot be helped with UI events since a person cannot be directed to slow down emissions. Therefore, a Flowable makes sense, and I can't think of any factories in RxJavaFX that shouldn't use it.

I think the best approach is to release RxJavaFX 1.0 and 2.0 as separate maintained versions, aligned with the respective RxJava counterparts. The same will likely happen with RxKotlinFX.

Again, I didn't dig deep in RxJava 2.0 but I think I have a high level of understanding. If anybody has any concerns, ideas, feedback, or just anything they would want to see in RxJavaFX 1.0 and 2.0, please let us know here on this issue.

opened by thomasnield 12
1.x JavaFxScheduler rewrite, fix for #48

This rewrite of the JavaFxScheduler is based on queued execution of very action. With a shortpath for the original Timeline issue in schedule(Runnable, long, TimeUnit). It reliable solves the problems in #27 and #48, as it ensures schedule calls from within the FX thread as well as its recursive actions will be processed before returning control to the caller. The pull request is for the fully queued version, which does not prefer recursive actions over pending or asynchronously scheduled actions. This implementation is easier and the behaviour matches that of a traditional Executor. I also did a minimalistic benchmark and the timings for one million tasks are 800ms for the new version vs. 51800ms for the old version.

opened by protogenes 11

CompositeObservable to merge Observable Events

I am encountering a need heavily where I want to merge() multiple Observable event sources, but I don't have the sources available upon initialization. I need to add them later at separate places in the application.

With David Karnok's help, I came up with a utility. Here is the Kotlin implementation.

class ObservableBus<T>(cacheCount: Int = 0) {

    private val subject: SerializedSubject<Observable<T>, Observable<T>> = PublishSubject<Observable<T>>().toSerialized()
    private val live: MutableSet<Observable<T>> = ConcurrentHashMap.newKeySet<Observable<T>>()

    private val observable = subject.flatMap { obs: Observable<T> -> obs.takeWhile { live.contains(obs) } }
            .observeOnFx().let { if (cacheCount > 0) it.cacheWithInitialCapacity(cacheCount) else it }

    fun toObservable(): Observable<T> = observable

    operator fun plusAssign(observable: Observable<T>) = add(observable)
    operator fun minusAssign(observable: Observable<T>) = remove(observable)

    fun add(observable: Observable<T>) {
        live.add(observable)
        subject.onNext(observable)
    }
    fun remove(observable: Observable<T>) {
        live.remove(observable)
    }
}

This is also helpful for creating event-driven models. So if you have a MenuItem, Button, and key combo that all trigger a refresh request, you can merge all three Observables later.

object MyEventModel { 
    val refreshRequests = ObservableBus<ActionEvent>
}

val button = Button("Refresh")
MyEventModel.refresh += button.actionEvents()

//later
val menuItem = MenuItem("Refresh")
MyEventModel.refresh += button.actionEvents()

//and later again
val ctrlRPress = someNode.events(KeyEvent.KEY_PRESSED,)
     .filter { it.isControlDown && it.keyCode = KeyCode.R }
     .map { ActionEvent() }

MyEventModel.refresh += ctrlRPress

Subscription

MyEventModel.refresh.subscribe { performRefresh }

Of course, you can push anything and not just ActionEvent items. Does anybody else see value in this? I'll write this in Java if there is interest.

opened by thomasnield 11

add nullable Bindings

add overloads to JavaFxObserver and JavaFxSubscriber which allow to unmask null values in an Optional or guarded by a sentinel as counterpart to JavaFxObservable.nullableValuesOf

opened by protogenes 9
Deprecating CompositeObservable in favor of Subjects

The CompositeObservable was somewhat of a moving target after I first had the idea. It was a tool to safely decouple RxJava streams in a JavaFX application without exposing a Subject, which can encourage antipatterns especially with Rx newbies.

Although I haven't changed my sentiments on Subjects, I may have softened my stance a little when it comes to decoupling. The CompositeObservable ultimately came to resemble a Subject without exposing the Observer methods. Not to mention, it is somewhat inconvenient having to call its toObservable() method to get the Observable.

Therefore, I am considering deprecating the CompositeObservable and telling people to use PublishSubject, ReplaySubject, etc instead. If anybody has thoughts on this topic, please feel free to share.

opened by thomasnield 9
JavaFxScheduler.getInstance() naming

Hello,

RxJava gave functional names to Schedulers accessor : Schedulers.io(), Schedulers.computation(), Schedulers.newThread(), ...

RxJavaFX has a technical name for the JavaFX Scheduler accessor : JavaFxScheduler.getInstance(). Even if you can understand it at the first sight, it can be more revelant to use a fonctional name instead, like : JavaFxScheduler.ui()

RxAndroid use the same logic, and hidding the singleton instance though RxAndroid.mainThread() : https://github.com/ReactiveX/RxAndroid/blob/1.x/rxandroid/src/main/java/rx/android/schedulers/AndroidSchedulers.java#L56

TLDR : Is renaming JavaFxScheduler.getInstance() to JavaFxScheduler.ui() can be an option ?

Regards.

opened by dwursteisen 9
Setting up a new build chain for stable/nightly releases.

This is an open discussion about what the best of way of setting up a build chain should be, for automatic publishing to Maven Central, and so on. My experience in this field is limited, so I'd welcome input on how to best accomplish this goal in a streamlined fashion.
help wanted

opened by Speljohan 0
update gradle to enable building with openjdk 14

Hello, I'm new to RxJavaFX and was trying to test it with a maven based project that depends on rxjava3. These are the changes I needed to successfully run ./gradlew publishToMavenLocal using openjdk 14. I also happen to be new to gradle but it looks like the more recent versions have helped simplify things a bit for handling java modules and scoping of dependencies. Hope this helps in the upcoming release with rxjava3 support!

opened by geodab 0
It looks like passing all the tests with openjfx 13.0.1

Hi,

I tried to change openjfx version from 11 to 13.0.1 and it looks like compiled correctly, which means, as long as I understand, the library is not using any deprecated API.

Is there any reason not to update it to 2.13.0?

I'm just wondering since my projects are using openjfx 13.0.1.

Thanks for the fantastic library :)

opened by geniejhang 2
Add index field to list updates

This is a feature that I have been wanting for a while from RxJavaFX and also has been requested in issue #72.

Edit: Not sure why the CI failed...It seems to be something wrong with the configuration or something.

opened by JonathanVusich 1
A typo on Gitbook guide
this one should be

.scan(String::length) .reduce(0)...

not

.map(String::length) .reduce(0)

here is url: https://thomasnield.gitbooks.io/rxjavafx-guide/content/2.%20RxJava%20Fundamentals.html#scan

and here is a screenshot
opened by riemannulus 0

Releases(2.11.0-RC36)

2.11.0-RC36(May 26, 2020)

Special thanks to @pvnhome, @JonathanVusich, and @Speljohan for spurring this on.
Source code(tar.gz)
Source code(zip)
2.11.0-RC35(May 25, 2020)

Special thanks to @pvnhome, @JonathanVusich, and @Speljohan for spurring this on.
Source code(tar.gz)
Source code(zip)
2.11.0-RC33(Dec 27, 2018)

This is a release candidate for RxJavaFX 2.11.0, which supports JavaFX 11.

Please try out this release and let me know if there are any issue
Source code(tar.gz)
Source code(zip)
2.11.0-RC32(Nov 24, 2018)

This is a release candidate for RxJavaFX 2.11.0, which supports JavaFX 11.

Please try out this release and let me know if there are any issue
Source code(tar.gz)
Source code(zip)
2.11-RC2(Nov 2, 2018)

This is a release candidate for RxJavaFX 2.11.0, which supports JavaFX 11.

Please try out this release and let me know if there are any issues.
Source code(tar.gz)
Source code(zip)
2.11.0-RC1(Nov 1, 2018)

This is a release candidate for RxJavaFX 2.11.0, which supports JavaFX 11.

Please try out this release and let me know if there are any issues.
Source code(tar.gz)
Source code(zip)
2.2.2(Nov 27, 2017)
This release contains bug fixes for the doOnNextCount(), doOnErrorCount(), and doOnCompleteCount() transformers as well as their FX counterparts doOnNextCountFx(), doOnErrorCountFx(), and doOnCompleteCountFx().

Unit tests have been added for these operators as well.

List<Integer> onNextCounts = new ArrayList<>(); Observable.just("Alpha", "Beta", "Gamma") .compose(FxObservableTransformers.doOnNextCount(onNextCounts::add)) .subscribe(); Assert.assertTrue(onNextCounts.containsAll(Arrays.asList(1, 2, 3)));
Source code(tar.gz)
Source code(zip)
2.2.1(Nov 24, 2017)
A series of nullable Binding factories has been built by @protogenes. These help workaround RxJava not allowing null emissions, which are often necessary for null states in JavaFX ObservableValues.

JavaFxObservable.toNullBinding() JavaFxObservable.toNullableBinding() JavaFxObservable.toLazyNullBinding() JavaFxObservable.toLazyNullableBinding() JavaFxSubscriber.toNullBinding() JavaFxSubscriber.toNullableBinding() JavaFxSubscriber.toLazyNullBinding() JavaFxSubscriber.toLazyNullableBinding()

The toNullBinding() factories use a null sentinel value to represent null emissions, while toNullableBinding() factories leverage Optional<T> emissions and unwraps them in the Binding.

Thanks for your help @protogenes! An https://github.com/thomasnield/RxKotlinFX release will follow shortly.
Source code(tar.gz)
Source code(zip)
2.2.0(Sep 9, 2017)
This is the first breaking change in awhile, although it only affects the Dialog factory. JavaFxObservable.fromDialog() will return a Maybe<T> rather than an Observable<T> now. This makes sense since a Dialog may only have one response from the user, if there is any provided value at all.

Dialog<String> dlg = ...; Maybe<String> response = JavaFxObservable.fromDialog(dlg);
Source code(tar.gz)
Source code(zip)
2.1.1(Jun 28, 2017)
Small addition to this release: a null-sentinal overload is now available for JavaFxObservable.valuesOf().

ObservableValue<String> myProperty = ... Observable<String> values = JavaFxObservable.valuesOf(myProperty, "N/A")

Thank you @protogenes for contributing this.
Source code(tar.gz)
Source code(zip)
2.1.0(May 28, 2017)
Deprecated CompositeObservable, use a Subject instead to decouple Observables and Observers #54

Group ID has been changed to io.reactivex.rxjava2 so build systems can use RxJavaFX 1.x and 2.x in the same project #53

Updated RxJava dependency to 2.1.0

Source code(tar.gz)
Source code(zip)
2.0.2(Feb 25, 2017)

Refactored to use io.reactivex.rxjavafx domain instead of rx.
Source code(tar.gz)
Source code(zip)
2.0.1(Feb 25, 2017)
RxJavaFX Now Supports RxJava 2.0

Re-released to trigger rebuild

RxJava 2.0 is a ground-up rewrite of RxJava that makes many critical changes to the ReactiveX implementation for Java. You can read more about what is different in RxJava 2.0 here. Documentation on RxJava 2.0 is an ongoing effort, and the Learning RxJava with JavaFX eBook will be updated accordingly. I will also be publishing Learning RxJava, the first book covering RxJava 2.0, later this year with Packt Publishing.

The primary difference between RxJava 1.0 and 2.0 is the separation of the Observable into the Observable and Flowable types. The Observable in RxJava 1.0 supports backpressure, but in hindsight RxJava leadership realized it would have been better to create a separate backpressured type. In RxJava 2.0, this became the Flowable and backpressure was removed from the Observable. The Subscriber was separated into the Observer and Subscriber types, where the Observer is used to subscribe to Observables and the Subscriber to Flowables.

This means there are a few changes for RxJavaFX 2.0, which is the starting version utilizing RxJava 2.0:

Since UI events cannot be backpressured, most of the source factories have been left alone and still yield Observables (and not Flowables).

RxJava 2.0 Observables forbid emitting null values, so JavaFxObservable.valuesOf() will ignore null values. If you want null values to be emitted, you will need to use JavaFxObservable.nullableValuesOf() to emit nullable values as Java 8 Optionals.

JavaFX Bindings now need to receive emissions from both Observables or Flowables. The JavaFxSubscriber utility class has been separated into JavaFxObserver and JavaFxSubscriber, which create Bindings off Observables and Flowables respectively.

JavaFxTransformers also has been split into FxObservableTransformers and FxFlowableTransformers, so JavaFX-specific operators are supported for both Observables and Flowables.

All deprecations from RxJavaFX 1.0 have been removed. The old factory naming conventions as well as JavaFxScheduler.getInstance() are gone.

Please feel free to contact me or file an issue if you have any questions or concerns. Also, a special thanks to @protogenes for helping expedite this rollout.
Source code(tar.gz)
Source code(zip)
2.0.0(Feb 25, 2017)
RxJavaFX Now Supports RxJava 2.0

RxJava 2.0 is a ground-up rewrite of RxJava that makes many critical changes to the ReactiveX implementation for Java. You can read more about what is different in RxJava 2.0 here. Documentation on RxJava 2.0 is an ongoing effort, and the Learning RxJava with JavaFX eBook will be updated accordingly. I will also be publishing Learning RxJava, the first book covering RxJava 2.0, later this year with Packt Publishing.

The primary difference between RxJava 1.0 and 2.0 is the separation of the Observable into the Observable and Flowable types. The Observable in RxJava 1.0 supports backpressure, but in hindsight RxJava leadership realized it would have been better to create a separate backpressured type. In RxJava 2.0, this became the Flowable and backpressure was removed from the Observable. The Subscriber was separated into the Observer and Subscriber types, where the Observer is used to subscribe to Observables and the Subscriber to Flowables.

This means there are a few changes for RxJavaFX 2.0, which is the starting version utilizing RxJava 2.0:

Since UI events cannot be backpressured, most of the source factories have been left alone and still yield Observables (and not Flowables).

RxJava 2.0 Observables forbid emitting null values, so JavaFxObservable.valuesOf() will ignore null values. If you want null values to be emitted, you will need to use JavaFxObservable.nullableValuesOf() to emit nullable values as Java 8 Optionals.

JavaFX Bindings now need to receive emissions from both Observables or Flowables. The JavaFxSubscriber utility class has been separated into JavaFxObserver and JavaFxSubscriber, which create Bindings off Observables and Flowables respectively.

JavaFxTransformers also has been split into FxObservableTransformers and FxFlowableTransformers, so JavaFX-specific operators are supported for both Observables and Flowables.

All deprecations from RxJavaFX 1.0 have been removed. The old factory naming conventions as well as JavaFxScheduler.getInstance() are gone.

Please feel free to contact me or file an issue if you have any questions or concerns. Also, a special thanks to @protogenes for helping expedite this rollout.
Source code(tar.gz)
Source code(zip)
rxjavafx-2.0.0.jar(53.96 KB)
2.0.0-RC1(Feb 24, 2017)
This is the pre-release of RxJavaFX 2.0, which is backed by RxJava 2.0.

For the most part, the API is largely the same as RxJavaFX 1.0. Most differences are due to the core changes in RxJava 2.0.

Please help test for functionality and share feedback on the API design. When all concerns are addressed, we will release RxJavaFX 2.0.

Key Differences:

JavaFxObservable.valuesOf() ignores null values

JavaFxObservable.nullableValuesOf() added to emit null values wrapped in a Java 8 Optional<T>

JavaFXObservable.nonNullValuesOf() has been removed

JavaFxSubscriber.toBinding() is overloaded to support both Observables and Flowables

JavaFxTransformers has been separated into FxFlowableTransformers and FxObservableTransformers

JavaFxSubscriber.toLazyBinding() has been removed due to implementation challenges.

JavaFxScheduler.getInstance() factory has been removed in favor of JavaFxScheduler.platform()

Source code(tar.gz)
Source code(zip)
rxjavafx-2.0.0-RC1.jar(57.66 KB)
1.1.0(Feb 25, 2017)
Many thanks to @protogenes for being the driver of this release.

NEW FEATURES

Implemented @protogenes' new JavaFxScheduler implementation that features less overhead and improved performance.

Added JavaFxObservable.invalidationsOf() factory

Source code(tar.gz)
Source code(zip)
1.0.0(Dec 18, 2016)
After nearly a year of controlled experimentation and prototyping, RxJavaFX 1.0.0 has finally been released. There should be no breaking changes to upgrade to this version, however there are some sweeping deprecations as well as some new features.

Nearly all factories in JavaFxObservable have been deprecated and replaced with more concise factory names inspired by ReactFX. For instance, fromObservableValue() is now valuesOf(). The RxJavaFX Guide will be updated later to reflect these new naming conventions.

In JavaFxObservable, there are now nonNullValuesOf() and nonNullChangesOf() factories that effectively supress null values emitted from an ObservableValue.

The CompositeObservable @Beta tag has been removed.

A new set of Transformers have been provided via the JavaFxTransformers static class. These are new Rx operators specific to JavaFX

doOnNextFx() - same as doOnNext() but executes on FX thread

doOnCompletedFx() - same as doOnCompleted() but executes on FX thread

doOnErrorFx() - same as doOnError() but executes on FX thread

doOnSubscribeFx() - same as doOnSubscribe() but executes on FX thread

doOnUnsubscribeFx() - same as doOnUnsubscribe() but executes on FX thread

doOnTerminateFx() - same as doOnTerminate() but executes on FX thread

doOnNextCount() - performs the provided action with the emission count for each onNext() call

doOnCompletedCount() - performs the provided action with the emission count for an onCompleted() call

doOnErrorCount() - performs the provided action with the emission count for an onError() call

doOnNextCountFx() - same as doOnNextCount() but executes on FX thread

doOnCompletedCountFx() - same as doOnCompletedCount() but executes on FX thread

doOnErrorCountFx() - same as doOnErrorCount() but executes on FX thread

The doOnXXXCount() operators are helpful for updating the UI with a status on how many emissions have been processed (e.g. through a ProgressBar or a simple Label with the count).

The 1.x branch is now the primary branch. Next on the roadmap is to implement this library with RxJava 2.0 on the 2.x branch. RxJava 2.0 brings some drastic changes with it and we will need a separate RxJavaFX 2.0 implementation to support it.

RxKotlinFX will get a 1.0 release this week as well.
Source code(tar.gz)
Source code(zip)
0.3.0(Nov 7, 2016)
Backed CompositeObservable with a serialized PublishSubject, allowing sources to be removed from a CompositeObservable at any time.

CompositeObservable#add() now returns a Subscription that can be used to unsubscribe() the CompositeObservable from a source Observable.

addAll() will return a CompositeSubscription containing all the Subscriptions.

remove(), removeAll(), clear(), and getSources() were removed from CompositeObservable as they are no longer are relevant due to above changes.

Source code(tar.gz)
Source code(zip)
0.2.0(Sep 11, 2016)
This release might break any previous usages of CompositeObservable, which now optionally accepts a Transformer. Any other constructors to control caching have been removed, as these were broken and now remedied by this new solution.

The CompositeObservable is modified to optionally accept a Transformer as a constructor argument. This Transformer is applied to the combined Observable so as to allow further manipulations yielded by toObservable().

You can leverage this Transformer to multicast the outputted Observable or (as shown in the example below) replay the last emission from the combined emissions.

CompositeObservable<String> source = new CompositeObservable<>(obs -> obs.replay(1).refCount()); source.toObservable().subscribe(System.out::println); source.add(Observable.just("Alpha","Beta","Gamma")); source.add(Observable.just("Delta","Epsilon")); Thread.sleep(1000); source.toObservable().subscribe(System.out::println);

OUTPUT:

Alpha Beta Gamma Delta Epsilon Epsilon
Source code(tar.gz)
Source code(zip)
0.1.4(Jul 26, 2016)
Fixed JavaFxObservable#fromObservableSet() not emitting anything

Implemented addAll(), removeAll(), clear(), and getBackingSet() methods on CompositeObservable

Source code(tar.gz)
Source code(zip)
0.1.3(Jul 24, 2016)

Fixed CompositeObservable dupe issue from 0.1.2

ADDED CompositeObservable for merging multiple Observables, but allows Observables to be added/removed at any time. Helpful for consolidating multiple UI event sourcesx

MODIFIED Removed dupe initial emission from ObservableSetSource.fromObservableSet() factory
Source code(tar.gz)
Source code(zip)
0.1.2(Jul 24, 2016)

ADDED CompositeObservable for merging multiple Observables, but allows Observables to be added/removed at any time. Helpful for consolidating multiple UI event sources

MODIFIED Removed dupe initial emission from ObservableSetSource.fromObservableSet() factory
Source code(tar.gz)
Source code(zip)
0.1.1(Jul 14, 2016)
ADDED

JavaFxObservable.fromDialog() factory which will emit the result of a Dialog<T> as an Observable<T>.

MODIFIED

JavaFxObservable.fromObservableList() now does an initial emission of the ObservableList before any changes occur.

JavaFxObservable.fromObservableMap() now does an initial emission of the ObservableMap before any changes occur.

JavaFxObservable.fromObservableSet() now does an initial emission of the ObservableSet before any changes occur.

Source code(tar.gz)
Source code(zip)
0.1.0(Jun 30, 2016)
Two new functionalities were added to this release.

JavaFX interval()

Added following factory to emit consecutive Long values at a set interval on the JavaFX thread. See #34

JavaFxObservable.interval(Duration duration)

Lazy RxJava Bindings

Two more Binding factories were added to turn an RxJava Observable into a JavaFX Binding, and now there is an option to call toLazyBinding() and not just toBinding(). This will result in the Binding implementation delaying subscription to the Observable until a value is requested from it. #35.

JavaFxSubscriber.toLazyBinding(Observable<T> observable) JavaFxSubscriber.toLazyBinding(Observable<T> observable, Action1<Throwable> onError)
Source code(tar.gz)
Source code(zip)
0.0.7(May 28, 2016)
Added factories to turn ObservableMap<K,T> events into several flavors of Observable<R>

Added factories to turn ObservableSet<T> events into several flavors of Observable<R>

Source code(tar.gz)
Source code(zip)
0.0.6(Apr 30, 2016)

Added CompositeBinding, a JavaFX equivalent to CompositeSubscription. See #23
Source code(tar.gz)
Source code(zip)
0.0.5(Mar 15, 2016)
See README for new features

ObservableList to Observable factory support

Improved JavaFxScheduler with trampoline mechanism

Special thanks to @akarnokd for his help with the JavaFxScheduler.
Source code(tar.gz)
Source code(zip)
0.0.4(Mar 8, 2016)
New factories added to JavaFxObservable:

fromSceneEvents()

fromWindowEvents()

fromActionEvents(), with overloads for Node, MenuItem, and ContextMenu

Source code(tar.gz)
Source code(zip)
0.0.3(Feb 14, 2016)
Refer to README to see new features.

Observable to Binding conversion

Value change factories

Source code(tar.gz)
Source code(zip)
0.0.2(Jan 9, 2016)

After a long delay, we are excited to release RxJavaFX. This simple API allows you to turn JavaFX ObservableValues and Node Events into a reactive Observable stream with all the RxJava goodness. It also comes with a JavaFX Scheduler so you can safely schedule emissions on a JavaFX thread at any time.
Source code(tar.gz)
Source code(zip)
rxjavafx-0.0.2.jar(16.29 KB)