feed.xml

Animated Transitions Made Easy

Fri, 13 Feb 2015 00:00:00 +0000

In the previous post I presented ReactFX’s Val as an improved ObservableValue. In ReactFX 2.0 Milestone 3 it got even better: changes to values can be animated seamlessly.

This work was initially inspired by Mike Hearn’s animatedBind function, but the API is rather different.

TL;DR Version

In short, in order to make a value animate, you just need to specify the duration of the transition and the interpolation for the animated value.

Val<Double> val = ...;
Val<Double> animated = val.animate(Duration.ofMillis(500), EASE_BOTH_DOUBLE);

Use adapter static methods if you don’t yet have a Val:

ObservableValue<Double> val = ...;
Val<Double> animated = Val.animate(val, Duration.ofMillis(500), EASE_BOTH_DOUBLE);

Example: Animating Circle Center

We will be changing the center of a circle and we want the circle to move smoothly to the new location, instead of jumping there right away. So we have a circle and a property that we will be changing in order to move the circle:

Circle circle = new Circle(30.0, Color.BLUE);
Var<Point2D> center = Var.newSimpleVar(new Point2D(15.0, 15.0));

Remember, Var is just a Property with some additional methods. We are now going to define a value that transitions smoothly to the value of center whenever center changes; call it animCenter:

1
2
3
Val<Point2D> animCenter = center.animate(
        Duration.ofMillis(400),
        (p1, p2, frac) -> p1.multiply(1.0-frac).add(p2.multiply(frac)));

On line 1, animate is one of those additional methods defined on Val/Var.
On line 2, we specified the duration of the transition.
On line 3, we defined the interpolation between the start and end point. It is a linear interpolation between p1 and p2.

Now we just need to bind the circle center to the animated center and we are all set. This needs to be done in two steps—binding the x coordinate and binding the y coordinate:

circle.centerXProperty().bind(animCenter.map(Point2D::getX));
circle.centerYProperty().bind(animCenter.map(Point2D::getY));

Et voilà, the circle now transitions smoothly to the new position.

Constant Duration vs. Constant Speed

One thing you may notice in the example above is that the circle moves faster when the new position is far from the current position than when it is close to the current position. This is because we specified constant duration of 400 milliseconds for each transition, no matter how far the circle has to travel. If we instead want a constant speed of the circle, we can define the duration as a function of the start and end points:

Val<Point2D> animCenter = center.animate(
        (p1, p2) -> Duration.ofMillis((long) p1.distance(p2)),
        (p1, p2, frac) -> p1.multiply(1.0-frac).add(p2.multiply(frac)));

The only difference is on the second line, where now the duration of the transition is proportional to the distance between the two points. Now the speed of the circle will be the same for short and long distances, but it will take longer to travel longer distances.

Here is the full source code of this demo, where clicking on the circle will relocate it to a random position.

Does it animate even if no one is listening?

No! If there is no observer of the animated value, there is no animation going on in the background and no system resources are used. Just saying

Val<T> animated = val.animate(duration, interpolator);

does not start the animation yet. Only when a listener is registered with the animated value does a JavaFX animation start in the background. As soon as all the listeners are removed, the background animation is stopped. In other words, animated values follow the ReactFX’s general philosophy of lazy binding.

Val<T>: a better ObservableValue

Tue, 10 Feb 2015 00:00:00 +0000

ObservableValue is the JavaFX way of representing a time-varying value, whose changes can be observed by a listener. As it is, it really is a bare bones interface. I myself have previously enriched it in two different ways: EasyBind’s MonadicObservableValue that adds some useful operations, and InhiBeans to postpone listener notifications. Val, introduced in ReactFX 2.0 Milestone 2, integrates both these ideas and adds some more.

Rich set of additional operations

Additional operations taken from EasyBind’s MonadicObservableValue, the most popular probably being flatMap a.k.a. type-safe select:

Val<Boolean> showing = Val.flatMap(node.sceneProperty(), Scene::windowProperty)
        .flatMap(Window::showingProperty);

Suspendable listener notifications

InhiBeans’ ability to avoid glitches by temporary suspension of listener notifications has been absorbed by Val:

