Writing games is a good way of learning a new programming language or framework. I've done this several times in the past: JavaScript/Snake , C++/Space-Shooter, Java2D/ColorGame.

This time I was interested in JavaFX 2 and again I was developing a little game as an example. Again I tried a "snake" like game as you probably know from old mobile phones. As the player you are controling a Snake that eats food that is laying around. Everytime you eat something to gather points and grow a little bit. The goal is to gather as many food as you can without byting yourself in the tail. In my version of the game there are no walls: When you move outside of the field on the left side you are immediatelly returning on the right side.

The development started in october 2012 with some experiments with JavaFX, FXML and dependency injection. The first version of the game was based on maven and javaFX version 2. In november 2012 the first version of the game was ready. It was based on maven and JavaFX in version 2. The dependency injection was implemented by hand without a DI framework.

After a long pause with no coding in may 2013 I returned to the project and started with a big refactoring. The code wasn't realy nice and the coupling between the components of the game was relatively tight. The idea of the refactoring was to encapsulate the state of the UI in a ViewModel. Another change was the usage of JSON for persisting highscores instead of CSV. This way I was able to remove a lot of code for CSV parsing.

In november 2013 again I made some changes to the game after another pause. The biggest change is the use of Gradle as build system instead of maven. I also done a big refactoring of the dependency injection system and simplified the code of the program. Another big simplification was the usage of Java 8 instead of Java 7.

The code of the game can be found on github: https://github.com/manuel_mauky/snakefx

For the lecture "IT security management" at the university my fellow students and me have developed a programm called "Datenpannen-Kalkulator". "Datenpanne" is the german word for "data loss" and means that you have lost some of your or your companies data.

The programm calculates the costs of losing data or virus infections in your company based on some parameters like the number of affected clients or your industrial sector. The calculation is based on existing statistics in which companies were asked about the costs that were caused by security incidents.

While it's obvious that the frontend of the application was developed with JavaFX (and the help of Afterburner.fx) the calculation logic is done with JavaFX too. All calculations were implemented with JavaFX's properties and databinding capabilities. At first this programming style is a little bit unusual because typically as a java delevoper you are used to implement calculations in an imperative style.

But this style of programming has lots of advantages: It's relativelly easy to implement a "reactive" user interface. The calculation logic is based on properties that are bound to the values of the input fields and the charts that are visualizing the result are bound to the result properties. This means that a change in the input fields immediately leads to a change of the calculated result values and this leads to an update of the displayed chart data. There is no need for a "calculate" or "update" button. It's all done automatically.

The code of this project can be found on github: https://github.com/manuel_mauky/datenpannen-calculator

For the JavaMagazin 11/2013 Alex has written an article that describes some of the thoughts he had when he initiated the mvvm-fx library that I'm working on too. He shows how you can implement the MVVM design pattern with JavaFX in a test-driven way. The code isn't specific to the mvvmfx library but shows the basic ideas of the pattern.

Today I like to introduce another open source library that my workmate Alexander Casall an me are creating at Saxonia Systems. Alex had the idea to try out the design pattern "Model-View-ViewModel" that was created by Microsoft engineers for Windows Presentation Foundation (WPF) and XAML and that is also used by some JavaScript frameworks like KnockoutJS.

The design pattern uses some technical capabilities of a modern UI technolgy like (bi-directional) data-binding and descriptive UI declaration to simplify the development of the UI and to make testing UI code easier.

JavaFX in version 2 supports both of these capabilities: It includes Properties and Data-Bindings and FXML, a xml dialect to create the UI for JavaFX.

At the moment our MvvmFX-library is at the very beginnning. We are trying out what is possible and what is not. We would be very pleased if you like to give it a try. You can find it on github: https://github.com/sialcasa/mvvmFX

The MVVM Design Pattern

Let's start with the View. With MVVM the view has to be silly. It may not contain any logic but only describe what is visible in the UI.

The UI specific logic is developed only in the ViewModel. The viewmodel contains the whole state of the UI and the logic that updates and changes this state. It provides the state to the outside in the form of Properties.

The view can now bind itself to the properties of the ViewModel. When the state of the viewmodel changes the view is automatically updated because of the binding.

