Taking a look at how EventHandlers, Listeners, Subscriptions and Bindings are different, and how they should be used in a JavaFX application.
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.
New Binding and Listener Methods in JFX 19/21
In JavaFX 19 and 21, new methods have been added to the Observables library that should change the way you write Bindings and Listeners
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.
It just works. I spent years with Eclipse (but quite some time ago now), and it was always a pain getting particular things to work properly. The last time I messed with it was doing research for an article I was writing. I was try to get Gradle support enabled. I wasn't able to do it, but I admit I gave up pretty quickly because I don't have the patience for messing with tools that don't work any more.
In truth, I really liked the Open aspect of Eclipse and I wish it work better than Intellij. Maybe it does now - I don't know. For Java Intellij is awesome, and does everything you could ever dream for. For Kotlin - well Kotlin is an Intellij product and the support for it is awesome.
That looks cool, but I have no idea what it does.
Anticipating complexity is a critical core concept that isn't taught in school either. Nothing of value ever stays simple. Unfortunately, it takes years of experience before you figure that out.
I use Markdown with Jekyll because it integrates nicely with GitHub Pages and I can run it locally for authoring. There's tons of support for it, as far as I can tell. Jekyll uses Liquid for templating, and it seems pretty good. For layout, I use Minimal Mistakes which has a really nice feel and it's comparatively easy to customize. Once I was through all the layout configuration stuff, it's really just a matter of writing articles and pushing them up to GitHub - rarely fiddle with anything technical these days.
For me, it's mostly Java and Kotlin. I look for the same kind of things. Things that I like to see:
- Short methods.
- Small classes
- Sensible packages
- Variables declared to Interfaces not implementations
- Single Responsibility Principle applied.
- DRY applied.
- Good names for variables and methods
- Few instance variables
- Few static members
- No comments, because you don't need them
- Uses lambdas, Streams and Optional
- No empty Catch{} blocks
- No f*&^*cking! arrays.
I can generally tell in a few minutes if something is going to be a pain to work with.
I used Atom for markdown editing for my blog and I loved it. After the death of Atom I felt forced to switch over to VS Code and I hate it.
Hate, Hate. Hate.
I can't tell you why, I just hate it.
I found Pulsar last week and my blood pressure is down where it belongs now.
For programming in Java & Kotlin I use Intellij Idea CE. I cannot image why anyone would bother with VS Code for this purpose either.
Some Thoughts on Coupling
We’re going to look at coupling: What it is, why it’s bad, and the ways that it can creep into your code.
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.
Article: Understanding ListView
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.
In this article, we taka a look at how TableView handles data, the mechanism that move data in and out of TableCells, and how to work with it.
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.
Getting Started with TableView
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.
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.
Sorry, I'm out of the loop. What did the OP do that caused grief with GitHub?
Printing from JavaFX
Master JavaFX Printing: Create, and print reports/documents seamlessly. Enhance your desktop app's functionality now! #JavaFX #Printing
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.
Creating a Custom Skin
An introduction to JavaFX Skins and Skinnable and how to create your own skin.
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:
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.
Welcome to JavaFX
Rather than have a giant sidebar that's difficult to read, I thought I'd create this welcome post and sticky it to the top of the page. This isn't expected to be static, and I welcome any suggestions for changes and additions, just add a comment to this post.
What is JavaFX?
JavaFX is a software platform and a graphical user interface (GUI) toolkit that allows developers to create rich and interactive applications for desktop, mobile, and embedded devices. It provides a powerful set of tools and APIs for building modern, visually appealing applications.
The platform that we now know as JavaFX was introduced as a successor to the Swing framework around the time that Java 1.8 was released. It is designed to provide a more advanced and flexible way of developing user interfaces compared to Swing, with improved graphics and multimedia capabilities.
How is JavaFX Different from Swing?
Swing is much older than JavaFX and this age is reflected in the approach that is taken with it. The following list summarizes the key differences between the two toolkits:
- Styling and CSS: JavaFX supports cascading style sheets (CSS), enabling developers to separate the visual appearance of the application from its logic. CSS can be used to define colors, fonts, layout, and other visual properties, making it easier to customize and maintain the application's look and feel.
- Multimedia Support: JavaFX includes native support for multimedia elements, such as audio, video, and 2D/3D graphics. It provides APIs for playing media files, rendering images, and creating animated visual effects.
- Properties and Bindings: JavaFX includes an extensive library of Observable classes that make it extremely easy to create relationships between the GUI and a Presentation Model. This allows JavaFX to easily support "Reactive" application designs.
- Extensive Animation Support: JavaFX has native support for animations and gradual transitions. Virtually any property of a Node can be associated with an animation.
- Modern Look and Feel: "Out of the box", JavaFX applications look much more modern than Swing applications. It is possible to update the look and feel of Swing, but requires extensive programming.
Useful Links
"Official Links"
- OpenJFX.io This is the "home" of JavaFX, and a good place to get started to download the SDK and see some documentation.
- API Documentation This link is for version 20.
- JavaFX CSS Reference Guide Indispensible information when you're designing your style sheets.
- The Modena Stylesheet This is a slightly earlier version, but you can pull it out of your SDK if you need a newer one. This is essential if you want to understand how to style the standard JavaFX Nodes.
- The Source Code The GitHub project with the source code.
- [OpenJDK Wiki] (https://github.com/openjdk/jfx/)
- Scene Builder The "drag and drop" screen designer tool.
Other Communities/Aggregators
- JFX-Central
- Foojay.io Posts links to new JavaFX content on the web on a regular basis.
- AwesomeJavaFX Has links to virtually every site with cool JavaFX content.
- r/javafx
Blogs
I was going to put in a list of blogs with active JavaFX content, but all the ones I could find have gone quite a while without any new content. If you find any, let me know.
Useful Projects and Libraries
- ControlsFX Pretty much the standard library of extra controls for JavaFX.
- AtlantaFX Modern styling for JavaFX using SASS.
- DirtyFX Implementation of Properties that tracks changes from a base value.
I use all the new features, it's called "Kotlin".
I so want the answer to that to be...they've all dumped Java and moved over to Kotlin. But probably not. BTW, JavaFX works wonderfully with Kotlin. Another reason not to lump it in with Java.
Two reasons I can think of:
- Presumably, !java won't stay dead forever, and it will have as much traffic as you'd expect for such a popular language.
- It would be nice to be able to link from other JavaFX resources to a Lemmy community as a dedicated place for JavaFX discussion and Q&A's.