New mvvmFX version 1.6.0 released

javajavafxmvvmfx

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.