DoubleProperty width = new SimpleDoubleProperty(1.0);
DoubleProperty height = new SimpleDoubleProperty(2.0);
Val<Number> area = Val.suspendable(Bindings.multiply(width, height));
area.suspendWhile(() -> {
    width.set(3.0);
    height.set(4.0);
});

In this sample, any observer of area will only observe a single change from 2.0 to 12.0 (instead of a change from 2.0 to 6.0 and another change from 6.0 to 12.0).

Lazily bound to dependencies

You can combine Vals to form new Vals. In JavaFX, this is known as creating bindings. There is one subtle but important difference in how these compound Vals bind to (i.e. start observing) their dependencies. Consider the following example:

Val<Double> width = // ...
Val<Double> height = // ...
Val<Double> area = Val.combine(width, height, (w, h) -> w * h);

At this point, there is no listener registered with either width or height. When the first listener is attached to area, only at that point does area start observing width and height. Similarly, when the last listener is unregistered from area, area stops observing width and height. I call this lazy binding, for the lack of a better name. This should be familiar to ReactFX users, because this is how EventStreams have always done binding to their inputs. This concept is also known as cold observables in Rx.

In the previous post I promised to give a better alternative to using WeakListeners for bindings. Lazy binding is that alternative. No matter how big the network of bindings is, you only need to remove those listeners that you have registered. All intermediate links will be “disposed” automatically. No weak listeners needed, both problems mentioned in the previous post avoided.

Correct behavior on recursive changes

It is possible that a change triggers another change of the same observable value. Changes reported by JavaFX’s observable values in that case are simply not correct.

Let’s show an example. The program below creates an IntegerProperty with initial value 0 and attaches two change listeners to it. The first change listener looks at the new value val and if it is greater than 0, (recursively) sets the property to val - 1. The second listener just prints the changes it observes to the standard output. Let’s change the property value and see what happens.

IntegerProperty p = new SimpleIntegerProperty(0);
p.addListener((obs, old, val) -> {
    if(val.intValue() > 0) {
        p.set(val.intValue() - 1);
    }
});
p.addListener((obs, old, val) -> System.out.println(old + " -> " + val));
p.set(2);

The output is

-> 0
-> 0
-> 0

which means that the second listener saw the value of the property changing from 1 to 0, then from 2 to 0, and finally from 0 to 0. This is just wrong. The value was actually changing like this: 0 -> 2 -> 1 -> 0. Any of the following sequences of observed changes would be consistent with what happened:

```
[0 -> 2, 2 -> 1, 1 -> 0],
```
```
[0 -> 2, 2     ->     0],
```
```
[0     ->     1, 1 -> 0],
```

[                      ] (no change observed),

but the listener observed something else.

Let’s rewrite the above program using Var, writable variant of Val:

Var<Integer> p = Var.newSimpleVar(0);
p.addListener((obs, old, val) -> {
    if(val > 0) {
        p.setValue(val - 1);
    }
});
p.addListener((obs, old, val) -> System.out.println(old + " -> " + val));
p.setValue(2);

The output of this program is

0 -> 1
1 -> 0

which is consistent with what actually happened.

The Trouble with Weak Listeners

Tue, 10 Feb 2015 00:00:00 +0000

JavaFX bindings use WeakListeners to observe their dependencies. This reduces the need to dispose() bindings, but comes with some surprising behavior. In this post I show two kinds of problems introduced by weak listeners. In the next post, I will show how we can do better without weak listeners.

Why Weak Listeners

(This section is my attempt to “reverse-engineer” the motivation behind weak listeners. This will be familiar to most readers, so feel free to skip to the next section.)

In a straightforward implementation, a Binding would need to be dispose()d in order to stop observing its dependencies and become eligible for garbage collection. This could get really cumbersome when you have something like this:

DoubleExpression x = // ...
DoubleBinding result = Bindings.max(x.add(5.0).multiply(7.0), 100.0);

In order to dispose the above binding correctly, it is not sufficient to do result.dispose()—one would need to dispose all the intermediate bindings as well:

DoubleExpression x = // ...
DoubleBinding intermediate1 = x.add(5.0);
DoubleBinding intermediate2 = intermediate.multiply(7.0);
DoubleBinding result = Bindings.max(intermediate2, 100.0);

// dispose
intermediate1.dispose();
intermediate2.dispose();
result.dispose();

(I know, I know, it should be sufficient to dispose intermediate1, but still…)

As you can see, this is very impractical, so there is a trick: weak listeners! In the above example, x holds only a weak reference to intermediate1, which in turn holds a weak reference to intermediate2, which holds a weak reference to result. Hence, dispose() is optional—bindings will be garbage collected when they are no longer strongly reachable.

Problem 1: Accidental Garbage Collection

DoubleExpression x = new SimpleDoubleProperty(0.0);
Bindings.max(x.add(5.0).multiply(7.0), 100.0).addListener(listener);
x.set(1.0);

Guess what: the listener may never be executed. Surprise! All the intermediate bindings may be garbage collected right away. For most readers, this is old news. And they already know that they need to store a reference to the resulting binding to prevent garbage collection:

DoubleExpression x = new SimpleDoubleProperty(0.0);
this.result = Bindings.max(x.add(5.0).multiply(7.0), 100.0);
this.result.addListener(listener);
x.set(1.0);

Still, this keeps biting people over and over.

Problem 2: Memory Leaks

This problem is more subtle and less known. That’s right, weak listeners do not entirely prevent memory leaks. It has been reported before and closed as “Won’t Fix”.

A weak listener is a wrapper that holds a weak reference to the actual (non-weak) listener. It is true that when the actual listener is no longer strongly reachable, it will be garbage collected. But what about removing the wrapper (holding the now cleared weak reference) from the list of listeners of an observable? The wrapper clears itself when it is invoked and finds out its actual listener is gone. The problem arises when the observable is never invalidated again, and thus the weak listener does not get a chance to clear itself. Here is an example that amplifies the problem by registering many weak listeners to an observable that is never invalidated:

The output of this program is

Used Memory after GC: 52.73 MB

UPDATE:

Now that I have presented Vals/Vars, here is the same program rewritten using Vals/Vars. It still does nothing, but does it much more efficiently.

And the output is

Used Memory after GC: 0.98 MB

Measuring FPS with ReactFX

Sun, 08 Feb 2015 00:00:00 +0000

I came across this StackOverflow question about measuring frame rate in JavaFX and while James_D gave a nice solution, I still found it a little too verbose for such a simple task.

So I just added one more feature before releasing ReactFX 2.0 Milestone 2, namely animationTicks(). Using that, the solution now looks like this:

EventStreams.animationTicks()
        .latestN(100)
        .map(ticks -> {
            int n = ticks.size() - 1;
            return n * 1_000_000_000.0 / (ticks.get(n) - ticks.get(0));
        })
        .map(d -> String.format("FPS: %.3f", d))
        .feedTo(label.textProperty());

Here is the full runnable demo, adapted from James’ answer.

RichTextFX just got faster

Sun, 06 Jul 2014 00:00:00 +0000

When I started working with JavaFX almost a year ago, there was no native JavaFX code-editing control. Just like any decent programming language hosts its own compiler, I believe any decent UI toolkit should host its own IDE. And you cannot have an IDE without a code editor. It is great that JavaFX allows you to embed HTML and Javascript, but on the other hand, I found it somewhat embarassing that users of the best UI toolkit on the planet had to resort to embedding HTML to get a text editor with syntax highlighting. So I started CodeAreaFX, which evolved to RichTextFX.

It had been noted before that for performance it was crucial to use a virtual layout, such as ListView. A virtual layout is one that only calculates the visible part of the scene. So I used ListView to lay out lines of text. The performance still was not great. Now I felt embarassed that those embedded Javascript editors probably performed better than my native solution. It turned out ListView was doing unnecessarily many cell updates. Combined with the complexity of TextFlow, it was too slow to destroy, recreate and apply style to the whole viewport of, say, 30 lines of code on every typed character.

