This week I've released a new version of mvvmFX. In this blog post I will highlight some of the new features and changes.

EasyDI integration

Support for dependency injection was always one of the main goals of mvvmFX and one of the first features we had implemented. Previously, mvvmFX was supporting CDI/Weld and Guice as dependency injection frameworks. With the new release we added support for the small DI library EasyDI.
I've written EasyDI as a dependency injection alternative for small to medium projects with the goal of an easy setup without extra configuration but with the tradeof of haven limited features compared to full-fladged DI frameworks like CDI or Guice. If you are interested in EasyDI you can read more about it here and here.

Validation in separate module

We have extracted the Validation feature into it's own maven module. This way you can use the validation mechanism without having to import the whole mvvmFX module. If you are using the validation classes and you upgrade to the new version you will have to add the mvvmfx-validation module to your maven/gradle build file. Everything else (i.e. package names) stays the same.

Additionally we have improved the ObservableRuleBasedValidation to be more flexible. Instead of an ObservableValue<Boolean> you can now also use an ObservableValue<ValidationMessage> as rule to control when a validation is failed and which message should be used in this case.

Lifecycle methods for ViewModels

It's now possible to add lifecycle hooks to the ViewModel. This way you can react to the event of the View being added to or removed from the SceneGraph. This can be useful to implement housekeeping of listeners or cleanup of used resources.
However, at the moment we see this as beta: It works for many of our use cases but we aren't 100% sure if there are hidden side effects that we haven't thought of yet. As always we highly appreciate your feedback.
At the moment this lifecylce hook is only available for FXML bases Views and only in the ViewModel. For the next version we are planing to add it for Java code based Views and the CodeBehind classes itself.

This is just a first step to help preventing memory leaks. For the next version we are also planing to provide a way to prevent unintentional garbage collection of Controller/CodeBehind classes as a second step.

New example app showing asynchrounous behavior usind CompletableFuture

There are many ways of handling asynchrounous behavior in JavaFX apps. One that I personally like a lot is using java's CompletableFuture. Therefore I've added a new example app that shows how you can use CompletableFuture with mvvmFX to wrap a blocking/synchrounous backend service in the ViewModel and still have a non-blocking UI. You can find the example code here.

I hope you like the new release. Tell us how you like it and provide feedback in the comments or in the issue tracker of the project.

In the JavaScript world there are thousands of libraries and frameworks available for you to use for your next application. And with plenty of choice there comes the agony of choice. Before you can even think about choosing the "best" framework you need a set of frameworks that you will take a closer look at in the second step. To get a first impression of a framework and to help you decide which framework is worth a closer look, one starting point is the TodoMVC project. It contains the same simple task management app created with different Web/JavaScript frameworks.

It's not a real-world application and ignores lot's of topics that are important for a typical web application. But it gives you a basic idea of the core principles and approaches of each framework and the differences between the frameworks. Another nice aspect of TodoMVC is that you can see a basic project setup for the framework of your choice. The TodoMVC app is neither too trivial (like the typical "hello world") nor is it too complex to understand the code anytime soon.

The idea to have a small set of requirements that are implemented with different approaches, libraries and frameworks isn't only limited to JavaScript frameworks but would be useful in other domains like JavaFX too.

For this reason I've started a "TodoMVC JavaFX" Project. Let's create the same app with different JavaFX frameworks! You can find the repository of the project on Github:

https://github.com/manuel_mauky/todomvcFX

The first idea to start this kind of project came to me after a talk I gave at the Java User Group Görlitz on "UI Design Patterns". In this talk I was comparing several MVC variants by implementing the same app with each pattern (here you can find the code).

Some time later I was creating a Todo example app for mvvmFX which I later used as starting point for the TodoMVC JavaFX project.

At the moment there are 3 implementations: First there is a "reference implementation" that only uses pure JavaFX without any framework. It's meant be a reference of how the application should behave and look like. Developers can take FXML, CSS or Java files from it to start with their own implementation.

The second example is the mvvmFX implementation I've mentioned above. The third example uses FluxFX, an experimental library that I've created for a talk on how to implement the Flux architecture with JavaFX.

