HamsterRage

When I started using JavaFX we were coming from having worked (for a short while) with Swing. Our approach to JavaFX was to use it just like it was Swing, but with different widgets and method names.

This meant that we wrote code that loaded data into screen nodes, and then we had to scrape it out again in the code that ran when the "Save" Button was clicked. When we had nodes that were dependent on other nodes, then we had handlers that ran when focus was gained or lost, so that we could update those other nodes. Or key listeners that would run when "Enter" was pressed.

Stuff like that.

Eventually we learned about Bindings, and we started to develop "rules" about how we would use Bindings. These were things like: When you had multiple properties in your layout that relied on some element in your Presentation Model, bind them all to that property in the Presentation Model, don't chain them off each other. For instance, if we had 3 Buttons that needed to be visible together based on some data, don't bind the first one's visible property to the data, and the second one's to the first one's visible property. Bind them all to the data.

At some point we realized that bidirectional binding of data entry nodes' value properties to the Presentation Model meant that we didn't have to scrape it out inside the "Save" Button code. Eventually we realized you don't even need to send any of that data anywhere from the "Save" Button code because the Presentation Model itself can be shared with the back-end logic - so it already had it.

All of this took years to figure out. Yes, years. And over that time I had the experience of going back to some code that we had written years earlier and rewriting it. Every single time I did this, the new code was better and, without exaggeration, only about 10-20% as big as the original. That's because doing stuff the "wrong" way, which was the only way we knew how at first, was clumsy and took way more code.

Only later did I learn that the approach that we had evolved (stumbled) into was called a "Reactive UI". We didn't try to get there. We just kept refining our approach and finding better techniques as we learned new things, and each incremental improvement moved us closer to Reactive GUI development.

Using JavaFX in a Reactive way, which I believe is the way that it is intended to be used, means that you need to understand the fundamental reactive techniques. This boils down to understanding Bindings, Listeners, Subscriptions and EventHandlers and understanding where you should use each one.

This article is my attempt to explain all that:

https://www.pragmaticcoding.ca/javafx/elements/events_and_listeners

Take a look and let me know what you think.

You might have missed it, but there were some significant new features added to JavaFX in the 19 and 21 releases. These all relate to Observables, and make creating Bindings and Listeners easier to use.

I don't think enough noise was made about these when they came out, and I totally missed them until a little while ago. I spent some time experimenting with them, looking at the source code, and then wrote an article to explain just about everything you need to know:

https://www.pragmaticcoding.ca/javafx/subscribe_and_map

First, we now have some methods to create Subscriptions on Observables, and these are way easier to use than ChangeListener and InvalidationListener. Basically, Subscriptions are wrappers around the Listeners, so the same notification mechanism is used "under the hood", but they are easier to declare and manage.

Secondly, a new method has been added, ObseravbleValue.map(). This is super cool, and allows all kinds of conversions and calculations to be baked into any Binding with only one Observable dependency.

Finally, we now have ObservableValue.flatMap() which allows you to create bindings that reach through composed objects with Property fields. This is going to be massively useful in those cases where you need to bind the Property of a Property and have it re-evaluate if either the wrapper Property or the contained Property change.

Even if you don't normally read my articles, you should have a look at this. You'll probably want to upgrade all of your projects to JFX 21 right away - I know I do.

I have a blog where I talk mostly about all things JavaFX, but this is one of the rare times that I write about something more general:

It's All About (Loose) Coupling

I have about 35 years professional programming experience, and I've read literally millions of lines of code in that time. I've seen some great code, but mostly tons and tons of horrible code (a lot of that my own code from some time past) that I've been tasked with somehow fixing or enhancing. Over that time, I've often pondered what makes some code "good" and others "bad".

My experience has shown me that excessive coupling is just about the worst thing that can happen to a code base in terms of sharing it and maintaining it. Yet, almost no new programmers (and a lot of experienced ones) seem to understand how important it is, and how to avoid it.

In this article, I review the kinds of coupling that I see all the time in projects that I look at. I try to explain how each type of coupling causes issues, how to recognize it and strategies to avoid or remove it.

Take a look, and let me know what you think.

This is the first of two articles about ListView:

https://www.pragmaticcoding.ca/javafx/elements/listview-basics

Personally, I'm a big fan of ListView, and a big fan of using it to do really cool stuff where you treat it more like a scrolling bunch of layouts. The team I worked with for years always wanted to build TableViews, so it was an on-going battle to try to get them to do more cool ListViews (that I mostly lost).

Anyways, you have to start at the start, and this article handles just the basics about ListView.

Take a look and let me know what you think.

Article 2 is just about done and covers most of the things you'll need to know to create cool layouts. Originally this was all one big article, but when I took a look at after a few days away, it was just getting to big and overwhelming.

After finishing the TableView Basics article, I thought it was a good idea to keep on going with the next logical TableView topic: how to handle data coming into your TableCells.

I think it's best if you view a TableCell just the same way you would any other layout. In other words, create a static layout that behaves dynamically in response to changes in the underlying data model. This is conceptually a little bit more complicated with TableCell because that data model is constantly replaced with new versions of the data model as the TableView is populated and the users scroll through it.

Usually, you don't see this complexity because you have a data model for the TableCell that's just a single value. But if you want to have a single column column in your TableView show data from several different elements in your TableView data model, or if you want to have TableCells that display data from a more complicated TableCell data model, then you need to have a better understanding about how that data moves in and out of your TableCells.

Along the way, this article looks at Cell.updateItem() and finds that it's pretty heavily abused and misused - not just in random "how to" articles on the web, but in the JavaFX JavaDocs as well.

Take a look at Handling TableCell Data if you're interested.

I had this article sitting around for the longest time (like over a year) and just couldn't get around to finishing it up until someone asked me a question related to it. That's why it's in Java and not Kotlin.

TableView Basics

This was (still is) intended to be the first of a series of articles on TableView and really covers just the standard stuff you can find in most online tutorials. However, I've tried to go a little bit deeper into explaining how and why stuff works than you'll find in those other tutorials. So, even though it feels to me a bit like, "the article you have to write before you can write the articles about the fun and cool stuff", I think it's going to be a better place to start if you aren't familiar with the basics about TableView.

Future articles are going to talk about creating custom columns, combining data fields into a single column, fancy row stuff and styling aspects.

Anyway, take a look and feel free to tell me what you think.

Over the years, I've seen a lot of people ask, "How can I print this TableView?", or some other similar question. I've always thought this was a bit silly, a TableView is a screen thing (or a VBox, or whatever), and printing it doesn't make much sense.

Most of the answers I've seen to these questions are along that line - printing is a data-centric thing and you should do it from the back-end as it has nothing to do with your GUI.

But it turns out that JavaFX does have classes designed to enable printing of screen layouts! Go figure.

Edward Stephen Jr. has an new article out introducing the concept. I think it's worth a read.

I still don't know what happens if you print a TableView, but at least there is a way to find out.

I have a blog where I talk about programming stuff - mostly JavaFX and Kotlin. I've been trying to keep up a steady stream of new content, and I have lots of ideas for topics, but sometimes life gets in the way. This is the first article I've posted in a couple of months.

This latest article is the last in a set of three about creating custom controls in JavaFX. The first two were:

• When and How to Create Custom Controls
• Customizing Controls that Extend Region

They're not actually required reading for this last article, but they do cover, between them, the most common use cases and approaches for creating custom controls.

But if you've ever wondered what Skin was, and how you might alter the look and feel of one of the standard JavaFX controls, then this article might be for you. In it, I look at turning the standard JavaFX ToggleButton into a toggle switch (with a flipper). Under the hood, it's still a ToggleButton, but by reskinning it, it has a whole new look and feel.

This whole area around Skins and Skinnable is pretty arcane in the JavaFX world. There are very few articles about how to do it. So a word of warning here, everything I know I found out by poking into the source code, looking at other people's attempts and digging into the little I could find on the web. This is not an explanation of any "official" documentation about how to do this - so there may be some mistakes in the approach. I can say that it works, and it works well.

As far as I can tell, this is the clearest (in my opinion, at least), step-by-step breakdown of how to go about creating a skin that's available. It's still not for beginners, but I hope someone finds it useful.

If not, then read the first two articles, I think they're pretty good too.