I set out to optimize and Flowless was born. Flowless is a virtual flow implementation with emphasis on eliminating unnecessary cell updates. Using Flowless, I get smooth editing experience even on an old (2010) laptop. You, too, can use Flowless in your applications in place of ListView if too many updateItem calls hinder the performance of your app. Note, however, that Flowless is a low-level layout container and you will have to make an extra effort to implement features like selection or inline editing. It would be great if someone from the community implemented a full-featured ListView on top of Flowless :wink:.

RichTextFX itself is a flexible low-level component able to support rich-text editing, syntax highlighting and more, but does not come with batteries included (by design). The upside is that you can use any lexer/parser you like. The downside is that you have to wire the lexer/parser to RichTextFX yourself (which is not difficult at all, but still…). Hopefully next time someone uses RichTextFX as the code editor in their project, they will consider wiring in a lexer with support for many languages and publish their work online :wink:.

Separation of View and Controller in JavaFX Controls

Wed, 11 Jun 2014 00:00:00 +0000

This post first really quickly introduces skins for JavaFX controls, then discusses the non-public base class for skin implementations (BehaviorSkinBase) and its pitfalls, and finally outlines how public API for Skin implementations that encourages separation of view and controller could look. This post presents a lesson learned from my recent refactoring of RichTextFX.

Skins

I cannot do a better job of introducing skins than the Javadoc of the javafx.scene.control package:

Controls follow the classic MVC design pattern. The Control is the “model”. It contains both the state and the functions which manipulate that state. The Control class itself does not know how it is rendered or what the user interaction is. These tasks are delegated to the Skin (“view”), which may internally separate out the view and controller functionality into separate classes, although at present there is no public API for the “controller” aspect.

[…] It is also the responsibility of the Skin, or a delegate of the Skin, to implement and respond to all relevant key events which occur on the Control when it contains the focus.

Illustrated, it looks like this:

The skin observes and acts on the control, where, “observes” means listens to events (e.g. mouse events, key events), property changes, observable collections changes, and, more generally, calls functions that do not alter the control’s state; “acts on” means calls functions to manipulate the control’s state. The arrow also means that the skin holds a reference to the control, but not the other way around.¹⁾

The documentation further suggests to separate the view and controller functionality into separate classes. It does not currently provide any API for this, neither does it say anything about the relationship between the view and the controller:

BehaviorSkinBase

Skins in JavaFX extend from BehaviorSkinBase, which is not part of the public API.²⁾ BehaviorSkinBase takes care of the view functionality, and delegates the controller functionality to Behavior. BehaviorSkinBase constructor takes a Behavior instance and makes it visible to subclasses, so that they can invoke methods on the behavior. Thus with BehaviorSkinBase, the undefined relationship from the previous diagram is “View acts on Controller” (which, in turn, acts on the model):

From my limited exposure to skin implementations, the possibility of view invoking methods on the controller is rarely utilized, and where it is, the code could probably benefit from some refactoring (as did RichTextFX).

The problem with BehaviorSkinBase

A real complication arises when the controller, in order to implement proper behavior of the control, needs to get some additional information from the view. Consider a text area. The model of a text area knows the caret position in terms of the index in the text, but does not know the caret coordinates on the screen or how paragraphs are broken into lines. To implement Up/Down key navigation, the controller needs to update the model with the new caret position (new index in the text). To this end, the controller needs to get additional information from the skin, because the new caret position depends on the current screen coordinates of the caret, as well as on how paragraphs are currently broken into lines.

This means there needs to be a back reference from the controller to the view. In the previous paragraph we have seen that this reference cannot, in general, be eliminated. On the other hand, I have come to believe that the other reference, the one from the view to the controller, can and should be eliminated.

Alternative architecture

That leaves us with this architecture that we should be implementing:

The only difference from the BehaviorSkinBase architecture above is that we flipped one arrow.

Now let’s put together some API that encourages this design. Let’s have interface Visual for views and interface Behavior for controllers. Let’s have a final class BehaviorSkin that implements Skin and the only thing it does is that it creates the Visual and the Behavior.

public interface Visual {
    Node getNode();
    void dispose();
    List<CssMetaData<? extends Styleable, ?>> getCssMetaData();
}

