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:
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.
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.
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.
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.
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.
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.
Let's assume this class diagram for a coffee machine application:
In this class diagram we can see the dependencies of each class:
The CoffeeMachine has a reference to the WaterTank and the CoffeePowderProvider.
The CoffeePowderProvider has a reference to the BeanContainer and to the Mill.
I'm a big fan of the Dependency Injection design pattern and I'm using it a lot.
I'm saying "design pattern" because when I'm thinking and talking about "DI" I don't think about frameworks,
big containers and a lot of magic. Instead, for me DI is a simple concept
of how you write your classes and put them together.
In the past I've used many DI frameworks like Guice, CDI/Weld, EJB and Spring. In other use cases (for example my SnakeFX game) I've done the DI by hand:
Simply put all dependencies of a class into the constructor of this class. In the main method you can now start to instantiate the classes you need starting by the ones that have no dependencies and can therefore be instantiated without constructor parameters needed. It's easy and this way you can't create cyclic dependencies by accident. Look at an old
version of the
DependencyInjector class of SnakeFX
to see what I mean.
Learning how to do the DI by hand was a real eye-opener for me. You can learn that DI is no magic at all and you
will lose all your fear from the big buzzword "Dependency Injection". It's nothing special. Simply a design pattern.