Another week, another bunch of good links right across the JavaFX ecosystem. Let’s dive right into the links of the week!

• I posted an example of how to create a ListView in JavaFX that supports multiple selection.
• dooApp posted an introduction to their FXForm project. FXForm is a library providing automatic form generation for JavaFX objects.
• Carl Dea has published a JavaFX Tabbed Pane and Tab Panel prototype.
• Sébastien Stormacq has posted about creating an animated chart in JavaFX.
• Srikanth Shenoy continues with the third part of his series titled ‘Effective JavaFX Architecture’. This week his post looks at ‘Asynchronous calls, Command Pattern and Testability‘.
• As part of his series of posts, Srikanth has also been creating a JavaFX project called fxobjects. From the website, “FxObjects is a JavaFX Application Framework that enables methodical, pattern based and test friendly way of developing JavaFX applications based on ideas and best practices distilled from real life usage”.
• Due to the amount of echoing going on about JavaFX and it’s future, most of which consist of references to each other (with very little further information), I’ve picked out Max Katz’s post this week as the only one I’m including. His post discusses what he believes the future of JavaFX looks like, both the good and the bad points.

So, in general, a week of impressive links, with some new releases, and interesting discussions and demonstrations. Keep it up folks, and I’ll catch you all again in a weeks time.

One of the things that would be really nice to have in the virtualised ListView and TreeView JavaFX controls, not to mention future controls like TableView, is multiple selection. Certain kinds of apps just can not exist without multiple selection in fact.

So, unsurprisingly, today I got an email from a user of JavaFX, who claims to be a fan of FX Experience (hi Keith!), who was needing multiple selection for his work. I didn’t actually think it could be done very easily (and one of my main jobs is working on these controls, so I should know), but I spent a bit of time looking into it, and it turns out that it’s actually quite possible, with a number of warnings and rough edges, and also the use of a little bit of unpublished API. As long as you’re promising to not tell anyone, I thought I’d share this code….but just with you, so shhh

What I present to you today therefore is to be considered proof of concept only. Using this in your day job is considered risky, as some of the code may not work in future releases. Being a proof of concept, the code below is not fully implemented (which I’ll detail more shortly), and performance may degrade somewhat as the number of selected items increases. No attempt at performance optimisation has been made. Proceed at your own risk I hope that I’ve sufficiently scared you.

I wanted to briefly show the code, and then just provide you with a jar file to download and use in your own projects. Firstly though, here’s a screenshot I sent to Keith to detail what he should expect to see when he runs the new control:

Do not adjust your TV sets (for those of you, ah, accessing the net via your TV?). The ListView on the right looks odd because the label is rotated inside the cell, to make it apparent that you can get multiple selection even when using a custom cell factory. To get the multiple rows selected I just held down ctrl or shift as I left-clicked, as is usually the case in list controls in other UI toolkits. Here’s the code I wrote to create the app in the screenshot above:

Stage {
    title: "Multiple Selection Demo"
    scene: Scene {
        width: 340
        height: 260
        content: [
            HBox {
                spacing: 10
                content: [
                    MultiSelectListView {
                        items: [1..100]
                    },

                    MultiSelectListView {
                        items: [1..100]
                        cellFactory: function() {
                            def cell:ListCell = MultiSelectListCell {
                                node: Label {
                                    rotate: 180
                                    text: bind if (cell.item == null)
                                        then "" else "{cell.item}";
                                }
                            }
                        }
                    }
                ]
            }
        ]
    }
}

Pretty much the kind of code you’d expect to see when creating a ListView, except the control is called MultiSelectListView, and the ListCell used in the second list is called MultiSelectListCell.

The code for MultiSelectListView is shown below. There is nothing special in here, it simply extends ListView, and adds a bit more API for selectedIndexes and selectedItems, as well as a default cell factory if one isn’t specified by the user.

import javafx.scene.control.ListView;
import javafx.scene.control.ListCell;
import javafx.scene.Node;
import javafx.scene.control.Label;

public class MultiSelectListView extends ListView {

    public-read var selectedItems:Object[];

    public var selectedIndexes:Integer[] on replace {
        selectedItems = for (i in selectedIndexes) items[i];
    }