public interface Behavior {
    void dispose();
}

public final class BehaviorSkin<C extends Control, V extends Visual>
extends SkinBase<C> {
    private final V visual;
    private final Behavior behavior;
    private final Node node;

    public BehaviorSkin(
            C control,
            Function<? super C, ? extends V> visualFactory,
            BiFunction<? super C, ? super V, ? extends Behavior> behaviorFactory) {
        super(control);
        this.visual = visualFactory.apply(control);
        this.behavior = behaviorFactory.apply(control, visual);
        this.node = visual.getNode();
        getChildren().add(node);
    }

    @Override
    public void dispose() {
        getChildren().remove(node);
        behavior.dispose();
        visual.dispose();
    }


    @Override
    public List<CssMetaData<? extends Styleable, ?>> getCssMetaData() {
        return visual.getCssMetaData();
    }
}

The general template for the Control’s createDefaultSkin() method will look like this:

protected Skin<?> createDefaultSkin() {
    return new BehaviorSkin<>(
            this,
            control -> new FooVisual(control),
            (control, visual) -> new FooBehavior(control, visual));
}

or more concisely using constructor references

protected Skin<?> createDefaultSkin() {
    return new BehaviorSkin<>(this, FooVisual::new, FooBehavior::new);
}

Note that the factory function for Visual gets only the control as the argument, while the factory function for Behavior gets the control as well as the Visual.

Also note that BehaviorSkin does not implement Skin directly, but instead extends SkinBase, which is already part of the public API.

The Behavior implementation may still extend from BehaviorBase where it did before, though this class is not part of the public API either.

UPDATE: I have fleshed out the API also for skins that are not represented by a single node, but need direct access control’s child list. Here is the Javadoc for the updated API.

Conclusion

The outlined extension to the API for skin implementations is rather conservative—it does not present any radical shifts. Its main goal is to encourage separation of view and controller aspects. It does not address other challenges connected with skin implementations, such as a mechanism to bind key events to actions (which would be the responsibility of the BehaviorBase class). On the other hand, it does not close any doors to resolving such challenges.

1) Neglecting the fact that when attached to the scene, the control holds a reference to its skin, but as the author of the control, you don’t ever access the skin from the control.

2) Not being part of the public API means that you should not use BehaviorSkinBase in your applications. Anyway, it is used by JavaFX itself and some version of it may make it to the public API in the future, so I find it worth discussing.

Detecting when the mouse stays still over a node

Fri, 06 Jun 2014 00:00:00 +0000

Everyone has seen tooltips: the mouse enters a node, stays still for a while, and then a tooltip is displayed. JavaFX does have tooltips. They are easy to use, but not very flexible. For example, you cannot control the delay before the tooltip is shown or for how long it is shown. If you want to roll your own tooltip implementation, the first step is to detect when and where the mouse stays still.

For touch devices, JavaFX has the TOUCH_STATIONARY event. There’s no such event for mouse, so we are going to simulate it by means of available mouse events.

Plan

Detect all mouse events on a node. When a MOUSE_MOVED event hasn’t been followed by any mouse event for 1 second, we conclude that the mouse is stationary. When the next mouse event arrives, we conclude that the mouse stopped being stationary. We are going to create a ReactFX event stream that emits the mouse position when the mouse becomes stationary and null when it stops being stationary.

Solution

1
2
3
4
5
6
7
8
9
10
11
12
EventStream<MouseEvent> mouseEvents = eventsOf(node, MouseEvent.ANY);

EventStream<Point2D> stationaryPositions = mouseEvents
        .successionEnds(Duration.ofSeconds(1))
        .filter(e -> e.getEventType() == MouseEvent.MOUSE_MOVED)
        .map(e -> new Point2D(e.getX(), e.getY()));

EventStream<Void> stoppers = mouseEvents.supply((Void) null);

EventStream<Either<Point2D, Void>> stationaryEvents =
        stationaryPositions.or(stoppers)
                .distinct();

