An introduction to Open Dolphin

Last year I started to work at Canoo and some of you might know that Canoo provides the open source remoting middleware Open Dolphin. At the end of the last year I had the pleasure to work with Open Dolphin in a customer project. Based on the experience of this project I started to contribute to Open Dolphin because I think that it provides an interesting way to handle the remoting aspects of an application. In addition I will blog about Open Dolphin and how you can use it in (JavaFX) applications.

If I need to describe Open Dolphin in just a few words I would say that it is a library that syncs presentation models between a server and one or many clients. If you haven’t seen such an approach before it’s maybe hard to understand. Therefore I will start with a basic introduction of the core concepts with this post.


As you can see in the image the client and the server can access the same presentation model. Let’s think about the presentation model as any data model. There are some best practices what kind of data should be defined in a presentation model but first of all let us define this as a model with any data in it. Both the client and the server can read data from the model or edit data in the model. Open Dolphin will automatically sync the model between the server and the client. In addition Open Dolphin supports multiple clients and therefore a more correct diagram would look something like this:

As you can see in the picture all the different clients don’t know each other and the sync between the presentation models in centralized by the server. If client A edits a value in the presentation model it will be synchronized with the server. Once the server has updated it’s own presentation model with the new value the server synchronizes this change with all other clients. By doing you can create applications that share exactly the same presentation model. The following video shows a short example:

While the sharing of the presentation model between several clients is a very cool feature and big benefit most of the time you need to synchronize a model only between the server and one client. Therefore the examples that will be shown in the following post will all use this approach. Once this workflow is completely described I will start to introduce the sync of several clients in future posts.

Benefits of using Open Dolphin and presentation models

One big benefit of Open Dolphin is its independence to UI Toolkits. By default Open Dolphin doesn’t depend on any toolkit like JavaFX, Swing or GWT. By using Open Dolphin you can use the same presentation model for JavaFX and Java Script clients, for example. When using some of the best practices that I will show in future posts a migration from one UI technology to another one will be more easy by using Open Dolphin. In addition the creation of an application that supports different client implementations (for example mobile, desktop and web) can be based on Open Dolphin. By doing so only the view of the clients will be different because Open Dolphin capsulate the controller logic and the data model.
Next to the support of different client technologies Open Dolphin is based on the presentation model pattern. By doing so it combines many best practices to create MVC, MVP or MVVM applications. The following graphic shows how the MVC can be implemented by using Open Dolphin:


The presentation model

Let’s have a deeper look at the presentation models and how such a model is structured and managed in Open Dolphin. Each presentation model is defined by an unique id. In addition a presentation model can be specified by a type. Both values are defined as a string. Open Dolphin provides methods to find a specific presentation model by its id or all presentation models of a given type.

A presentation model contains a set of attributes and each attribute defines a value in the presentation model. Let’s have a look at the following example to describe how attributes can be defined:

In this example we have two different input fields and therefore we will define 2 different attributes:

  • An attributes that defines the name value
  • An attributes that defines the description value

To create Attributes the Dolphin interface contains some factory methods. The following code snippet shows how the Attributes can be created:

In the code a both attributes are created by defining the name of the attribute and an initial value. Once the attributes are created we can create a presentation model that will automatically synced between client and server:

Once this is done the presentation model is created an can will automatically be synced between client and server whenever anything in it will be changed. This will happen if the value of an attribute will be changed, for example:

Next to the name an Open Dolphin attribute is defined by a tag and a qualifier. As shown with the type of presentation models attributes can be found by using its tag, for example. Since these powerful features aren’t needed for a first simple application I will show them in a later post.

Server commands

Another important feature of Open Dolphin is the support of server commands. On server side command handlers can be registered for a specific command. Each command is defined by a unique name and can be called from client side.

By doing so you can trigger server commands from client side. In a server command the presentation models can be accessed and modified. By doing so you can define a save command for example. Once the command is triggered you can convert the current content of the presentation model into business entities and persist them in a database.

On server side the command handler can be registered by using a method of the ServerDolphin interface:

Once the command handler is registered it can be called from client side:

By doing so the command will be called on server side.

Basic interfaces