    override var cellFactory = function():ListCell {
        var label:Label;
        def cell:ListCell = MultiSelectListCell {
            onUpdate: function() {
                def item = cell.item;
                if (item == null) {
                    cell.node = null;
                } else if (item instanceof Node) {
                    cell.node = item as Node;
                } else {
                    if (label == null) {
                        label = Label { }
                    }
                    label.text = if (item instanceof String) then item as String else "{item}";
                    if (cell.node != label) cell.node = label;
                }
            }
        }
    }
}

Moving on, we come to MultiSelectListCell, which is where the real warning comes – this class has unpublished API being used, and we offer no guarantee that it’ll stay this way. Use it at your own risk, and seriously, don’t build your business around this API being available. You’ve been warned.

This class creates a custom MultiSelectListCellSkin, and binds to the selectedIndexes sequence to determine if it is selected or not. When this property changes, it calls some impl_ code to re-evaluate its state, to allow for the background selection colour to be turned on or off as necessary. The rest of the code is pretty straightforward (i.e. don’t question it)

import javafx.scene.control.ListCell;
import javafx.scene.control.Skin;
import com.sun.javafx.scene.control.skin.ListCellSkin;
import com.sun.javafx.scene.control.skin.SkinAdapter;
import javafx.util.Sequences;

public class MultiSelectListCell extends ListCell {

    def multiSelected = bind Sequences.indexOf((listView as MultiSelectListView).selectedIndexes, index) != -1 on invalidate {
        impl_pseudoClassStateChanged("selected");
    }

    package override function createDefaultSkin():Skin {
        SkinAdapter {
            rootRegion: MultiSelectListCellSkin { }
        }
    }

    override function impl_getPseudoClassState():String[] {
        [
            if (multiSelected) "selected" else null,
            super.impl_getPseudoClassState()
        ]
    }
}

MultiSelectListCellSkin is hidden inside MultiSelectListCell (for no particular reason), and its job is simply to just extend ListCellSkin, apply a small bug workaround, and apply a custom behavior, which is where the actual multiple selection magic happens.

class MultiSelectListCellSkin extends ListCellSkin {
    override var behavior = MultiSelectListCellBehavior { }

    postinit {
        // This fixes an issue where the mouseReleased function is called twice.
        overlay.onMouseReleased = null;
    }
}

The final class is a slight extension of the ListCellBehavior class, not surprisingly called MultiSelectListCellBehavior. This class handles the mouse click event, including determining if ctrl or shift is held down, and acting appropriately.

import com.sun.javafx.scene.control.behavior.ListCellBehavior;
import javafx.util.Sequences;

public class MultiSelectListCellBehavior extends ListCellBehavior {

    override function mouseReleased(e) {
        // Note that list.select will reset selection
        // for out of bounds indexes. So, need to check
        def listCell = skin.control as MultiSelectListCell;
        def listView = listCell.listView as MultiSelectListView;

        // If the mouse event is not contained within this ListCell, then
        // we don't want to react to it.
        if (listCell.contains(e.x, e.y)) {
            if (listCell.index >= sizeof listView.items) return;

            var row = listCell.index;

            if (e.controlDown) {
                if (Sequences.indexOf(listView.selectedIndexes, row) == -1) {
                    insert row into listView.selectedIndexes;
                } else {
                    delete row from listView.selectedIndexes;
                }
            } else if (e.shiftDown) {
                var start = listView.focusedIndex;
                var end = row;
                var range = if (start < end)
                    then [start..end] else [end..start];

                listView.selectedIndexes = range;
            } else {
                delete listView.selectedIndexes;
                insert row into listView.selectedIndexes;
                listView.focus(row);
            }
        }
    }
}

That’s all there is to it. Note that whilst I wrote this, because it is not a ‘production-quality’ control, I haven’t tested it at all, past a few user tests. I’m sure it’ll have issues. If you report them to me I’ll revise this post to ensure the best control we can have. You should also note that this in no way reflects how we’ll do multiple selection in the future, when it is supported ‘natively’.

Now, on to the warnings I warned you were coming. In general, don’t use the select() function any more – just directly manipulate the selectedIndexes sequence. Also, don’t use the selectedItem / selectedIndex properties any more – just use the selectedItems and selectedIndexes sequences instead. If you think you’re going to forget this, it should be possible to just keep overriding more functions / properties to have everything work as expected, but unless I feel sufficiently nagged, I’ll probably just leave this as a user exercise. Similarly, there is no support for keyboard navigation / multiple selection in this version.