In the future I will add other examples and I hope that the community will contribute other examples too. At the moment I'm working on an example using the Haskell-like pure functional language Frege and FregeFX.

If you like to add another example with your framework of choice (No matter if you are the author of this framework or just a user) you are very welcome. Just add an issue in the github project so that me and others know you are working on it and so we can discuss your idea. Or simply send a PullRequest :-)

I hope that the gradle build configuration I'm using at the moment works for your framework/language too. If this is not the case please tell me - I'm open to suggestions of how to improve the build process and project setup. You can find more information on how to contribute in the readme file. And of cause I'm also happy to hear if you think there is some information missing or the description could be improved.

To make sure that all examples are fulfilling the requirements I've added a set of TestFX tests. These UI tests are simulating a user interacting with the app. If you've never seen a little more complex TestFX test this might be interesting for you too.

I hope this project will be useful for JavaFX developers out there. Please tell me what you think :-)

I've written an article for the german JavaMagazin 7.15 with the topic "Reactive Programming mit JavaFX" (you can find it here online: jaxenter.de).

In the article I'm introducing the reactive programming paradigm from the perspective of a UI developer. Reactive Programming is technique to escape from the so called "callback hell". Instead of reacting to user events with callbacks (i.e. side effects on a global state) you define dependencies between time-varing values that will be updated automatically by the programming environment when changes or events are happening.

With its properties and data-binding API, JavaFX already has a good base for reactive programming.

One point I wanted to highlight in the article is the fact that you don't necessarily need a functional programming language to do "Reactive Programming". Of course the original work and research in the field of reactive programming was done with functional languages but it's possible with non-functional languages like Java too (of course the syntax is far more inconvenient but thats a fact that apparently every java developer has resigned to ;-)). A relatively simple abstraction over the Observer design pattern is all you need, like it is done in the internal implementation of the JavaFX properties and databindings.

To make the programming easier there are also libraries available that can help to write JavaFX application in a reactive programming way. The first library I'm introducing in the article is my own Advanced-Bindings project that can be used for more complex bindings.

After that I'm using the really cool ReactFX library for composition of event streams. At the end I'm presenting the library RxJava which is obviously the most famous of the stated libs. In the article I'm showing how you can integrate a RxJava based service in a JavaFX application.

In the first part of this series I was showing an interface for a generic repository and an in-memory implementation. In this part I will show another implementation with the Java Persistence API (JPA).

An in-memory repository is a good starting point and is handy during the development but at some point you need "real" persistence. One option in the Java world is the "Java Persistence API" (JPA). This blog post is not a JPA tutorial so I expect you to have some knowledge about JPA already. Furthermore I have to admit that I'm not a pro when it comes to JPA. Again: The things described here are working for me but I'm sure there are many improvements possible.

Persisting data is part of most apps and there are several ways of doing persistence. In this blog post I'm sharing some of my techniques and personal oppinions. Maybe it doesn't fit for everybody but it works for me and maybe this is helpful for some people.

When it comes to persistence my favorite is EventSourcing: Instead of persisting the current state of your data, only events of changes to your data are persisted. The current state can then be (re-)calculated from the events. In my oppinion this is the most natural and elegant way of handling persistence but, to be honest, it's not the easiest to implement, especially in Java.

But this is another story. Today I want to further investigate persistence for use cases where EventSourcing is not an option and/or classical state-based persistence is needed. In such cases I'm typically using the repository pattern. The key of this design pattern is to define a common interface for persistence functionality that is independent from the underlaying persistence technique. For each specific persistence technique (for example a database, the filesystem or a cloud storage) an implementation of the interface can be provided. This way you can exchange the persistence technique without touching the rest of your application. Additionally this improves the testability because you can provide a mock implementation of the repository interface for unit tests.

Yesterday we released the new version 1.1.0 of mvvmFX. This time we have lots of new features that can make the development of JavaFX applications easier.

Some of the new features:

Commands

The most interesting new feature are the Commands. With them you can now encapsulate actions in the ViewModel and provide them to the View. Each Command has boolean properties showing if it is running at the moment and if it isExecutable. The latter can for example be used in the View to bind the visibility of a button. With CompositeCommands you can compose many commands so that all sub-commands are executed when the composite command is triggered. See the wiki page for a detailed explanation.

