Next area to cover for JavaFX App Development series is developing the application using JavaFX (version 1.3). Development of the application using JavaFX had its ups and downs. One highlight is the ease at which one can customise the view of the ListView control, very easy and flexible. The biggest downside is the fact that JavaFX does not have any built in support for concurrency (multi-threading), although Java code can be used for back-end concurrency. However when it comes to front-end concurrency there is only a single function in JavaFX which only works in a single situation (deferring the action to be executed at a later time).
JavaFX's single option for front-end concurrency is far from ideal. What happens if you're using Prism instead of Decora for displaying the application? If you're in that situation then you're out of luck! Such an issue being highlighted will likely increase the haste to include basic built-in concurrency for the front and back end stuff in JavaFX. Maybe this support will be in the next major release?
Customising/setting up controls is fairly straight forward with JavaFX. What makes this task especially easy is that fact that the look and feel can be completely decoupled with the CSS support. I have largely been satisfied with the suitability of the Caspian look. Still some tweaking of the look for the XTableView control will need to be done in order to make the text of selected rows readable. Some controls lack functionality that would make the application more complete. For example the Menu and MenuItem controls (preview) do not support keyboard accelerators (shortcuts), this is a known issue.
The tab ordering system used by JavaFX has been absolutely spot on, hence no manual intervention was needed, just layout nodes/controls correctly. What is missing is the ability to create custom dialogs. Currently too much unnecessary work is being done in Cookery to make a Stage behave like a custom dialog with mixed results, ugh! One suggestion for the JavaFX team is to provide a public-init instance variable called dialog in the Stage class, which sets the Stage to behave like a dialog when set to true (default value is set to false).
In terms of application performance it runs reasonably quickly, although some long term testing will need to be done to see how the application copes with long term use (under some stress). Hopefully I will not encounter the dreaded OutOfMemoryError with binding like I did with the original development of Cookery using JavaFX 1.2.
Listed below are the issues I encountered with JavaFX, and some third party libraries:
Using custom list cells in a ListView causes it to be improperly displayed
With the custom ListCell display empty string(s) if the current item is null.
No standalone JavaFX runtime to distribute with the application
Possible workaround is to connect the application via JNLP to the Internet, provided the target PC has Internet access.
Stage does not have a function for requesting focus
Hide the Stage first, then make it visible in order for it to gain the focus (works on some OS's).
JavaFX does not have any basic support for concurrency
Delegate the concurrency to code written in Java. Only a workaround if you need just back-end concurrency done.
JavaFX does not have a table control (eg TableView)
Use XTableView control from JFXtras library.
JavaFX does not have a built in database API
Use Java's JDBC API and/or JavaFX Composer's Data Source library. Only a workaround for a desktop JavaFX application.
The text for the selected rows is not readable for XTableView
Customise the look of XTableView using its skin property (use an instance of XTableSkin class). Note that doing it in CSS doesn't work at the moment.
JavaFX does not support creating a custom dialog box
Use XDialog class from JFXtras library. Only a workaround if you don't mind creating a front-end application with an in-cohesive look and feel.
Conclusion
With Cookery at the beta stage there will still be some long term testing to do. Some issues occur long after an application is completed, so it pays to get the user to use it for a while before it is finished. That way you can avoid some major bugs from popping up unexpectedly by catching them before they appear in the finished product.
Despite the fact that I had run into a few issues with using JavaFX I was still able to continue with development on Cookery, without any major show stoppers. This concludes the JavaFX App Development series.
Can you provide any information about the trouble you're having with ListView/ListCell?
ReplyDeleteJonathan - With the ListView it displays "null" cells (non existing items) that shouldn't be displayed at all. These null cells are displayed with the text "null" after the existing items.
ReplyDeleteNull cells do not appear if a cell factory isn't being used in the ListView.
It sounds like your custom cell factory might not be correct - why not do something like I did in this post here:
ReplyDeletehttp://fxexperience.com/2010/06/javafx-checkboxtreeview/
Note I actually test for null and put an empty string in the cell in that case.
Your empty string method (for the ListCell) did the trick. Is it part of the ListView's design to allow null items (not selectable) to be displayed?
ReplyDeleteWhen you take over the cell factory you're taking over the rendering of all cells - empty or not. Null is a perfectly valid value to display, so we don't stop it, although we do block selection as we know it's not a populated row. Cell Factory creates a cell for every visible row in the ListView, so it's important to handle these edge cases.
ReplyDeleteYou can now update your post above regarding custom list cells :-)