The viewmodel knows the model. How exactly the model is created isn't part of the MVVM pattern. It is the interface to the business logic and the rest of the application. The viewmodel takes the informations that are needed to be presented in the view from the model and brings that informations in the right form in which the view needs them.

A common example is a UI that should show the name of a person. The model has Person instances that are containing string variables for "forname" and "surname". In the UI you are expecting this informations to be presented in a nice way. The viewmodel would take the person instance and concatenate the for- and surname to one single string that is provided as a property "name". The view has a label that's textProperty is bound to the name property of the viewModel.

The design pattern defines a strict top-down visibility for the components. The View knows the ViewModel. The ViewModel knows the Model but not the View. And the Model knows neither the View nor the ViewModel.

Testing

What is really cool about this design pattern is that the whole UI specific logic is only located in the viewmodel. Conditions like "Is the button x disabled or enabled?" are developed in the viewmodel. The view doesn't know about this conditions. It only knows that there is a button and that it's visibility property is bound to a boolean property in the viewmodel. The view doesn't care about under which conditions this boolean property is true or false.

This enables you to unit-test your UI logic. The viewmodel is only a simple Java class. You don't need to boot-up the whole application to perform difficult UI integration tests. JUnit is all you need.

I'm very pleased that an article of my colleagues and me with the title "SynchronizeFX: Remote JavaFX Property Binding" is released in the JavaMagazin 08/2013.

In this article we describe the use cases that induced us to create the SynchonizeFX library and how we are using it in our own product eteoBoard. Additionally some of the implementation details are described and of cause a little how-to is part of the article too.

This blog post is about my visit at the JAX 2013 in Mainz, one of the biggest Java conferences of europe. As an exception this time the post is written in german and not english.

In der letzten Woche hatte ich durch meinen Arbeitgeber die Möglichkeit, die JAX 2013, eine der größten Java-Konverenzen Europas in Mainz zu besuchen. In diesem Blogpost möchte ich über Vorträge berichten, die ich besucht habe.

JavaFX

Enterprice Anwendungen mit JavaFX (8)

Adam Bien berichtete in seinem Vortrag "Enterprice Anwendungen mit JavaFX (8)" recht unterhaltsam von seinen Erfahrungen mit Enterprice Anwendungen und den Dingen, die bei dieser Klasse von Anwendungen seiner Ansicht nach relevant sind. Er kam zu dem Schluss, dass hier JavaFX in vielen Fällen eine lohnenswerte Alternative zu den klassischen Webtechnologien sein kann.

Im Verlauf des Vortrags stellte er anschließend seine Vorstellung davon vor, wie Entwickler Oberflächen mit JavaFX entwickeln sollten. Trotz anfänglicher Skepsis sieht er vor allem FXML, die XML-Basierte Beschreibungssprache für JavaFX ab Version 2, als ein sehr gutes Werkzeug an. Mit FXML lässt sich eine Oberfläche deklarativ beschreiben und dynamisch von JavaFX aus laden. In der FXML-Datei kann der Name einer Controller-Klasse angegeben werden, der dann von JavaFX automatisch instanziiert wird und der per Dependency Injection die benötigten Referenzen auf UI-Elemente erhält. Adam Bien sieht hier das Prinzip der Inversion of Control sehr gut umgesetzt.

Da für FXML-Dateien auch ein sehr reichhaltiger und ausgereifter WYSIWYG-Editor namens SceneBuilder existiert, sieht er diese Vorgehensweise bei der Entwicklung von Desktop-Oberflächen als vorteilhaft an.

Die einzige Lücke, die in diesem Mechanismus noch besteht, ist die Verwendung von echter Dependency Injection für die Anbindung der Backend-Logik. Der DI-Mechanismus von JavaFX injected nämlich nur UI-Elemente aus der FXML-Datei in den Controller, andere Abhängigkeiten wie Services werden nicht automatisch eingefügt. Da die Instanziierung des Controllers ebenfalls von JavaFX übernommen wird, kann der Entwickler auch nicht einfach per händischer Dependency-Injection per Konstruktor die Abhängigkeiten hineinreichen.

