Archives for the month of: November, 2009

Hello, and welcome to a new weekly post on FX Experience. In this post, and all future ‘JavaFX links of the week’, we’ll be covering the latest and greatest JavaFX news that you may have missed in the past week. You may recognise this segment, as it is a subset of the ‘Java desktop links of the week’ that I post on my own blog. Whilst I work out the best way to go forward, the JavaFX links section will find itself being duplicated on both sites.

As with my website, this weekly post tries to not take itself too seriously. We certainly won’t be covering every JavaFX news item every week – we’ll pick out the quality topics that we think you’d like. Also, whilst we all work on JavaFX at Sun, we usually don’t have any insight into the projects we’re linking to, so sometimes we might make mistakes in summarising links. So, if you want to flame anyone, pick me – the best way is to email me. Also, I’d appreciate any links you may have that you think deserve some coverage.

That’s the first week of JavaFX links of the week down. If you’re interested in other Java desktop technologies, check out Java desktop links of the week, and remember to follow the fxexperience twitter stream for more updates.

I came across the cool blog by Rakesh Menon the other day “JavaFX – Text Effects”. It got me thinking how many other cool text effects could we do in JavaFX. Quick research for ideas came up with “50 Stunning Photoshop Text Effect Tutorials” blog post on Smashing Magazine. So I picked a couple fun ones and had a go :-)

Neon Text

Neon Sign ScreenshotClick To Run

(more…)

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…)

We’re intending to write a number of different smaller blog entries focused on describing various features and usages of JavaFX Script. I was asked several times by people this week at Devoxx, why choose JavaFX instead of HTML, Flex, or something else? The two real strong advantages of JavaFX are that 1) you have access to a wealth of Java APIs if you need it, and 2) Developing in JavaFX Script is highly productive.

It is this second point that I hope becomes clear and I hope to convey with this series of Language Lessons. Many times Jasper and I have been holed up writing demos with JavaFX and it is not uncommon for us to just pipe up every so often with “this is just so cool” or “javafx makes some things reaaaaally nice”. I know this sounds like the cheerleader squad coming from the guys who have been part of building this product. Call it pride in craftsmanship. Its honestly how we feel, and hope to convey this to you as we go along.

So with that, here’s the first Language Lesson: Object Creation.

There are actually two different syntaxes for creating objects in JavaFX. One should be used for creating Java objects, and the other for creating JavaFX objects. If you are going to create a Java Object, you will most often want to use the “new” keyword — exactly like you do in Java. You can either use the default no-arg constructor (if the class you are creating has one) or one of the other constructors. For those not familiar with Java, it looks like this:

def obj = new StringBuffer("Hello World");

The second syntax is what we call the Object Literal syntax, and looks more like object creation in JavaScript than in Java. JavaFX Script supports a different concept for object creation and initialization from Java. In the Java world, you have to call one of a fixed set of (generally) explicitly defined “constructors”, which are essentially special functions that create an object. Each constructor has certain parameters, just like functions.

This usually led to object creation & initialization code that looked like this:

JButton button = new JButton();
button.setText("Cancel");

In JavaFX Script, there are no explicit constructors. Instead, you say what object you want to create and what initial values to give to each variable. If you don’t define an initial value for a variable, then the class will use its own initial value. For example, you might do this in JavaFX Script:

Button {
    text: "Cancel"
}

There are some subtle differences between these two cases for a library author (like me), but it works really exactly the same as far as users of the library (like you) are concerned. The difference is that the traditional Java approach is very procedural (do this, then do that) whereas the FX way is declarative. In such simple examples as this it makes no difference, but as we will soon see as the Language Lessons continue, this declarative style lends itself to some very cool possibilities.

Until next time, have fun coding.

We recently finished our session at devoxx on “JavaFX Games”, for all you you who have attended or read our previous post and played the game, here is the source.

Download Source

Enjoy!

We are excited to see all your cool physics experiments and games so please post links in comments.

We just finished our talk here at Devoxx called “Gaming JavaFX”. The talk was scheduled for Friday morning and we wanted to do something really fun and a bit lighthearted, but also really practical. Earlier this week James Gosling had a talk about the Java Store, and we wanted to provide some momentum to the idea that you can write really fun and interesting games in JavaFX and then load these up into the store.

Jasper posted a preview teaser earlier in the week of our Dude with a bomb. You’ll appreciate watching the talk at Parley’s when they have it posted (or you can pay Parley’s a few quid and see the talk even earlier).

Dueling Sketch

The game we wrote is called “Dueling Dudes”. Its a non-scrolling side shooter, not unlike some other popular games like Scorched Earth or iShoot. Except we decided to replace the tanks and earth with dudes and boxes. We placed it in a warehouse and gave each box & barrel physical properties, and gave our dudes weapons and the ability to bash the terrain around. It was tremendous fun. I once read that every programmer should write a game at least once a year just for fun and to keep that youthful exuberance. I couldn’t agree more.

Technically it was a very pleasant and fun thing to work on as well. Integrating the physics engine was not very much work, and using a scenegraph to model things was very natural. We drove things mostly from the engine and a few well placed binds and a single Timeline which drove the world. Jasper pretty well wrote the whole thing over 3 days. Here was our secret equation for success:

Equation For Success

We’ve hosted the game here at FXExperience, hope you enjoy playing it (and if you have troubles on your machine configuration we’d like to know that too!).

DuelingDudes

Click To Play

In a couple hours Jasper and I will be presenting a talk titled “Enterprising JavaFX” at Devoxx. The main purpose of the talk is to describe how to use JavaFX for writing enterprise application content. Here’s a quick teaser screenshot of one of the apps we’re going to describe:

Jira Dashboard Application

Jira Dashboard Application

We’ll be writing some additional blog posts over the next few weeks describing various tips n’ tricks as to how we used web services in this app, how we wrote the custom list cells, and so forth.

bombdudeCome see a cool new game we have written on the current JavaFX release and learn how we wrote it. We’ll even post a link to play it online, though I might have to save that till the end otherwise all I will hear in the room are explosions coming from every laptop.

Gaming JavaFX
with Jasper Potts & Richard Bair
Firday 20th Nov  9:30am
at Devoxx

For those unlucky few who are not attending Devoxx this year, you will be missing many great things. We will post the game and some blogs about it over the next couple weeks and the recorded talk will be available early next year online as a video.

Hope to see you there :-)

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:

FX.deferAction(function() { doAutoHide(); });

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:

FX.deferAction(doAutoHide);

Much nicer.

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!

Should "lookup" drill down into CustomNode?

View Results

Loading ... Loading ...