So – that’s it really. You can download a NetBeans project containing this source code, or if you’re just wanting to use the code as-is, I’ve also put up a jar file for you to use directly in your own applications. Feel free to leave comments.

Well, what an interesting week we had in the JavaFX world. It started off with Kirill Grouchnikov posting his thoughts that JavaFX is a train wreck. This created a number of threads around the web discussing this. At the same time Stephen Chin posted his petition to open source JavaFX. So much controversy, so many (sometimes anonymous) comments – what a week! For what it’s worth, I’m just reporting the news here, not endorsing or disagreeing with any of it

• As mentioned, this week Kirill Grouchnikov outlined his thinking that JavaFX is a train wreck. Quite quickly the comments on his blog became incredibly side-tracked, so he turned off comments. Because of the nature of the topic, the discussion spilled over into a number of other blogs, and for the most part was mostly negative.
• Stephen Chin has posted a petition to open source JavaFX. Further discussion is available here and here.
• The next Silicon Valley JavaFX Users Group topic has been announced: it’ll be Stephen Chin and Keith Combs doing a live lab session where they will demonstrate the concepts behind implementing JavaFX Controls. It’s coming up August 11, so a few weeks away yet.
• Jim Weaver has posted a tutorial on the Sun Developer Network titled “Stylin’ with JavaFX“.
• Dean Iverson has posted some comments about his previous blog posts to fix up mistakes and misunderstandings on his part.
• Max Katz has done a bunch of blogs recently, titled ‘Binding to server-side context variable from JavaFX‘, ‘Using Expression Language (EL) in JavaFX to communicate with server‘ and ‘Seam conversations from JavaFX‘.
• Alex Ruiz has announced FEST JavaFX Compiler Maven Plug-in 1.0b2. This release adds new configuration options.
• Sergey Malenkov has posted about ‘localized reaction time‘. It shows how you can localise your application in JavaFX.
• William Antônio Siqueira has created LyricSearchFX, which you can run over at his new blog.
• I posted two brief screencasts to show off a TabView control I’m building in my spare time.

Whew! What a week. Catch you all again in a week.

A good week of JavaFX links this week – some exciting releases, and interesting blog posts exploring / announcing interesting work. Let’s get right into it!

• Richard Bair posted a text alignment trick that is useful when trying to lay out Label text.
• I posted a tip regarding sequence performance, and how you can cut down on needless churn.
• Stephen Chin has announced the release of JFXtras 0.7 release candidate 2.
• Max Katz is presenting at the next Silicon Valley JavaFX Users Group meetup, which is this coming week on Wednesday, July 14, 2010 at 7PM PST.
• Speaking of Max, he has posted two blog posts titled ‘Calling Seam component from JavaFX‘ and ‘Invoking Hibernate Validator from JavaFX‘.
• It looks like IntelliJ IDEA is starting to support JavaFX even more, with the 0.2 release of their JavaFX plugin for IntelliJ. Watch the Getting Started video if you’re interested.
• Nicholas has blogged about displaying a JavaFX applet in a Grails application.
• Srikanth Shenoy has posted the second part of his multi-part series on ‘Effective JavaFX Architecture’, this time covering Test Driven Development with JavaFX.

That’s us for another week. Thanks to everyone for your hard work in the community, and for sharing your knowledge with the rest of us Catch you all again in a weeks time!

Sure, there are plenty of tips discussing how to use sequences in JavaFX, but the one I wanted to cover quickly today is regarding the fact that sequences are immutable. That is, once you create them, their content can’t change.

‘You lie!‘ I hear you all shout, running off to your IDE’s to show me the following fully legal and compiler-friendly code:

var seq = [ 1, 2, 3 ];
insert 4 into seq;
insert 5 into seq;
delete 1 from seq;

println(seq);

If you run this code, the output will be [ 2, 3, 4, 5 ], as expected. It’s understandable if you think the sequence is being updated in-place – it certainly looks that way from where we’re all standing – except that under the hood it isn’t, and there are performance implications we need to be clear on. To get straight to the point, the insert and delete instructions create a brand new sequence instance, but fortunately they also ensure that the seq variable always refers to the new instance, quietly leaving the old instance to get garbage collected.