Line 1 creates a stream of all mouse events on node.
Line 4 keeps only events that haven’t been followed by another one for 1 second.
Line 5 further filters the stream to contain only mouse moves.
This means that, for example, if the last event is a click and then the mouse stays still, it is not detected as mouse being stationary. Note that this is consistent with how tooltips work—the tooltip is not displayed after the node is clicked.
Line 6 converts mouse events to mouse positions.
Line 8 declares that any mouse event is a reason to end the stationary state.
Line 11 includes both types of events (started being stationary and stopped being stationary) in one stream.
Line 12 filters out repeating stopped being stationary events.

Highlights

There are no mutable variables to track state, like lastMousePosition or isStationary. Any use of timers to measure the 1 second delay is completely hidden as well. All the variables above are effectively final and all state is managed by the event streams.
There is no CPU overhead when no one is actually subscribed to stationaryEvents. This is due to the lazy nature of event streams. Only when someone subscribes to stationaryEvents does this propagate all the way down and an event handler is registered for mouse events on the node.

Usage

stationaryEvents.subscribe(either -> either.exec(
        pos -> showTooltipAt(pos),
        stop -> hideTooltip()
));

Optionally: Dispatch `MouseStationaryEvent`s on a node

You may want to use JavaFX’s standard addEventHandler method to detect when the mouse starts and stops being stationary.

Let’s define MouseStationaryEvent with the following API:

public class MouseStationaryEvent extends InputEvent {

    public static final EventType<MouseStationaryEvent> ANY;
    public static final EventType<MouseStationaryEvent> MOUSE_STATIONARY_BEGIN;
    public static final EventType<MouseStationaryEvent> MOUSE_STATIONARY_END;

    /** Creates a new event of type MOUSE_STATIONARY_BEGIN. */
    static final MouseStationaryEvent beginAt(Point2D screenPos);

    /** Creates a new event of type MOUSE_STATIONARY_END. */
    static final MouseStationaryEvent end();

    public Point2D getPosition();
    public Point2D getScenePosition();
    public Point2D getScreenPosition();
}

Implementation of this class is not very interesting, but is provided here for completeness.

Now, to start dispatching MouseStationaryEvents for a node, you simply do this:

EventStream<Either<Point2D, Void>> stationaryEvents = // defined above

stationaryEvents.<Event>map(either -> either.unify(
        pos -> MouseStationaryEvent.beginAt(node.localToScreen(pos)),
        stop -> MouseStationaryEvent.end()))
    .subscribe(evt -> Event.fireEvent(node, evt));

The unify operator converts a stream of either Point2D or Void to a stream of a single type MouseStationaryEvent. Point2Ds are converted to a MouseStaionaryEvent of type MOUSE_STATIONARY_BEGIN and Voids are converted to a MouseStationaryEvent of type MOUSE_STATIONARY_END.

Usage

node.addEventHandler(MOUSE_STATIONARY_BEGIN, e -> {
    showTooltipAt(e.getScreenPosition());
});

node.addEventHandler(MOUSE_STATIONARY_END, e -> {
    hideTooltip();
});

Convenient helper class

Finally, here is a helper class combining all of the above that you can use in your projects.

Usage

// detect stationary events on a node after 1 second delay
MouseStationaryHelper helper =
        new MouseStationaryHelper(node, Duration.ofSeconds(1));

helper.events().subscribe(either -> either.exec(
        pos -> showTooltipAt(pos),
        stop -> hideTooltip()
));

// If you would rather use standard JavaFX way,
// start dispatching MouseStationaryEvents on the node.
helper.install();

node.addEventHandler(MOUSE_STATIONARY_BEGIN, e -> {
    showTooltipAt(e.getScreenPosition());
});

node.addEventHandler(MOUSE_STATIONARY_END, e -> {
    hideTooltip();
});

// optionally, stop dispatching MouseStationaryEvents
helper.uninstall();

Timers in JavaFX and ReactFX

Wed, 04 Jun 2014 00:00:00 +0000

The takeaway from this post should be that to schedule future actions in a JavaFX application you don’t need an external timer (and thus an extra thread in your application), such as java.util.Timer or java.util.concurrent.ScheduledExecutorService. You can use Timeline or FxTimer, a convenient wrapper around Timeline used internally in ReactFX and recently exposed as public API.