Glücklicherweise ist der DI-Mechanismus von JavaFX relativ leicht erweiterbar und so stellte Adam in seinem Vortrag auch das von ihm entwickelte Mini-Framework Afterburner.fx vor, welches einfache DI auf simple Art und Weise umsetzt und dabei, wie andere DI-Frameworks auch, die 'javax.inject'-Annotationen verwendet.

Wer schon immer mal sehen wollte, wie einfach ein DI-Framework sein kann, der sollte sich unbedingt den Quellcode von Afterburner.fx auf Github anschauen. Das ganze Framework besteht nämlich nur aus 2 relativ kleinen Klassen.

JavaFX vs. Html5

Im Vortrag "JavaFX vs. Html5" zeigt Björn Müller einige Anwendungsfälle auf, bei denen HTML5 (in Kombination mit JavaScript) seiner Ansicht nach nicht die passende UI-Technologie ist, sondern klassische Desktop-Oberflächen besser geeignet sind. Er bezieht sich vor allem auf große, umfangreiche Business-Applikationen mit umfangreichen Eingabemasken und mehreren Hundert Screens. Als Beispiele nennt er Anwendungen aus dem Bereich der Logistik und Lagerverwaltung.

Als Gründe nennt er nicht nur die nach wie vor bessere Performance von Desktop-UI's, sondern vor allem die Entwicklungseffizienz, d.h. wie schnell die Entwickler die entsprechende Funktionalität liefern können.

Als eine mögliche Lösung für die Entwicklung großer Business-Applikationen stellte Björn anschließend das von ihm entwickelte Framework CaptainCasa vor.

CaptainCasa stellt eine Verbindung des UI-Frameworks JavaFX mit dem Serverseitigen Komponenten-Modell von JavaServer Faces her. Denn obwohl JSF in den meisten Fällen zur Entwicklung von HTML-Oberflächen genutzt wird, ist es prinzipiell unabhängig von der tatsächlichen benutzten View-Technologie.

Die Serverseite kann damit klassisch mit JavaEE entwickelt werden, die UI wird mittels JSF und einer speziellen Tag-Library umgesetzt. Auf Client-Seite kommt statt dem Webbrowser jedoch ein JavaFX-Renderer zum Einsatz. Die UI ist damit nicht fest im Client implementiert sondern wird dynamisch auf Serverseite generiert und mittels eines XML-Datenaustauschformats zum Client gesendet, welcher aus diesen Informationen die Oberfläche aufbaut. Eingaben des Nutzers werden auf ähnliche Weise wieder zum Server gesendet und durchlaufen dort den bekannten JSF-Livecycle.

Für Entwickler, die bereits mit JSF zu tun hatten, ist der Lernaufwand deshalb relativ gering. Sie müssen sich nicht mit den Details von JavaFX ausseinander setzen, sondern können ihre gewohnten Serverseitigen Technologien aus dem JavaEE-Umfeld einsetzen. Neu ist lediglich die Tag-Library von CaptainCasa, die jedoch vom Prinzip her nicht wesentlich anders funktioniert, als bekannte JSF-Libraries.

CustomComponents in JavaFX

Gerrit Grunwald stellte in seinem Vortrag das wesentlich von ihm vorangetriebene Projekt JFXtras vor, welches eine Sammelstelle für JavaFX-Customcontrols darstellt. Er zeigte, welche Möglichkeiten JavaFX bietet um selbst Controls herzustellen oder vorhandene Controls anzupassen. Dazu zeigte er zunächst den prinzipiellen Aufbau von JavaFX-Controls, welche Interfaces und Dateien zu einem Control gehören und wie diese zusammenhängen. Allein dieser Einblick war für mich als Entwickler schon sehr spannend und lehrreich.

Als praktisches Beispiel nutzte er ein Control, welches eine LED-Leuchte darstellen sollte. Zum Erstellen der Grafiken benutzte er ein Vektorgrafikprogramm, welches SVG exportieren konnte. Die SVG-Datei convertierte er mit einem speziellen Tool in ein Format, welches direkt von JavaFX dargestellt werden kann und benutzte dieses als grafische Grundlage seines Controls. Anschließend musste noch die Logik des Controls implementiert werden, was er natürlich mit JavaFX-Bindings umsetzte.

OpenDolphin