Of course, as I just noted, from a developers perspective we can treat seq as a reference to a sequence instance and be oblivious to these ‘behind-the-scenes’ sequence shenanigans. There is nothing wrong with this, but it’s important to know that creating sequences isn’t free, and certainly minimising the amount of sequences we create is a smart idea.

To be slightly more technical, I should note that there are some exceptions to this ’sequences are immutable’ rule when dealing with non-shared sequences of specific types, but I don’t want to muddy the point of this blog, which is….

Use the expression language features of JavaFX to reduce the number of sequence instances you need to create.

For example, you might have code that looks like the following:

var seq:Integer[];

for (i in [1..MAX]) {
    insert i*i into seq;
}

I hope, with this blog post firmly at the forefront of your mind, you can now see why perhaps this isn’t such a great idea: we’re creating MAX sequence instances, one for each iteration of the for loop – ouch. Importantly, this example isn’t far-fetched and made to prove a point: I just found a very similar example in my code the other day (which I promptly fixed up), and even found a few blog posts on this site and other sites that use this approach. What you actually should do is something like the following:

var seq:Integer[];

seq = for (i in [1..MAX]) {
    i*i
}

In this case rather than create MAX instances of the sequence, we’re creating only one – the result of the for expression. This is considerably more efficient, and can lead to huge performance gains, depending on what you’re doing. In my case it made the difference between my code being usable and being jittery. Obviously in my case this was a very critical for loop, and it may be similar in your use cases also.

I hope that this helps you eek out a little more performance from your apps. Now, go forth and optimise your sequences

One of the annoying sharp edges in JavaFX is around text alignment, especially with regards to the Text node. In this tip, I’m going to skip using the Text node in favor of using the Label control, because it gives you better… uh… control over text placement. This is actually based on a trick I used to use with Swing all the time. If I wanted to center some text in a layout, I’d specify the space I wanted the text positioned within by setting the size of the label to match that space, and then I’d either position the text at the center, top, right, etc.

Using the same trick in JavaFX, I can cause some text to be right positioned. An additional benefit to using the Label control is that if the space isn’t big enough for the text, it can be elided using the textOverrun variable.

    Label {
        width: bind 120
        text: "Right Positioned Message!"
        font: Font { size: 10 }
        textFill: Color.BLACK
        hpos: HPos.RIGHT
    }

Anyway, it ain’t perfect but a good trick for the moment.

Wow, July already. Time sure is flying these days. As always, please feel free to flick me an email or a tweet to let me know of any news you want included. Let’s get on with the news!

• Tor Norbye blogged about not using implicit return types in public API declarations in JavaFX, and from my perspective, copped quite an unfair bashing for doing so. He also provided a NetBeans plugin for identifying this issue, and ‘quick fixing’ it. As for the comments on the post: I personally love implicit typing, but not when it is public API, for the reasons Tor identifies. It would suck to have to type :Void for every function and specify the type of all parameters in an overridden function. The language really isn’t broken.
• The Exadel JavaFX Plugin for Eclipse has been upgraded to 1.3.3. In addition to this they’ve blogged about the new ‘go to member’ feature added in 1.3.3.
• Johannes Schneider has announced that he has added his JavaFX2Java bridge to the JFXtras project (in a separate cloned repo). You can find out more about this bridge in another blog posting.
• The Oracle Technical Network interviewed John Jullion-Ceccarelli and Martin Ryzl, two of the managers behind NetBeans 6.9. They discussed the new NetBeans Composer tool for rapid JavaFX application development.
• Srikanth Shenoy has blogged about ‘Effective JavaFX Architecture‘. This is the first part of a series of posts he is promising to do.
• Eviware popped out of nowhere this week with their loadUI application for load-testing webapps. They’ve posted some videos and in general their app, built using JavaFX and Groovy, looks really impressive.
• Oracle announced that JavaFX is powering the Major League Baseball ‘fantasy baseball’ applications, although I haven’t yet seen it in action because I don’t live in the US or Canada (but you can go here to sign up, and presumably play).