The 3 most important interfaces of Open Dolphin are Dolphin, PresentationModel and Attribute. All three interfaces are defined in the dolphin-core module. In addition to the core model Open Dolphin provides a module for the client and the server side. Each of this modules contains a specialization of the interfaces. The dolphin-client module contains the ClientDolphin, ClientPresentationModel and CLientAttribute interfaces that extend the base ones for example.

By doing so you need only one dependency for the client and one dependency for the server to use open dolphin:


This post shows some of the core concepts of Open Dolphin. For developers that used REST or EJB as the removing layer of applications this is a complete new approach. Therefore it’s important to understand how Open Dolphin works before creating a first simple application based on this concepts. In my next Open Dolphin post I will show how a first “Hello World” application can be created.

How to set up a DataFX application

A lot of people start using DataFX in small projects without a build file and by doing so they sometimes use old builds. Because of that I will give you some hints how to setup a project that is using DataFX.

DataFX builds

Every stable DataFX build can be found at Maven Central. If you are new to Maven or Maven Central just open this link. On the page you will find all artifacts of DataFX. If you for example want to use DataFX core you can download the jar, sources and javadoc here.

maven central

Each DataFX artifact is defined by the group-id, artifact-id and version. The group-id is always “io.datafx” and the artifact-id depends on the DataFX-Module. If you for example want to create an application that is suing the DataFX Flow you need the datafx-flow module and all it’s dependencies. At the moment the last stable version is 8.0.

If you want to download the DataFX jars by hand and add them to your application you need to download all dependencies of the module, too. Thankfully DataFX doesn’t have much dependencies. Here is an overview:

Once you have downloaded the last version of DataFX and added the jars to the class path of your application you can start coding.

Using builds tools

Normally you won’t download the dependencies of your application manually. Build tools like Maven or Gradle can do this job for you. By using one of the tools you only need to define the dependencies in your build file and the build tool will automatically download all needed jars. In addition the tools support transitive dependencies. This allows you to avoid needing to discover and specify the libraries that your own dependencies require, and including them automatically. If you Maven as build tool and you only want to add the DataFX Flow API to your application you only need to add one dependency:

Use DataFX in your application

Once you added DataFX as dependency to your application you can using it as described in the tutorials.

DataFX Tutorial 6

In this tutorial I want to show how dynamic actions can be handled in DataFX. In all the last tutorials the actions are defined in the flow configuration or by using annotations. By doing so you can’t dynamically choose which action should be called when clicking a button for example. To do so DataFX provides the FlowActionHandler class. This class provides methods to call DataFX actions directly in code. Here are some examples:

As you can see the FlowActionHandler class provides methods for all the action types that are supported in DataFX by using annotations or the flow configuration.
Normally you want to use the FlowActionHandler inside of a view to call dynamic actions based on a user interaction. To do so DataFX provides the @ActionHandler annotation that can be used to inject the FlowActionHandler in a view controller. Here is a small example how this will look:

As you can see it is really easy to call DataFX actions in code. As a next step we want to create a small application that uses this features.
Let’s say we have a main view and 3 sub views. In the main view you can choose by using radio buttons to which view you want to navigate.
To do so we create a controller with the “navigate” buttons and the radio buttons. As a next step we need to define a ToggleGroup for all the radio buttons. This group manages the RadioButton instances. By doing so you can only select one RadioButton. This is a JavaFX basic feature. If you want to now more about RadioButtons and ToggleGroups you should buy this book or visit this training. After this is done the controller should look like this:

As you can see in the code I don’t use the @FXML annotation. With DataFX 8 we introduced the @ViewNode annotation to inject components of the view in the controller. Basically this annotation can be used as the @FXML annotation but it provides more features. You can define the fx:id of the node as the value of the annotation, for example. By doing so your field must not have the same name as the node in the FXML file. Here is a short example how this can be used:

In addition the JSR-377 is currently planned and this will introduce a UI Toolkit independent annotation to inject view components. DataFX will implement the JSR once it is released and therefor we started to define our own basic annotations. SO maybe the name of the annotation will change once the JSR is released.
Once the controller is finished we need to add the action handler and navigate to the selected view. The RadioButtons instances in the controller define the controller classes for all the subviews as user data. By doing so we can simply navigate to the selected user data. Here is the final code for the controller:

Once this is done you can select the wanted view in the UI and by clicking the “navigate” button the view will change to the selected one.
All the view controllers for the subviews are defined as shown in earlier tutorials. You can find the complete code of the example here.

How to support Emojis (Part1)

Mostly all mobile application support emojis since some years. Later browsers and applications like twitter added global support for emojis. I think it’s time to have a deeper look at this funny icons and how a software can make use of them.


Emojis and unicode

Let’s start with a fact that is a big benefit when working with emojis: Since 2010 all the emoji icons that you know from your favorite chat application are standardized in the unicode standard. The unicode standard defines more than 700 emojis. This means that each emoji is defined as a unicode character and has its unique unicode code:
emoji def

In the picture above the icons that you might know from apple devices are used to visualize the emojis. But unicode doesn’t define the look of the icons. The unicode standard only defines the expression of the emoji as you can see in the official unicode documentation (example):

uni expression

Because the emojis are defined as unicode chars the can be part of any String or character array that supports unicode. For example in Java the String object supports unicode and therefore a String can contain emoji chars. Now the big question is: How can we add a emoji character to a String? On a normal desktop PC we don’t have emojis on the keyboard :(
There are different ways how you can type any unicode character with a keyboard (windows tutorial). If you are a mac user there is a very fast and easy way:
The “Messages” app supports emojis like you know it from an iPhone. Here you can simple add emojis and copy&paste them in any other application. Here is a short video that shows the handling:

Emojis in JavaFX

This successful test shows that the operation system supports emojis. Let’s try Java as a next step. To do so I created a small and easy JavaFX application that contains only a simple TextField:

Once the application is running we can do the same as before: Create a text with emoji chars, copy the text and past it into the JavaFX textfield:
jfx bad

As you can see in the image something went terrible wrong. We don’t see any smileys in the textfield. Instead of the emojis some strange characters appeared. Does this mean that JavaFX doesn’t support emojis?

Emojis and fonts

You shouldn’t be scared ;) JavaFX isn’t the problem. The strange issue is based on the font of the textfield. Let’s think about the functionality of a font: it interprets a character and draws a (vector based) icon for the char on the screen. In the example no specify font is defined for the textfield. Therefore the default font will be used that is “Lucida Grande” on a Mac (see this post for more details). Lucida Grande doesn’t contain a visual representation for the emoji unicode characters and therefore the strange icons will be shown. Th show emojis on the screen we need a font that supports them. One open source font that supports emojis is OpenSansEmoji. The font can be found at github. Once you downloaded the font you can define it for your textfield as described in an earlier post:

Once this is done we can use emojis in JavaFX applications – but only on windows without problems. On Mac OS there is a bug in the os depended clipboard code. Therefore you can’t paste any text with emojis in a JavaFX textfield. I will describe this problem in detail later. Let’s add a emoji character directly in code to the textfield. This will work on any OS.

Emojis and UTF-8

As you can see on this page a emoji is defined by 4 bytes in UTF-8. In Java all Strings are defined in UTF-8 by default and therefore we need to define a emoji this way:

This code will create a string that contains the grinning emoji as you can see in the overview:


Once this is done the emoji will be shown in the textfield and can simply be copied to any other application that supports emojis:


The last posts (like this one) I’m working on are very long and therefore I decided to split them in several smaller ones. In the next post I will discuss the problem on Mac. In addition I will show how emojis can be simply added to a text.

Concurrency in UI Toolkits (Part 1)

Today every UI toolkit that is not running in a browser needs an UI Thread the handle the repainting and the event handling of the UI. Examples for this kinds of UI Toolkits are iOS, Android, SWT, JavaFX or Swing. Each of this toolkits defines a thread that will handle all the ui specific calls. Let’s call this thread “UI Thread”.

By definition all calls that will affect the UI or get data of the UI must be called on this thread. Accessing the UI from another thread than the UI Thread will result in a lot of different problems.

