And please note: the CanooNet app is available for 5.99 € until June 30, 2013. You save 60%!

During the last JavaOne, Canoo announced the open sourcing of Dolphin.
OpenDolphin is a library that provides a remoting solution to bridge the world of Enterprise Java and Desktop Java or other client technologies (mobile, web).

Since then, a lot has happened around OpenDolphin and it keeps gaining more and more attention.
For me personally, it was from the first time I heard of it a very interesting project, but due to daily business and other projects I didn’t have the time to get into it.
Using JavaFx as the first client technology to be implemented was also a little hurdle as I haven’t done any serious work with JavaFX, yet. But now, I’ve finally found some time to play with JavaFx and OpenDolphin .
(Besides, there is an JS implementation of OpenDolphin – it proves that OpenDolphin doesn’t tie you to a client UI technology.)

Afterburner.fx

As I attended to Adam Bien’s Airhacks Workshops in March, he introduced the Afterburner.fx mini-framework to the audience and released it a few days later.

Afterburner.fx is a minimalistic MVP framework for JavaFX that provides
“Zero-Configuration” dependency injection (DI) of models and services
and
Convention-based unification of presenter, view, FXML and css.

Thus it enables the usage of the JavaFX scene builder (a UI design tool) to implement a clear seperation of layout and logic (as the layout is encapsulted in the xml). In his talk “Enterprise JavaFX 8″ Adam describes it as an implementation of “inversion of control”.
The outcome is a very powerful set of lightweight technologies to build JavaFx applications.

The wiring between the UI XML and the code a pretty minimal. On the one hand, in XML, you just need to define the controller class:

<AnchorPane id="AnchorPane" ... fx:controller="de.mynethome.presentation.DemoPresenter">

And optionally, event handler methods can also be set via XML with

<Button ... fx:id="button" onAction="#buttonClicked"  />

In the code, the UI components get injected by the @FXML annotation and the name used as fx:id :

@FXML
  Button button;

Combine the power

My idea on the moment I saw it was to bring those two projects together to benefit from the features of both projects:

• A clean and easy way to create the UI and build up the client
• a powerful and non the less easy to use library for client-server communication and clear speration between logic on the server-side and UI-related code on the client with open-dolphin.

AfterburnerDolphin

You can find the outcome of this idea at my AfterburnerDolphin project at github.

It demonstrates the things mentioned above:

In the client module, you can find a clearly structured app, the design and layout clearly seperated (as extracted to xml and css files) from the logic (look at the App class and the DemoPresenter).

It’s all tied together via DI and convention-based confguration of afterburner.fx .

The client creates a PresentationModel and binds the button text value to the value of that model.
(DemoPresenter, Line 43)

public void initialize(URL location, ResourceBundle res){
    JFXBinder.bind(ATT_ATTR_ID).of(textAttributeModel).to("text").of(button);
}

On a button click, the client communicates via OpenDolphin with the server (server module, ApplicationAction) where the command for a new value (current date) of the presentation model’s attribute is created and send as a response.

(ApplicationAction, Line 17)

actionRegistry.register(ApplicationConstants.COMMAND_ID, new CommandHandler<Command>() {
      public void handleCommand(Command command, List<Command> response) {
        ServerAttribute date = getServerDolphin().getAt(PM_APP).getAt(ATT_ATTR_ID);
        ServerDolphin.changeValue(response, date, new Date());
      }
    });

That demonstrates how easy this set of technologies lets you set up a well structured multi-tier application and implement a roundtrip between client and server.

Any business logic can be handled on the server, the client only need to implement the presentation. And the implementation and maintenance of the client UI is eased up by the clear structure implemented with the help of afterburner.fx .

The UI of this sample application is very simple, as you can see from the screen shot – before and after click on the button. The date used as die new button text is set on server side.

Conclusion

I think, the combination of AfterBurner.fx and OpenDolphin provides a very powerful featureset.
At first, it’s easy and quick to setup and design UI Layout with Scence Builder.
After that, AfterBurner.fx and OpenDolphin allow you to build an application with clear, distinct seperation between layers:

• UI layout (in XML)
• UI logic (in client code)
• Business Logic (and more) (in server code)

You can be up and running very quickly with a short time to initiate application development. With the clear seperation, I would expected the setup to provide the foundation for a very maintainable project.
And with OpenDolphin you protect your investment as you can very quickly provide an multi-channel application (providing an mobile app UI based on the already developed server code) or switch to another UI technology and reuse the business logic implemented on server side.

Further steps

Fork AfterburnerDolphin on github.

Find out more about Afterburner.fx, visit the Afterburner.fx Homepage.

Get more information on OpenDolphin with the OpenDolphin documentation.
Or look at the OpenDolphin videos on youtube.

• clear separation of what to display (server) and how to display (client)
• application logic on the server (efficiency and protection of investment)
• full exploitation of the native clients capabilities (fidelity)
• generic presentation models (independence of client and server)

These benefits derive mainly from a client-server split at the presentation model layer.

Read more about the architecture and concepts in the online documentation or have a look at the extensive set of sample applications:

• OpenDolphin library (multiple demos)
• Dolphin jump start project (step-by-step introduction)
• train station demo project (complex showcase app)

JavaFX as a modern Java UI toolkit is certainly a natural choice to go along with OpenDolphin on the Java client. But the clear separation of concerns (what and how to display) makes it easy to deploy any UI framework on the client. In the demos you’ll find examples of JavaFX and Swing clients that happily coexist with exactly the same server code.

Since the costs to switch the client technology are fairly low with OpenDolphin, going web and mobile is the next logic step. Dolphin.js leverages exactly that potential.

Dolphin.js is an OpenDolphin client implementation in JavaScript allowing you to connect your web application to an OpenDolphin server. It follows the same concept as the Java implementation, therefor most of your OpenDolphin knowledge is applicable to it.

The usage of Dolphin.js is best introduced with an example. You’ll find the Dolphin.js jump start project in Canoo’s github account. A video of the jump start application can be found here.

Dolphin.js uses require.js for modularization which is an AMD implementation. Dolphin.js integrates into your JavaScript project as follows (head section):

<script type=”text/javascript” src=”../scripts/require.js”></script>
<script type=”text/javascript” src=”../scripts/dolphin.min.js”></script>
<script type=”text/javascript” src=”config.js”></script>

It is important to list the require.js dependency first. In config.js you can define external dependencies to third party libraries. Your application runs as an AMD module (body section).

Any dolphin.js app is structured as follows:

‘Dolphin’ is the core module and required for any app. Typically you want to create a presentation model with client attributes, therefor you need ‘comm/ClientAttribute’ as well. The Dolphin constructor takes the (Dolphin) server URL and optionally a flag if the browser session should be cleared upon reload. Once you have a Dolphin instance you are ready to create and bind your UI to the presentation model.

The following snippet creates a presentation model with a ‘temperature’ client attribute and binds it to an HTML input field:

        var tempAttr = new ClientAttribute(“temperature”);

        var weatherMold = dolphin.getClientDolphin().presentationModel(

            ”weatherMold”,

            ”weather”,

            tempAttr

        );

        var tempInput = document.getElementById(“tempInput”);

        tempInput.addEventListener(“input”, function () {

            var value = tempInput.value;

            tempAttr.setValue(value);

        });

        tempAttr.on(“valueChange”, function(data) {

            tempInput.value = data.newValue;

        });

The binding to the temperature attribute is stable and reflects any changes in the input field or model vice verse.
Binding to individual HTML elements is the most basic integration which works with any JavaScript framework.

Future version of dolphin.js will support direct integration in JS frameworks such as backbone.js and angular.js which provide model-view bindings out of the box.

The code example shown is only the most basic usage of Dolphin.js. For a master-detail and a server push implementation have a look at the jump start project code. Dolphin.js is very lean (currently around 700 lines of code) so it’s straightforward to read through the source code. The jump start project also features a mobile (JavaScript) client.

