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
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
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
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.