That’s it for another week folks. Catch you in a weeks time.

A fairly quiet week in the JavaFX world this week, but nevermind, I’m sure it’s just because the majority of you are too busy working on your blog masterpieces for next week Regardless, there are some very useful links in this weeks post, so have at it, and as always please do flick me an email (or twitter message) with any link you think is worthy of being included.

• There’s been a bit of a documentation refresh going on recently, with the JavaFX 1.3 API getting refreshed, and a JavaFX CSS reference document being made available at the same time. For more information check out my summary blog post.
• I posted about caching in custom cells in JavaFX controls such as ListView and TreeView. This is (probably) a useful post for people creating custom cells.
• Jim Clarke has blogged about his experimentation with JavaFX and WEBM on Linux.
• Jan-Hendrik Kuperus has blogged the second part of his post on integrating JavaFX with regular Java.
• Mark in your calendars July 14th, which is when Max Katz is talking about enterprise JavaFX.
• Speaking of Max, he has also blogged about the new preferences dialog added to the JavaFX Plugin for Eclipse that Exadel, the company he works for, develops.

That’s all folks. Thanks to everyone who took the time to post about what they’re working on, and for those of you who didn’t, I’m looking forward to your blogging masterpieces next week

Ok, I know we’ve been going on about custom cells / cell factories a bit recently, but I wanted to do one more post about a very useful topic: caching within cell content.

These days ‘Hello World’ has been replaced by building a Twitter client, so I’ve decided to frame this topic in terms of building a Twitter client. Because I don’t actually care about the whole web service side of thing, I’ve neglected to implement the whole ‘real data’ / web services aspect of it. If you want to see an actual running implementation with real data, have a look at William Antônio’s Twitter client, which is using this ListCell implementation.

So, in all the posts to this site related to cells, I’m sure you’ve probably come to appreciate the ways in which you should create a ListView or TreeView with custom cell factories. Therefore, what I really want to cover in this post is just the custom cell implementation, and the importance of caching. A Twitter client wouldn’t be a true client without showing the users profile image, so this is my target for caching. Without caching, each time the cell was updated (i.e. the content changes due to scrolling, or when we scroll a user out of screen and then back in), we’d have to redownload and load the image. This would lead to considerable lag and a poor user experience. What we need to do is load the image once, cache it, and reuse it whenever the image URL is requested by a cell. At the same time, we don’t want to run the PC dry of memory by loading all profile images into memory. Enter: SoftReference caching.

Word of warning: I’m not a caching expert. It is possible that I’ve done something stupid, and I hope you’ll let me know, but I believe that the code below should at least be decent. I’ll happily update this example if anyone gives me useful feedback.

Check out the code below, and I’ll continue to discuss it afterwards.

import model.Tweet;

import java.lang.ref.SoftReference;
import java.util.HashMap;

import javafx.geometry.HPos;
import javafx.geometry.VPos;
import javafx.util.Math;
import javafx.scene.control.Label;
import javafx.scene.control.ListCell;
import javafx.scene.image.Image;
import javafx.scene.image.ImageView;
import javafx.scene.layout.Container;
import javafx.scene.text.Font;
import javafx.scene.text.FontWeight;

// controls whether the cache is used or not. This _really_ shouldn't be false!
def useCache = true;

// map of String -> SoftReference (of Image)
def map = new HashMap();

def IMAGE_SIZE = 48;

public class TwitterListCell extends ListCell {

    // used to represent the users image
    var imageView:ImageView;

    // a slightly bigger and bolder label for the persons name
    var personName:Label = Label {
        font: Font.font("Arial", FontWeight.BOLD, 13);
    }

    // the message label
    var message:Label = Label {
        textWrap: true
    }