Normally all user events that are handled by the toolkit will be called on the UI thread. Therefore an event handler will be called on the thread, too. If a developer wants to interact with UI components as a result of an user event he can do this directly in the handler. The following code shows some pseudo code how this might look. Normally each UI Toolkits provide it’s own mechanism for event handling.

If you want to interact with the UI from outside of an event you need to invoke your code on the “UI Thread”.

Each UI Toolkit provides a helper method to handle this invocation. In a UI Toolkit independent and unified way this method might look like this:

By doing so any runnable can be called on the UI Thread. This is ok for some general use cases but it’s definitely not enough to create an big application. One of the big problems is that you don’t know when the code will be called and when the call is finished. The definition of this method only says that the code will be called in some future on the UI Thread. Therefore we need a second method that blocks until the call is finished.

In most cases this method will have the same signature as the previous one. Let’s define the method in a unified way:

Thanks to Java 8 we can define this method as a default method based on the other one:

This looks good so far but there is still a problem. As said the UI must only be accessed by using the UI Thread. Let’s think about a background thread that want’s to call a web service based on some user input. To do so the thread needs to know the input of a textfield, for example. Because we can’t access the text from the background thread we need to invoke the call to the UI Thread:

The following code shows how such a call might look like:

To do so we need another helper method:

In addition we can provide a method that won’t block until the call is finished:

Now we have a set of methods that can be used to interact with the UI Thread:

Let’s have a deeper look how we can implement this methods by using default methods:

As you can see there are 2 differences to the basic interface definition. First we need to throw some exceptions because calling the get() method of a Future instance will throw exceptions. These exceptions are needed. Let’s think your runnable call that accesses the UI will contain an error and throws an exception. In this case you want to know about the error when checking the result of the call. As a next change the Provider result type of one method is changed to Future. Internally a Future is used that can’t be casted to the Provider interface. In addition a Provider won’t define the needed Exceptions as described earlier.


The defined interface contains only one method that needs to be implemented in a UI Toolkit specific way to create some helper methods. This is a good start but some of you might know, that there are still some problems in this methods. Maybe you call a *AndWait(..) method from the UI Thread. This will maybe end in a deadlock. In addition the Future interface defines the method “boolean cancel(boolean mayInterruptIfRunning)”. What happens if we call this on a task that is executed by the UI Thread? This issues will be discussed in the next post.

Desktop & Embedded Application JSR

Today the JSR for Desktop & Embedded Applications has been started and I’m proud to be part of it. The main goal of this JSR is to define a specification for common issues and behaviors that are shared between most desktop applications. This contains the following topics:

  • dependency injection via JSR330
  • common application structure
  • application life-cycle
  • localized resources
  • resource injection
  • localized configuration
  • decouple state from UI (binding)
  • persistence session state (preferences)
  • action management
  • component life-cycle
  • light-weight event bus
  • honor threading concerns (specific to UI toolkit)
  • application extensibility via plugins (implies modularity)

Until now there isn’t any line of code but I think that parts of the JSR will be influenced by some Application Frameworks like DataFX or Griffon. In addition Eclipse RCP and Netbeans have solved some of these problems and will be used as inspiration.
The website of the JSR can be found here. If you want to discuss about the JSR you should join the mailing list and star / watch the github repositories.

Oh, and because it’s a JSR it has an official number: JSR 377

JavaFX Talks JavaOne 2014

Some of the JavaOne 2014 talks were published at Parleys and I hope that a lot of other talks will follow. Thankfully some of the published talks are very good JavaFX related talks and I will post a list of all JavaFX talks. Once new talks will be posted at Parleys I will update the list.

Hand drawing effect with JavaFX

Some days ago Thierry Wasylczenko blogged about 12 of his favorite JS libs. On of the libs is js-sequence-diagrams that I did know. By using the library you can draw sequence diagrams in a browser. I really like the hand drawn theme of the tool that draw all the diagrams like they are sketched with a pen. Here is an example of the theme:
After having a look at the source code of js-sequence-diagrams I found the methods that render all the hand drawn lines. Cubic curves are used here and the control points of the curves are calculated by using random values. These two control points define the bend of the curve as you can see in the following picture:
cubic curve
Once I’ve seen this I wanted to try if I can do the same with JavaFX :)
Thankfully JavaFX contains support for cubic curves. The Path shape can contain curves that can be defined by the CubicCurveTo class. By using this class you can create lines and shapes that look like hand drawn onces by using the same algorithm as in js-sequence-diagrams. I created a simple test class that draws some arrows, lines and rectangles by using this algorithm. Here are some results:

As you can see in the picture the shapes look different in each of them. This is caused by the random values that are part of the algorithm. If you want to try this here is my one class gist that contains all the code:

First steps with WebComponents

I think one of the big new HTML features in the next years will be WebComponents. By using WebComponents developers can create fully-featured DOM elements as defined in the web component spec. In short this means that you can create your own HTML tags. If you want to add an avatar view to your web app you and use web components you can define a avatar component and then use the <avatar> tag in your HTML file. To use web components today you can use one of the following libraries:

I chose polymer to create my first web component and in this post I want to show you what I did to create a reusable custom HTML tag. Most likely this isn’t a best practice tutorial because I currently starting to learn about this topic :)

Project setup

As a first step I downloaded the polymer lib. To do so I used bower that is a package manager for web development. With bower you can define all the library dependencies of a web application like you can do with Maven for Java apps.
After you have installed bower on your system you need to execute the following commands in the folder of your web project:

This will create a bower.json file in your project and adds polymer as dependency. My file looks like this:

To download all dependencies you need to call

This command will download all defined dependencies and install the in the bower_components folder in your project. When committing your project to git you can simply ignore this folder.

If you don’t want to use bower you can download and integrate the polymer lib by hand.

As a next step you can create a index.html to test your custom components and a folder that will contain the components. Once this is done your application folder might look like this:

General structure of a WebComponent

As said a web component is a custom control for web pages. Top define a component we only need one HTML file. As in other languages or UT toolkits a web component is composed of a layout definition, a style and controller logic. In the web world this means HTML (layout), CSS (style) and JavaScript (controller). By using polymer all 3 parts can combined in one file. Here is a skeleton for the file:

As you can see the code starts with an import. Each custom component must import the polymer.html file. Thanks to bower this is already in the bower_components folder and can simply be imported. The polymer-element tag describes the web component. In the tag there are 3 more tags that describes the layout (template), the style (style) and the controller of the component (script). The polymer-element tag has some attributes that describes the name of our component and its attributes.
To create a small web component you don’t need to define all 3 inner tags but some basics are needed to display the component in a browser.

Defining the first component

As a start we want to create a minimal web component that will only print an “A” on screen. To do so we create the “Simple-A.html” file in the components folder and add the following content:

As far as I know is this the minimum definition that you need to define a component. In the template a paragraph that contains an “A” is defined. This is default HTML and if we don’t want to create a reusable component we could write this directly in an HTML file. In the script section the Polymer({}); call registers the component so it’s recognized by the browser. Once this is done the component can be used in any HTML file to render the “A” paragraph on screen:

Use the component

To include the custom web component in a HTML page you need to import it. In addition the polymer platform lib must included to the page. Here is the code of a HTML page that includes everything and adds the “A” paragraph component several times to the body of the page:

As you can see in the code the html files that defines the custom component is imported in the web page. Once this is done the custom tag can be used in the web page. When having a look at the web developer tools of safari you can see that the


tags are now part of the page:
view in console

Browser support

I tested my HTML file on Safari, Chrome and Firefox. Safari and Firefox work fine but on Chrome I don’t see anything. The web console shows a “Cross-Origin Resource Sharing” so maybe it will work when running the page on a web server instead of just opening the file from the filesystem. I’m not a web expert so maybe Chrome has the correct behavior here. I will check this later and blog about it in my next web component post. After all by doing the most simply try and opening the HTML file with the browsers that re installed on my system this is the result of the browser check:


It was very easy to create the first web component. As a next step I will try attributes for the components and some JavaScript logic. I will block about it as fast as possible.

Responsive Design for JavaFX

Once of the new APIs that I have shown at JavaOne was ResponsiveFX that can be used to add responsive design to your JavaFX application. ResponsiveFX is an open source project maintained by Canoo and will be published to Maven Central the next days.