ModelWrapper

The second big feature is the ModelWrapper. This class can simplify the mapping between the Model and the ViewModel for CRUD like applications. Instead of duplicating the fields of a model class in the ViewModel you can now use the ModelWrapper that support reloading (copy values from Model to ViewModel), resetting (set ViewModel to default values) and committing (copy values from ViewModel to Model). In the wiki you can see a detailed example.

Using mvvmFX views as items of ListView

You can now use the CachedViewModelCellFactory as CellFactory for the javaFX ListView component. This way you can use mvvmFX Views as items of the ListView. See a more detailed description in the wiki: https://github.com/sialcasa/mvvmFX/wiki/ListView-containing-mvvmFX-views.

Inject ResourceBundle in the ViewModel

Until now it was only possible to inject the ResourceBundle in the View. But for some use cases it would be useful to have the ResourceBundle available in the ViewModel too. With the new version this is possible via the annotation @InjectResourceBundle. In addition we have added a live cycle method for the ViewModel like it was possible in the View before. We use the same naming conventions for this: If the ViewModel has a method with the signature public void initialize() it will be called by the framework after the injection of the ResourceBundle is done.

public void MyViewModel implements ViewModel {
    @InjectResourceBundle
    ResourceBundle resourceBundle;

    private StringProperty title = new SimpleStringProperty();

    public void initialize() {
        title.setValue(resourceBundle.getString("app.title"));
    }
    ...
}

Utility modules

Additionally we have introduced two more Maven modules:

mvvmfx-utils contains utilities that are not directly related to MVVM but that are more generally useful for JavaFX development. We moved the SizeBindingsBuilder and the ListenerManager from the core module to this new module to improve the cohesion of the core module.

mvvmfx-testing-utils contains utils that we used for testing purposes internally for some time. Now these utils are available for the public. The most interesting is the GCVerifier that we are using for testing situations where Garbage Collection is important.

See the whole list of changes at github: https://github.com/sialcasa/mvvmFX/releases/tag/mvvmfx-1.1.0

Today I had an interesting issue with JavaFX ChangeListeners and Exceptions. I was writing a unit test to reproduce a simple bug in mvvmFX. The issue was a NullPointerException that was thrown under some specific conditions. No big deal. I had written the test case that reproduces the exception in no time but something was still wrong. The exception was visible in the console window of the IDE but the test was still green.

When you use a ListView or a TableView in JavaFX you can easily separate the definition of the List/Table and the data that is displayed by the component.

For example when you use a TableView you could create an ObservableList containing your data objects and set CellValueFactories to define what value will be displayed by a specific column. Look at the code from the Oracle docs for a simple example.

The key point is: When you add/remove an instance of your data in the observable list (your data model) the table will update itself accordingly. You don't need to manually add a new row to the table or anything like that. This is a realy cool way to separate the visualization of the table from the data to be displayed.

Some days ago we have released the first stable release of our mvvmFX library that helps you to implement the Model-View-ViewModel pattern with JavaFX.

The new release can be used with Maven/Gradle:

<dependency>
        <groupId>de.saxsys</groupId>
        <artifactId>mvvmfx</artifactId>
        <version>1.0.0</version>
</dependency>

compile 'de.saxsys:mvvmfx:1.0.0'

Additionally Alex and me have written an article for jaxenter.de. This is a german version. An english version of the article will follow next week.

On december 3, 2014 I gave another talk at the Java-User-Group Görlitz with the title "Model-View-* : UI-Design-Patterns im Detail".

The talk was all about the Model-View-Controller pattern and it's variants like Model-View-Presenter (in different flavours) and Model-View-ViewModel. The example code was written in JavaFX. You can find the Code here on github. Of course I also presented the usage of our own MVVM framework mvvmFX.

Additionally I spoke about the scope of UI patterns: On the one hand side you can see "MVC" at the abstraction level of a single UI control. In the talk I used the example of a TextField control.

On the other hand you will often here people talking about "MVC" when they talk about the overall application architecture. I compared the terms of MVC with the well-known Three-tier Architecture and the less common CQRS architecture.