Dierk König hat in seinem Vortrag das von ihm mitentwickelte Framework OpenDolphin vorgestellt. OpenDolphin ermöglicht es, eine Anwendung nach dem Shared Presentation-Model Muster zu entwickeln. Dabei wird das Presentation-Model, also sämtliche Daten, die die Benutzeroberfläche beschreiben, auf einem Server gehalten. Die Oberfläche des Clients verbindet sich mit dem Server und bindet sich direkt an dieses Presentation-Model. Serverseitige Änderungen an diesem Model sind dann unmittelbar auch auf Clientseite sichtbar. Das gleiche gilt äquivalent auch für Änderungen des Clients, die sofort zum Server synchronisiert werden.

Werden mehrere Clients mit dem Server verbunden, wird dadurch die UI der Clients untereinander ebenfalls synchron gehalten.

Dies war für mich auch der Hauptgrund, den Vortrag zu besuchen, da dieses ein ähnlicher Anwendungsfall ist, für den meine Arbeitskollegen und ich auch unser Framework SynchronizeFX erstellt haben. In unserer Applikation kommt es ebenfalls auf eine Synchronisierung der UI zwischen mehreren Instanzen an.

Im Detail betrachtet hat OpenDolphin jedoch einen anderen Ansatz. Es lässt sich zwar mit JavaFX verbinden, arbeitet intern jedoch mit einer eigenen Bindings-Implementierung, während unser Framework ausschließlich mit JavaFX-Bindings arbeitet.

Während bei unserem Framework der Hauptaugenmerk auf eine einfache Integration in JavaFX-Anwendungen lag, sieht OpenDolphin eines seiner wesentlichen Ziele darin, die leichte Austauschbarkeit von UI-Technologien zu unterstützen. Da beim Shared-Presentation-Model die einzige Verbindung zwischen Client und Server das gemeinsame Datenmodell ist, lässt sich dieses Ziel vergleichsweise gut erreichen.

In der Demo hat er ein Beispiel vorgeführt, bei dem eine JavaFX-Anwendung und eine HTML5/JavaScript-Anwendung miteinander synchronisiert waren und jeweils die geänderten Daten des anderen Clients anzeigen konnten.

JSF / CDI

Neues aus JavaServer Faces 2.2

In diesem Vortrag hat Andy Bosch über Neuerungen im neuen JavaServer Faces Standard 2.2 berichtet. Er hat dabei 4 wichtige Haupt-Features im Detail erklärt und weitere Nebenfeatures genannt.

Die 4 "Big Ticked Features", wie er es nannte, sind:

HTML5 Support

Wie der Name vermuten lässt, handelt es sich hierbei um eine bessere Integration von HTML5-Features in JSF. Zwar war es auch bisher schon möglich, mit JSF HTML5-Dokumente auszuliefern und auch die neue HTML5-Tags zur semantischen Strukturierung von Webseiten ließen sich ohne weiteres benutzen.

Probleme gab es jedoch z.B. mit den von HTML5 definierten data-* Attributen, mit denen in HTML5 jedem Element beliebige Meta-Informationen mitgeliefert werden können. Dies soll im neuen JSF besser unterstützt werden.

Resource Library Contracts

Für JSF 2.2 war ursprünglich geplant, Multi-Templating zu unterstützen, d.h. es sollte möglich sein, mehrere Themes für eine Anwendung zu definieren und einfach, auch zur Laufzeit, auszutauschen. Ideen eines Marketplaces, auf dem Templates und Themes gehandelt werden könnten, standen im Raum. Letztlich hat sich jedoch gezeigt, dass diese Ideen nicht alle in der gesetzten Zeit umsetzbar waren. Gewissermaßen eine abgespeckte Version ist nun unter dem Namen "Resource Library Contracts" im neuen JSF 2.2 Standard enthalten.

Mit Resource Library Contracts wird definiert, dass in einer JSF-Anwendung unter 'META-INF/contracts' Verzeichnisse angelegt werden können, die einem Template entsprechen. In diesem Verzeichnis sollen alle zum Template gehörenden Dateien untergebracht werden, also XHTML-, CSS-, JavaScript- und sonstige Dateien.