Responsive Design

Today software must fit a wide range of devices. When developing an application customers often want to use it on a desktop pc and on a tablet. In addition a subset of the features should be useable with a mobile phone. Oh, and maybe next year the first customers want to check information on a smart watch. Even if web apps and JavaFX applications can be distributed and used on most of this devices you can’t simply use the same UI on them.

All these devices provide different screen sizes and resolutions. In addition the user interaction is in some parts completely different. While using a mouse and keyboard on a desktop pc you want to use touch and gestures on your mobile to navigate through the app.
One approach to handle these issues is responsive design that can be used to provide an optimal viewing experience—easy reading and navigation with a minimum of resizing, panning, and scrolling—across a wide range of devices. Responsive design was first introduced by web applications and influenced the development trends in this area. By defining different layout for specific screen sizes the fronted of a web application will look good on mostly all devices.



The core concept of ReponsiveFX is copied from Twitter Boostrap that provides responsive design for HTML. Boostrap provides several CSS style classes that can be used to hide or show components on different screen sizes. Here is a short overview of all the style classes:
By adding one of these style classes to a component the visibility of the component depends on the current frame size. Here is a small example how this can be used in HTML:

Responsive Design & JavaFX

By default JavaFX doesn’t provide an API for responsive design. Thankfully JavaFX supports CSS and therefore we can add this feature. This is exactly what ReponsiveFX does. By using the API you can simply use the same style classes as in HTML in your JavaFX application. To add the responsive support to an application you only need one line of Java code:

This adds the support for responsive design to the given stage. All nodes that are in this stage can now use the described style classes. Therefore you can simply do the following in Java code:

In the example a table and a list are defined that will visualize the same set of data (items). Depending on the size of the application the list or the table will be shown on screen. Here is a short video that shows the behavior:

By adding this API to your JavaFX application you will have the same possibilities as in HTML to provide responsive design.

Responsive Design & pseudo classes

By using the given classes you can hide and show components depending to the frame size in your application but often you want to show different sizes of controls depending on the screen size. Let’s think about a toolbar that should have a different size in all supported screen sizes. In HTML you would do the following:

In JavaFX this would correspond the following code snippet:

This is very bad practive because Java must handle all 4 instances in this case. Even if only one toolbar will be displayed on screen all are part of the scene graph. If you will do this with controls that contains images you will blow up your memory for example. Therefore you shouldn’t do this. I thinks it’s clear that we need a better solution and ResponsiveFX contains one :)
Next to the style classes ReponsiveFX provides pseudo classes for all supported screen sizes. Here is a list of the supported pseudo classes:

  • extreme-small-device
  • small-device
  • medium-device
  • large-device

By using this pseudo classes you can define the visualization of a node depending on the current application size. The pseudo classes will automatically be added and removed for each node inside the scene graph of a windows that is handled by the ResponsiveHandler. Thanks to this you can define the following CSS rules for a control:

In your Java code you can now define one control and set its ID to match the CSS rules:

Whenever the size of the application will change the matching pseudo class will be set to the control and the visualization of the control will change depending on the CSS attributes. By doing so you can create applications that will look different on the specified frame sizes. This will be helpful when developing applications that should work for desktop and mobile or on embedded devices. Here is a short video that shows how a responsive application might look:

Responsive Design in Java code

In addition to the shown features ReponsiveFX supports a Java API to react on responsive changes. A listener can be registered to the ResponsiveHandler and will be fired whenever the responsive types changes. By doing so you can react on changes direct in Java code. This will be helpful if you need to change anything that can’t be done by CSS. AT the moment this feature is a fast hack for JavaOne but I plan to refactor this in near future.

Where can I get it?

As said ResponsiveFX will be released in near future. I’m currently create clean modules / libraries of all the demos and examples that I showed at JavaOne. ResponsiveFX is already extracted as a stand alone library. The next days I will set up the GitHub repo and add some documentation. Once this is done I will upload the first version to Maven Central.

Additional Information

Because of a missing feature in JavaFX ReponsiveFX contains some hacks that can result in unwanted behavior. If you like the API and need responsive design in JavaFX you should vote for this issue at the JavaFX bug database.