Our experience in porting the Dolphin from Java to JavaScript shows that specific ports to native mobile plattforms as iOS and Android are feasible and the next step.

Dolphin.js demonstrates the inherent multi-channel capabilities of OpenDolphin. With such an approach you no longer have to bet on the next UI client technology, but rather are able to react quickly to changing UI demands at the least possible costs.

Get in touch with us for more information on OpenDolphin and it’s multi-channel capabilities.

At Canoo, we have a lot of meeting rooms. They can be booked using our corporate calendar (Zimbra).

In your organization it may be the case that all meetings always have a proper room reservation, every participant is fully aware where his next meeting will take place, and no spontaneous meetings ever occur.

Well, it is different at Canoo. We may stand in front of the meeting rooms asking ourselves:

• Where will my meeting be?
• Who is currently in which meeting?
• Where can I go without a reservation?

We could go back to the workplace, fire up the corporate calendar and find that information but we had the idea that it would be much nicer to have the information readily available right where we need it: on a screen in front of the meeting rooms.

In the future, we may want to extend the information to corporate news, pictures, blog posts, build status, welcoming visitors, and so on. We were bold enough to call that project CanooNow and implemented it as part of the infamous Canoo code camp.

Technologies and Hardware

We wanted to experience how such an application could be implemented on a Raspberry Pi. The Pi is an inexpensive mini computer with limited resources, but still is capable to run Java – a special JDK provided by Oracle for Raspberry Pi. Additionally, the plan was to put the application logic on a server and let the embedded device be the display. We decided to use open-dolphin to this end.

We were also eager to make use of the attractive view controls of the jfxtras.com project for JavaFx application. The Agenda control seemed to be a perfect match to our application.

Experiences with JavaFx and open-dolphin

Our first goal was to adjust the Agenda control so that it does not show days per column, but shows a room within each column. The Agenda control is made from the Agenda model class and the AgendaWeekSkin, that handles the visualization of the control. For that we built a new Skin class that is capable in achieving the desired effect.

We had reached this intermediate step with almost full functionality after an intense coding session with the result below:

This application shows our meeting rooms (which have got country names) and our breakroom.

After this milestone, we targeted to integrate open-dolphin into the application. If you would like to know more about open-dolphin, please check out the official website www.open-dolphin.org.

It didn’t take long to ‘dolphinize‘ our app. We needed a reference to the client dolphin:

class MainView extends javafx.Application {
   static ClientDolphin clientDolphin
   ...
}

The clientDolphin property will be set in the Application starter classes. We have it in two flavors: one for a development scenario where the dolphin server runs in the same VM as the client, and one for a real client server separation scenario. In case of development the starter looks like:

public class ApplicationInMemoryStarter {
	public static void main(String[] args) throws Exception {
		DefaultInMemoryConfig config = new DefaultInMemoryConfig();
		config.getServerDolphin().registerDefaultActions();
		config.getClientDolphin().getClientConnector().setUiThreadHandler(new JavaFXUiThreadHandler());
		registerApplicationActions(config);
		MainView.clientDolphin = config.getClientDolphin();
		Application.launch(MainView.class);
	}
}

When the main view is initialized, a command for data retrieving must be sent by the clientDolphin:

clientDolphin.send(Commands.CMD_PULL, new OnFinishedHandlerAdapter() {…}

This will be mapped to a server side action where the data access to our room reservation system takes place. It loads the appointments and returns the required data to the client.

Get our heads around the model

In order to get the Agenda control do the things that we want it to do, we had to design the presentation models properly. We came up with three types of presentation models:

• Appointment: This type holds the neccessary data for a single appointment such as startDate, endDate, title, organizer, attendee
• Room: Type for the columns of the Agenda control.
• Person: Type for the organizer and the attendees  of an appointment.

The Main View registers as a ModelStoreListener on presentation models of type Appointment and finally adds/remove an appointment instance to the Agenda.

clientDolphin.getModelStore().addModelStoreListener(Appointment.TYPE, new ModelStoreListener() {
	@Override
	public void modelStoreChanged(ModelStoreEvent event) {
		PresentationModel presentationModel = event.getPresentationModel();
		switch (event.getType()) {
		case ADDED: // map presentation model to appointment and add it to the agenda control.
			mapAppointment(presentationModel);
			break;
		case REMOVED: // remove appointment from agenda control
			removeAppointment(presentationModel);
			break;
		}
	}
});

Also the skin class of the agenda control must react on Room model changes. It must add or remove columns accordingly.

Here it is

Finally – after two days of work (including the nights) CanooNow stands in front of the meeting rooms, displaying live data, and giving directions to employees and guests:

The screen shows all appointments that take place in the various meeting rooms. On the left hand side, a time scale of 6 hours is shown. It moves up every full hour automatically. The red line visualizes the current time and moves along. Completed appointments are greyed out.

At Canoo we deployed the application to a Raspberry Pi that is connected to a flat screen. This flat screen is positioned at the entrance allowing everybody to check  whats going on in our meeting rooms.

Lessons Learned

JavaFx

With JavaFx it is very easy to develop complex UIs. Binding properties is a slick way of having one property that controls all bound objects. There is no repaint() required like in Swing. Another neat thing about JavaFx is the CSS style definitions. Most of the CSS style definitions worked, a very few we had to set through the component API.

Open-dolphin

Open-dolphin is a tiny piece of software that can be easily integrated into any application. For us, the time spent for getting dolphin working as we wanted was less than a third of the whole project development time.

Raspberry Pi

The Raspberry Pi mini computer has got everything that is required for running JavaFx applications. With raspbian linux and a specially baked Java version from Oracle, the application runs perfect – even the performance is acceptable. The performance was our biggest initial concern, but it turned out not to be an issue. Of course we did not use complex UI transitions that would certainly bring the Raspberry Pi to its boundaries.

The CanooNow Team,

Fabian Dreier, Franz-Josef Wiszniewsky, Johannes Porzelt, Martin Huber, Detlef Brendle

Use-Case

Here is the situation: on the platforms of a train station, say Olten in Switzerland there are many departure boards informing people about trains starting from this station in the near future.

GUI Overview

The application implements such a departure board in form of a window with a table showing the next 5 trains. One goal was that the departure boards are displayed on a Raspberry Pi. In addition the application contains a so called admin GUI to maintain information about trains and simulate arrivals and departures of trains. The Admin GUI uses the master-detail paradigm.

The following screenshots of the Admin GUI and the Departure Board should give you an impression on how the two GUIs look like.

To make this post not too boring I will just describe the important things from a concept point of view.

Project Setup

We started with an empty directory and created the initial open dolphin project structure with the open dolphin gdt template which meant our project was up and running within minutes. As GUI technology we decided to use JavaFX and also GroovyFX to make working with JavaFX even easier.

Admin GUI

When the Admin GUI shows up a so called named command (COMMAND_GET_ALL_DEPARTURES) is sent to the server asking for all train departure data. The server creates presentation models (PMs) which are sent to the client by dolphin automatically.  When the PMs arrive on the client a callback is invoked so that it can bind the PMs to the table on the GUI.

After having put the details view (which we also called editor) next to the table the goal was that it shows the data of the currently selected row in the table. Here the PMs start to shine. We simply created a separate PM which we called selectedDeparturePM.
Note that this selectedDeparturePM is nothing visible by itself. It is simply a placeholder for the concept of the currently selected PM. Whenever the selection in the table changes the newly selected PM of the table got applied to the selectedDeparturePM.

Then we bound the editor’s widgets to selectedDeparturePM. This means the table and the editor are completely decoupled. And if you start typing changes in the editor fields you immediately see the changes in the table while typing (that’s done by open-dolphin in the background). You could easily think of putting a second version or instance of the editor on the GUI (also bound to selectedDeparturePM) and the three views would all be in sync.

When we noticed that the table as a widget was still too much in control we created another “invisible” PM: selectedDepartureIdPM which we bound to the table. This means whenever the selected row in the table changes selectedDepartureIdPM is adapted and vice versa. Now you will ask why is it necessary that the table listens to changes of selectedDepartureIdPM The use case for this was the undo/redo support. We wanted that a change of the selected row in the table is also undoable. Changing the selected row in the table say from row 5 to row 6 now causes a normal value change of selectedDepartureIdPM from 5 to 6. When the user presses undo selectedDepartureIdPM changes back from 6 to 5 and since the table is bound to selectedDepartureIdPM the selection of the table also changes back to row 5. Nice, isn’t it?

And then of course we had to bind selectedDepartureIdPM to selectedDeparturePM and vice versa. This appeared like a best practice to us: views like the editor which are interested in all details of the selected PM bind to the selectedDeparturePM, those (like the master/table view) which are only interested in the id bind to the selectedDepartureIdPM. That’s all.

Departure Board

Now to the Departure Board. This is basically a second client to the same application. You have to know that the server side PMs of the AdminGUI and those of the Departure Board live in their own separate worlds (sessions). Also note that there is no concept of a shared PM. So if we want to show data visible on the Admin GUI on the Departure GUI you have to send the data to it. This is issued by pressing the button ‘erster Eintrag auf Abfahrtstafel’ which sends the PM’s data to the other client(s) by making use of Open Dolphin’s event bus.

The Departure Board clients use a long polling approach to be able to display changes immedately. This means whenever the AdminGUI presses the button they new 5 records appear immediately on the Departure board. And what’s more if you change data in the editor the changes appear on the Departures board which typing. We found that quite impressing.

During the code camp we wanted to use @hansolo_’s very nice departure board custom control on the Raspberry PI. It turned out that some adaptions have to be made first in order to make it PI ready. This is currently on the way. So for the PI we used a normal table for the time being. On the desktop we created a second version of the Departure Board using Swing as GUI technology. See for yourself how nice the result looks like:

It was really easy to add input validation to the Editor using tags of the PM’s attributes. We also made use of tags for the labels of intput fields so that validation and labels (think of internationalization) are defined by the server.

Altogether we were positively surprised how far we got in just a couple of days. It was a real joy to develop this application. If you’re interested you can find it on https://github.com/canoo/dolphin_train_station . The readme file appearing on the github page explains how to build and run the application.

My personal conclusions are:

• Using the presentation model approach with Open Dolphin is the way I want to build GUIs from now on.
• It will be hard if I have to go back and use other paradigms now that I know how to do it right.

These are the ground rules:

• you have to be there all three days
• we work in small groups
• you have to present your achievements Saturday afternoon

What happens in code camp doesn’t stay in code camp!

This spring, we decided to work on OpenDolphin in connection with JavaFX, Raspberry Pi, and HTML5 with 10 developers in three projects.

Detailed blog posts about all three projects will follow and I wouldn’t want to reveal too much in advance beside that we have all been thrilled by the achievements.

We were not surprised to see JavaFX living up to its promise of allowing great user interface development from desktop down to small embedded devices. It worked like a charm.
The cool thing was to hook these user interfaces up with OpenDolphin presentation models and to control the application from a remote server – even synchronizing the views.

We were able to extend OpenDolphin’s reach to multi-client / multi-channel HTML5 applications working in perfect harmony with JavaFX views, which triggered a bit of discussion on Google+.

Most of all, the OpenDolphin approach passed a most scrutinizing test: being used in anger by a Canoo team. We identified a few possibilities for improvement along the way but the general assessment concluded that OpenDolphin was

- “quick to get into” in a day or so
- “made from a few simple, reliable concepts”
- “versatile and powerful”
- “the best way to structure UIs”.

Even advanced tasks like supporting reliable undo/redo (even rollback of selections) and scaffolding complex forms with three lines of code suddenly became possible in this very short time frame.

You bet that beside the exciting work – which sometimes almost led us to being late for the delicious catering – we had a tremendous amount of fun.
Late in the night, we even defined a new software development methodology:
beer programming.

Stay tuned!
There is more to come soon.