Es wird weiterhin ein gewisser Formalismus definiert, welchen Standards diese Templates folgen sollten, damit ein einfaches Austauschen auch zur Laufzeit möglich ist. Dieser Formalismus ist allerdings nicht besonders streng, weshalb nicht garantiert werden kann, dass das Austauschen ohne Anpassung funktioniert.

Letztlich ist es trotzdem die Aufgabe des Entwicklers, sicherzustellen, dass bestimmte Template-Abschnitte vernünftige Bezeichner besitzen, die in allen Templates identisch sein müssen, damit Elemente ausgetauscht werden können.

Faces Flows

Mit Faces Flows soll es in Zukunft einfacher werden, Seiten zu implementieren, die eine festgelegte Abfolge besitzen, wie zum Beispiel Wizards, Bestellprozesse oder ähnliches.

Dafür wird ein neuer CDI-Scope FlowScope definiert, der genauso lange gültig ist, wie die Seiten des Flows angezeigt werden. Die Definition, welche Seiten zu einem Flow gehören, soll dabei deklarativ erfolgen, d.h. die einzele Seite weiss nicht unbedingt, dass sie zu einem Flow gehört. Dies soll die Wiederverwendbarkeit erhöhen.

Neue JSF-Tags ermöglichen ausserdem die detailierte Steuerung des Flows z.B. mittels Bedingungen/Switch Anweisungen und der Definition eines Start- und Ende-Punkts.

Stateless Views

Das "Stateless Views"-Feature wurde von Andy Bosch im Vortrag nicht sehr euphorisch vertreten. Er machte eher den Eindruck, dass dieses Feature nicht wirklich wichtig oder sinnvoll wäre. Es geht darum, bestimmte Views zu definieren, die keinen serverseitigen Zustand besitzen. Das Ziel dahinter ist, die Performance und den Speicherverbrauch zu minimieren.

Andy hatte jedoch bezweifelt, dass Stateless-Views dazu beitragen können, diese Ziele nennenswert voranzubringen, da schon der Partial-State-Saving-Mechanismus, der bei JSF 2 Einzug gehalten hat, den zu speichernden und übertragenden Zustand auf ein nötiges Minimum reduziert.

Hier die gesamte Feature-Übersicht JSF 2.2.

Apache Deltaspike

Apache Deltaspike ist eine Sammlung von Erweiterungen für "Contexts and Dependency Injection" (CDI). Es ist aus den Projekten Seam 3 und Apache CODI hervorgegangen und soll diese beerben. Im Vortrag von Mark Stuberg wurde das Projekt vorgestellt und einige Beispiele gezeigt.

Beyond PrettyFaces - Einführung in Rewrite

Christian Kaltepoth stellte in seinem Vortrag das Framework Rewrite vor, welches aus dem JSF-Framework PrettyFaces hervorgegangen ist. PrettyFaces hatte mir schon in einigen JSF-Projekten gute Dienste geleistet, weshalb es schön war, einmal direkt von einem der Entwickler einen Einblick zu bekommen.

PrettyFaces ist eine Bibliothek für JavaServer Faces, die einen URL-Rewrite-Mechanismus bereitstellt, um die URLs, die eine JSF-Anwendung benutzt, nach den Wünschen des Entwicklers anzupassen. Ziel ist es, die teils langen und "hässlichen" URLs, die JSF von Haus aus nutzt, durch hübsche und kurze URLs zu ersetzen. Statt 'www.example.org/faces/article/overview.xhtml?articleId=1234' könnte dann z.B. die URL 'www.example.org/articles/1234' benutzt werden. Damit wird gleichzeitig die verwendete UI-Technologie ein wenig versteckt. Vor allem aber können so Links erzielt werden, die sich als Bookmarks vernünftig speichern lassen.

"Rewrite" setzt dieses Ziel fort. Es wurde aus dem ursprünglichen Framework PrettyFaces herausgelöst und kann als Nachfolger verstanden werden. Rewrite versteht sich nicht mehr nur als Erweiterung für JavaServer Faces sondern als allgemeines URL-Rewriting-Framework für Java. Die Unterschiede, die auch im Vortrag gezeigt wurden, betreffen vor allem die Art und Weise der Konfiguration. Bei PrettyFaces hat der Entwickler die Wahl zwischen einer XML-Konfigurationsdatei und Annotationen direkt an den JSF-ManagedBeans. Da die letztere Variante aber sehr unübersichtlich ist und ein zentraler Ort zur Übersicht über alle Rewrite-Regeln vorteilhaft ist, wurde bei uns in Projekten immer die XML-Konfiguration eingesetzt. Diese hat jedoch auch ihre Nachteile, vor allem die geringe Flexibilität, mit der Regeln geschrieben werden können.

