FX Experience Has Gone Read-Only
I've been maintaining FX Experience for a really long time now, and I love hearing from people who enjoy my weekly links roundup. One thing I've noticed recently is that maintaining two sites (FX Experience and JonathanGiles.net) takes more time than ideal, and splits the audience up. Therefore, FX Experience will become read-only for new blog posts, but weekly posts will continue to be published on JonathanGiles.net. If you follow @FXExperience on Twitter, I suggest you also follow @JonathanGiles. This is not the end - just a consolidation of my online presence to make my life a little easier!
tl;dr: Follow me on Twitter and check for the latest news on JonathanGiles.net.
by Richard Bair | Nov 24, 2009 | General, Web Services
In a post from earlier this year I explored the concept of background tasks in JavaFX. If you haven’t yet, you might want to review that article before reading on. For the impatient: JavaFX is currently a single threaded programming language. All code you write in JavaFX occurs on the same thread. Since you don’t want to write an unresponsive application, you need to write long-lived operations on a background thread. The Task API provides a single consistent abstraction which all background operations in JavaFX are based on. This means whether you are computing fibonacci sequences, breaking down protein chains, writing to a database or reading data from disk there is a single consistent programming model and API that your GUI communicates with. And we think this is a pretty good idea. (more…)
by Richard Bair | Nov 13, 2009 | General, Tips n' Tricks
Just a quick post here. Found another example in Popup code that can be cleaned up and wanted to share. Here is the original code:
[jfx]
FX.deferAction(function() { doAutoHide(); });
[/jfx]
This line of code is going to use the FX.deferAction function which takes as a parameter a function with no arguments and no return. (FX.deferAction is essentially like SwingUtilities.invokeLater(Runnable)). However, since the doAutoHide() function already has this method signature, I can avoid creating the anonymous function and instead simply do:
[jfx]
FX.deferAction(doAutoHide);
[/jfx]
Much nicer.
by Richard Bair | Nov 13, 2009 | API Design, General
The Node class has a lookup function which is used for finding a node in the scenegraph based on an id. Every node has a String id, similar to HTML. In theory it should be unique within the scenegraph though in practice this isn’t necessarily the case.
This lookup function currently only operates over the “public” or “logical” scenegraph, not the physical one. For example, a Button is a Control which delegates its visuals to its Skin. The Skin has a sub-scenegraph. But since we typically want to encapsulate all that, we hide it from the programmer such that most things don’t find this part of the scenegraph. Seems like a reasonable thing to do (Swing went the other way and all the gory details were public which led to issues sometimes where people would dig around and rely on internal details — the horror! — and this made it incredibly difficult to fix bugs later in Swing).
CustomNode was our level of encapsulation. Any CustomNode’s children was explicitly not part of the public API. However, a number of people have complained, likely because they aren’t using CustomNode for encapsulation but rather for modularization of their source code (ie: break a huge file into several files where each piece extended from CustomNode).
So it seems like this partitioning of “logical” and “physical” scenegraphs is quite confusing at times. So the question is, should the lookup function operate on the physical scenegraph? Vote!
[poll id=”2″]
by Richard Bair | Nov 13, 2009 | General, Tips n' Tricks
I was doing a bit of work today reviewing the Popup class we’re working on for the next release of JavaFX. I showed Jasper some code snippets and he pointed out that I should write a quick blog on it because it shows a nice progression of how to do looping in JavaFX. (more…)
by Richard Bair | Sep 18, 2009 | General
I’ve been working my way through Pro JavaFX, a book by some folks who’ve been working with JavaFX from the very first days and who know what they’re talking about. I haven’t quite made it through to the end, but wanted to post my thoughts and a quick review of the book.
Overall this is a really nice book. There is a lot of information here, and a lot of little details and nuances that were news even to me. Perhaps because I know the APIs very well but don’t know the language in as much depth, I particularly like the sections in the book which cover the language itself. There are a lot of interesting things about the javafx language.
I usually like to learn a new platform by starting with the language and some very simple examples whereas Pro JavaFX starts you off somewhere near the deep end in Chapter 1. I would personally recommend starting at Chapter 2 and getting your feet wet with some really simple demos (spinning rectangles are a good starting point) before jumping into the large code examples.
Chapter 3 was also particularly good at explaining a lot of the basic building blocks that go into JavaFX applications: the Stage, Scene, Animations, and basic Nodes. Between Chapters 2 and 3 you should have plenty of information to get up and running writing your first JavaFX apps.
If you’re looking for a handy reference to get started with JavaFX, and for an especially good introduction to the language, I recommend getting a copy of Pro JavaFX.
by Richard Bair | Jun 9, 2009 | API Design, General, Links
A nice little set of articles by Henry Zhang and Jim Weaver at O’Reilly’s InsideRia.com detail how Zhang wrote a PacMan game in FX. From the article:
When I was young I was fascinated by arcade games. One of my favorites was the Pac-Man game. Recently, when I was learning the JavaFX language, I decided to write the game in JavaFX. Based on my experience in other programming languages, I assumed there would be some amount of work in building a game such as Pac-Man, giving me a good feel for RIA development in JavaFX.
A quick perusal reveals at least one no-no that we should document better: never subclass the Shape classes. They weren’t meant to be subclassed, and if JavaFX Script gave us “final” we’d have used it. Rather, use a CustomNode. The only three Node classes in JavaFX 1.2 that were intended to be subclassed were CustomNode, Control, and Container.
I’m not sure anything bad will happen to you if you subclass one of the shapes, maybe we’ll relax this restriction in the future. Primarily, we just never intended this usage. But hey, sometimes the best things aren’t intended! Its great to see some detailed examples coming out about JavaFX, can’t wait to see more!