One-time action

This is how to use Timeline to schedule a one-time action:

Timeline timeline = new Timeline(new KeyFrame(
        Duration.millis(2500),
        ae -> doSomething()));
timeline.play();

Equivalently, you can use this ReactFX shortcut:

FxTimer.runLater(
        Duration.ofMillis(2500),
        () -> doSomething());

In addition to the latter being more readable, FxTimer uses the new Java Time API introduced in JDK 8.

Periodic action

This is how to schedule a periodic action using Timeline:

Timeline timeline = new Timeline(new KeyFrame(
        Duration.millis(2500),
        ae -> doSomething()));
timeline.setCycleCount(Animation.INDEFINITE);
timeline.play();

Using FxTimer, it looks like this:

FxTimer.runPeriodically(
        Duration.ofMillis(2500),
        () -> doSomething());

Or, because we really like event streams:

EventStreams.ticks(Duration.ofMillis(2500))
        .subscribe(tick -> doSomething());

Timer cancellation

Let’s see how one can cancel a scheduled action.

The Timeline way:

Timeline timeline = new Timeline(new KeyFrame(
        Duration.millis(2500),
        ae -> doSomething()));
timeline.play();

// later
timeline.stop();

The FxTimer way:

Timer timer = FxTimer.runLater(
        Duration.ofMillis(2500),
        () -> doSomething());

// later
timer.stop();

There is one important semantic difference between the above code snippets. In the first one, doSomething() may still be executed after timeline.stop(), even though both timeline.stop() and doSomething() are executed on the JavaFX application thread. It happens when stop() is called after the timeline has reached the key frame, but before the associated action had a chance to be executed on the JavaFX application thread. EDIT: Note that this behavior makes sense for animations: if there is an action a associated with time t1 and stop() is called at time t2 > t1, then, if not already done so, a should still be executed in order to advance the animation to a state corresponding to t2.

On the other hand, for timers it makes sense to cancel the timer upon stop() even if the timer is already overdue. Therefore, FxTimer takes an extra measure to ensure that the action is never executed after stop().

Here is the code that shows that behavior.

How to ensure consistency of your observable state

Tue, 13 May 2014 00:00:00 +0000

In this post, I would like to make an appeal to JavaFX developers, especially library creators, to provide stronger consistency guaranties of their observable objects.

The problem

When implementing an object with two or more observable properties that should satisfy a certain invariant (i.e. they are not completely independent), it is often tricky to ensure that the invariant holds all the time the client code is able to query the values of the properties. The invariant often breaks for a brief moment when updating property values: a listener of the property to be updated first can observe the old state of the property to be updated next. As a consequence, the client code needs to be more defensive (i.e. longer and less clear) to handle potential inconsistencies.

We demonstrate the issue on TextArea. It has (among others) these properties: caretPosition, anchor, selection. There is a natural relationship that should hold between these three properties:

selection = (anchor, caretPosition), if anchor ≤ caretPosition;
selection = (caretPosition, anchor), otherwise.

Stated in code, it is

selection.equals(IndexRange.normalize(anchor, caretPosition))

So let’s write a program that tests the above invariant:

TextArea area = new TextArea();
area.caretPositionProperty().addListener(obs -> checkConsistency(area));
area.anchorProperty().addListener(obs -> checkConsistency(area));
area.selectionProperty().addListener(obs -> checkConsistency(area));

void checkConsistency(TextArea area) {
    IndexRange selection = area.getSelection();
    int caretPosition = area.getCaretPosition();
    int anchor = area.getAnchor();
    assert selection.equals(IndexRange.normalize(anchor, caretPosition));
}

Try the full runnable version. Don’t forget to enable assertions. Run the program and type a letter to the text area. You will get an AssertionError, which means the tested invariant has been broken.

Can we fix it?

Yes!

InhiBeans, a subpackage of ReactFX, provides property and binding implementations that allow you to update their value or invalidate them without notifying the listeners right away. You can update a number of properties and only then notify the listeners. By the time a listener of property p queries the value of property q, both properties will have been updated and thus consistent.