    override var node = Container {
        content: bind [ imageView, personName, message ]

        override function getPrefHeight(width:Number):Number {
            def w = listView.width;
            Math.max(IMAGE_SIZE, personName.getPrefHeight(w) + message.getPrefHeight(w));
        }

        override function doLayout():Void {
            var x:Number = -1.5;
            var y:Number = 0;
            var listWidth = listView.width;
            var cellHeight = height;

            // position image
            Container.positionNode(imageView, x, y, IMAGE_SIZE, cellHeight,
                HPos.CENTER, VPos.TOP, false);

            // position text at the same indent position regardless of whether
            // an image exists or not
            x += IMAGE_SIZE + 5;
            var textWidth = listWidth - x;
            var personNameHeight = personName.getPrefHeight(textWidth);
            Container.resizeNode(personName, textWidth, personNameHeight);
            Container.positionNode(personName, x, y, listWidth - x, personNameHeight,
                HPos.LEFT, VPos.TOP, false);

            y += personNameHeight;
            Container.resizeNode(message, textWidth, message.getPrefHeight(textWidth));
            Container.positionNode(message, x, y, listWidth - x, height - personNameHeight,
                HPos.LEFT, VPos.TOP, false);
        }
    }

    override var onUpdate = function():Void {
        var tweet = item as Tweet;

        personName.text = tweet.person.name;
        message.text = tweet.message;

        // image handling
        if (map.containsKey(tweet.person.image)) {
            // the image has possibly been cached, so lets try to get it
            var softRef = map.get(tweet.person.image) as SoftReference;

            // get the image out of the SoftReference wrapper
            var image = softRef.get() as Image;

            // check if it is null - which would be the case if the image had
            // been removed by the garbage collector
            if (image == null) {
                // we need to reload the image
                loadImage(tweet.person.image);
            } else {
                // the image is available, so we can reuse it without the
                // burden of having to download and reload it into memory.
                imageView = ImageView {
                    image: image;
                }
            }
        } else {
            // the image is not cached, so lets load it
            loadImage(tweet.person.image);
        }
    };

    function loadImage(url:String) {
        // create the image and imageview
        var image = Image {
            url: url
            height: IMAGE_SIZE
            preserveRatio: true
            backgroundLoading: true
        }
        imageView = ImageView {
            image: image;
        }

        if (useCache) {
            // put into cache using a SoftReference
            var softRef = new SoftReference(image);
            map.put(url, softRef);
        } else {
            map.remove(url);
        }
    }
}

You’ll note that in this example most of the code is pretty standard. A few variables are created for the image and text, and then I’ve gone the route of laying the content out in a Container, but you can achieve a similar layout using the available layout containers. Following this I have defined an onUpdate function, which is called whenever the cell should be updated. This is usually called due to a user interaction, which may potentially change the Cell.item value, which would of course require an update of the cell’s visuals.

The bulk, and most important part, of the onUpdate function deals with loading the users profile image, or retrieving and reusing the cached version of it. Note the use of the global HashMap, which maps between the URL of the users image and the Image itself. Because it is global (i.e. static), this map will be available, and used, by all TwitterListCell instances. Also important to note is that I didn’t put the ImageView itself into the HashMap as a Node can not be placed in multiple positions in the scenegraph, but an Image can be.

The rest of the code in this class really just deals with the fact that a SoftReference may clear out it’s reference to the Image object if the garbage collector needs the memory, in which case we need to reload the image again. The other obvious part is the need to also put the image into the cache if it’s not already there.

Shown below is the end result, but remember that there is a working version of this demo in William Antônio’s Twitter client, which is a very early work in progress.

I hope this might be useful to people, and as always we’re keen to hear your thoughts and feedback, and what you’re hoping us to cover. Until next time – cheers!

Recently a few useful documents turned up on the web related to JavaFX, so I thought I’d briefly provide the links to them in case you weren’t aware of their existence.

Firstly, the JavaFX team updated the JavaFX 1.3 API documentation. There is a bunch of new content for much of the API, and improved package documentation (which you can see by clicking the arrow on the main page relevant to the package you’re interested in). In particular, the javafx.animation, javafx.scene, javafx.scene.control and javafx.scene.chart packages have a bunch of useful information.

Secondly, with the huge improvements to CSS support in JavaFX 1.3, we’ve published a comprehensive CSS guide. This is a huge resource to people interested in styling JavaFX user interfaces, as it lists all available css properties for each control.

Finally, for those interested in ensuring your coding style is following convention, the best resource is Tor Norbye’s JavaFX coding conventions document. It’s not the definitive style guide for JavaFX, but it is a great starting point. I think there is only one difference between his conventions and what we use internally, and he notes this in the page.

There we go – a few very useful resources that you may be interested in perusing in a spare moment.