Bei Rewrite wird dieses Problem gelöst, in dem eine Fluent-API zur Beschreibung der Regeln mitgeliefert wird. Damit kann der Entwickler seine Regeln in Java-Code formulieren und ist bei Refactorings abgesichert. Er kann aber trotzdem alle Regeln an einer zentralen Stelle im System sammeln oder aber auf verschiedene Klassen aufteilen, wenn das notwendig sein sollte. Der Entwickler hat also die volle Kontrolle.

Aus meiner Sicht ist dieser Ansatz sehr vielversprechend und sollte unbedingt im Auge behalten werden.

Slides

JSF Performance

Im Vortrag von Thomas Asel wurden einige typische Performance-Probleme von JavaServer Faces aufgezeigt und mögliche Lösungen analysiert.

Das potentielle Problem von JSF ist, dass auf Serverseite zu jedem Request ein relativ umfangreicher Lifecycle durchlaufen wird, bei dem ein Komponenten-Baum der UI aufgebaut und bearbeitet wird.

Es stellte sich heraus, dass die Größe des Komponentenbaums einen entscheidenden Einfluss auf die Performance der Applikation hat. Je größer der Komponentenbaum, desto länger braucht JSF für die Abarbeitung des Lifecycles. Interessanter Weise gibt es hier offensichtlich starke Unterschiede zwischen den beiden JSF-Implementierungen. Bei der Referenzimplementierung Mojarra kann man einen exponentiellen Zusammenhang zwischen der Größe des Komponentenbaums und der Verarbeitungsdauer feststellen, was dazu führt, dass bei relativ großen UI's Mojarra recht lange braucht. Die alternative Implementierung Apache MyFaces zeigt ein anderes Verhalten. Zum einen ist die Geschwindigkeit durchgehend deutlich höher als bei Mojarra. Zum anderen ist hier ein Linearer Zusammenhang zwischen Größe des UI und Verarbeitungsdauer zu sehen, was dazu führt, dass der Geschwindigkeitsvorteil umso größer ausfällt, je größer der Komponentenbaum ist.

Aus diesen Erfahrungen können zwei Bausteine zur Verbesserung der Performance gewonnen werden:

1. Wenn möglich, sollte Apache MyFaces als Implementierung gewählt werden. Dies ist allerdings nicht immer möglich. Zwar kann bei allen Enterprise-Servern die JSF-Implementierung getauscht werden, oft sind hier jedoch praktische Einschränkungen durch Support-Verträge gegeben, die verfallen wenn der Server umkonfiguriert wird.

2. Der Entwickler sollte unabhängig von der Implementierung die Größe des Komponentenbaums möglichst klein halten. Vor allem bei Custom-Komponenten ist Vorsicht geboten. Zum Beispiel sollten reine Wrapper-Komponenten vermieden werden.

Neben der reinen JSF-Verarbeitung existieren noch weitere Stellen, bei denen auf die Performance Einfluss genommen werden kann. Vor allem die Übertragung von zahlreichen großen Dateien zum Client nimmt viel Zeit in Anspruch. Um diesem Problem zu begegnen, können JavaScript- und CSS-Dateien zunächst zu je einer Datei zusammengefasst werden und diese kombinierten Dateien "minifiziert" werden. Es wurde jedoch gezeigt, dass dabei auch Vorsicht geboten ist und umsichtig geplant werden muss, um tatsächlich einen Vorteil zu erlangen. Würde man z.B. sämtliche JavaScript-Dateien des gesamten Projekts zu einer einzelnen Datei kombinieren. Es wird jedoch in der Regel nicht überall sämtlicher Code benötigt sondern nur ein Teil davon. Es bietet sich hier z.B. an, Bibliotheken wie jQuery und natürlich jsf.js, die JavaScript-Library von JSF selbst, zu einer Datei zusammenzufassen, da dieser Code in der Regel überall gebraucht wird.