Here is a sketch of how one could fix the above inconsistency in TextArea:

Switch the implementation of caretPosition, anchor and selection properties for their counterpart from org.reactfx.inhibeans.

Replace any selectionChangingOperation() on TextArea (such as typing, moving the caret, …) by

 try(
     Guard g1 = caretPosition.block();
     Guard g2 = anchor.block();
     Guard g3 = selection.block()
 ) {
     selectionChangingOperation();
 }

or, more concisely

 Guardian.combine(caretPosition, anchor, selection)
         .guardWhile(() -> selectionChangingOperation());

Note: In some cases, you can provide consistency guaranties just by arranging the order of invalidation propagation among dependent properties and/or bindings. This solution, however, relies on the implementation detail that property and binding implementations provided by JavaFX itself notify the listeners in the order they were registered. It is therefore fragile to future changes or alternative property/binding implementations. Also, it gets complicated very quickly.

What about observable collections?

InhiBeans currently provide a wrapper for ObservableList that is able to temporarily block the notifications of list changes. All changes made to the list while blocked are combined into a single list change that is fired upon release. Blockable wrappers for other collections might be added in the future.

ReactFX's general stream combinator: State Machine

Thu, 01 May 2014 00:00:00 +0000

In ReactFX, we work with event streams. It provides various operations on event streams such as filter, map, merge, zip, combine, reduceSuccessions. Of course these cannot cover all the use cases. In such a case, you can either extend LazilyBoundStream to implement your custom stream combinator, or you can use the state machine combinator.

A state machine has a state and multiple input streams. An event emitted by an input stream causes the state machine to update its state and/or to emit an event. We demonstrate ReactFX’s internal DSL (fluent API) for defining state machines on an example.

Example

We implement a stream combinator that takes a source stream and two control streams. An event from one control stream mutes the source stream, an event from the other control stream unmutes the source stream. The resulting stream emits the same events as the source stream, but only when not muted. We are going to represent the internal state as a boolean indicating whether the source stream is muted.

1
2
3
4
5
6
7
8
9
EventStream<T> source = ...;
EventStream<?> muteImpulse = ...;
EventStream<?> unmuteImpulse = ...;

EventStream<T> combined = StateMachine.init(false)
    .on(muteImpulse).transition((wasMuted, i) -> true)
    .on(unmuteImpulse).transition((wasMuted, i) -> false)
    .on(source).emit((muted, t) -> muted ? Optional.empty() : Optional.of(t))
    .toEventStream();

On line 5 we set the initial state to false (not muted).
Line 6 says that when an event arrives from the muteImpulse stream, we set the internal state to true (muted), no matter what the previous state or the value of the impulse is.
Line 7 says that when an event arrives from the unmuteImpulse stream, we set the internal state to false (not muted), no matter what the previous state or the value of the impulse is.
Line 8 states that when an event arrives from the source stream, it is either emitted or not, based on the internal state (muted or not).
Line 9 completes the creation of the state machine and the associated stream.

feed.xml

Animated Transitions Made Easy

TL;DR Version

Example: Animating Circle Center

Constant Duration vs. Constant Speed

Does it animate even if no one is listening?

Val<T>: a better ObservableValue

Rich set of additional operations

Suspendable listener notifications

Lazily bound to dependencies

Correct behavior on recursive changes

The Trouble with Weak Listeners

Why Weak Listeners

Problem 1: Accidental Garbage Collection

Problem 2: Memory Leaks

Measuring FPS with ReactFX

RichTextFX just got faster

Separation of View and Controller in JavaFX Controls

Skins

BehaviorSkinBase

The problem with BehaviorSkinBase

Alternative architecture

Conclusion

Detecting when the mouse stays still over a node

Plan

Solution

Highlights

Usage

Optionally: Dispatch MouseStationaryEvents on a node

Usage

Convenient helper class

Usage

Timers in JavaFX and ReactFX

One-time action

Periodic action

Timer cancellation

How to ensure consistency of your observable state

The problem

Can we fix it?

What about observable collections?

ReactFX's general stream combinator: State Machine

Example

Optionally: Dispatch `MouseStationaryEvent`s on a node