Wichtig ist auch die Integration der Kombinierungs- und Minifizierungsschritte in den Build-Prozess, da man während der Entwicklung ja die Quelltexte in einem vernünftig lesbarem Format erhalten möchte. Im Vortrag wurden einige Tools genannt, die diese Vorgänge z.B. in einen Maven-Build-Schritt erledigen.

Weiterführende Informationen zu den Performancemessungen sind hier zu finden.

I've done a little demo application and a step-by-step tutorial for SynchronizeFX.

The demo consists of a small server application with a simple domain model and a client application that shows a slider control that is synchronized.

On the server there is a domain model that contains a DoubleProperty named sliderValue. This model is transfered to the client applications and will be synchronized between the applications.

On the client we have a view containing a Slider control. This control is bound bidirectionally to the model value so that when the user is dragging the slider at first the value changes in the local instance of the domain model and is synchronized to the server after that.

The SynchronizeFX library ensures that the domain model is synchonized automatically. This means that the change of one client is instantly send to all other clients.

The whole step-by-step tutorial and the source code can be seen at github: https://github.com/saxsys/SynchronizeFX/tree/master/demos/sliderdemo

At saxsys I'm part of a team that is developing a digital scrumboard with JavaFX. One of the key features is the instant synchronization of the UI state between different boards over the network. When you drag a task note at one of the boards it moves instandly on the other board too.

For this feature we had developed a small library and I'm very pleased that we can now release this library as a free open source project called "SynchronizeFX". You can find the code at github: https://github.com/saxsys/SynchronizeFX.

The key idea is that we synchronize models that are build up on JavaFX's Properties. At the moment the synchronization over the network is done with websockets but other technologies are possible too.

I like markdown. And I like open source software. To combine both I created a github repository that contains some of the widespreaded free software license files formatted with markdown. When you use this files in github projects with the file ending of ".md" they are nicely formatted on the github page.

At the moment I have this license files in the repo:

• Apache License v2
• GPL v3
• LGPL v3
• MIT
• Mozilla Puplic License v2

Feel free to copy them as you like.

I had the chance to give a lecture for students of the masters degree for computer science at the University of Applied Sciences Zittau / Görlitz. The title of the course of lectures was "Webdevelopment in practice" and my part was a lecture on the topic "Test driven Development and Dependency Injection".

At first I talked about the advantages of automatic tests in professional software development. I described the different types of tests like unit tests and integration tests. One of the main points was that "real" unit tests only test the component itself and not the surrounding environment. To achive this you need to replace all dependencies of a class with mock objects to be able to simulate an environment for your tests.

Based on this insight I described the design pattern dependency injection as this pattern is the best way to be able to replace dependencies of a component. In the lecture I didn't use a framework for dependency injection but explained how you can implement dependency injection by hand. I showed the different styles of dependency injection like "constructor injection", "field injection" and "setter injection" and explained why in my opinion constructor injection is the most advantageous choice.

After the basics I showed the test driven way of developing software. Writing your test before the implementation is leading to better testable code and in most cases to lesser coupling between components. I personally think that one of the biggest points of doing TDD is that it helps me to focus on the requirements of the software and not the implementation. I think about how a class should be used by a developer. This leads to a better API for every class.

The last part of the lecture was a chapter about testing anti-patterns. I explained that using static methods in java is only aceptable when they are stateless and there are no side-effects. Otherwise you can't be sure about the state of your application when executing the test. The same is true for the Singleton design pattern.

Another testing anitpattern in my opinion is using final for classes or methods as in this cases it is harder to use mocking in the tests.

Exercise

In addition to the lecture there was an computer exercise afterwards. The students had to try out TDD in practice. The exercise was taken from the german book "Das Java-Praktikum" (dpunkt.verlag, 2008, from Reinhard Schiedermeier and Klaus Köhler). This is a book with small exercises to learn and practise java programming. In the book it's not done with TDD but in my opinion the exercises are great for this purpose.

The task was to write a class that encapsulates a specific point in time and gives the user and easy way to handle and visualize this instance of time.

The code of the test and the implementation can be found on github: https://github.com/manuel_mauky/tdd-example-clocktime.