- Create Test Case for a JavaFX source file (found in file's popup menu)
- Create Model Validator for a JavaFX source file (found in file's popup menu)
- Wizards for creating custom Lookups, App Controllers, Blocks, and Test Runners (for running Unit Tests)
29 June 2010
JFX Blocks Plugin 0.2 For NB Released
JFX Blocks Plugin 0.2 for NetBeans has been released on Kenai. Here is the list of features for this plugin:
27 June 2010
Possible Areas For JavaFX
Now is the time for JavaFX to expand into other areas. Many of you will already have some ideas as to which areas JavaFX should head into next. Listed below are some some possible areas for JavaFX to head into next:
Android Support
By far this is one of the most requested ideas, JavaFX providing support for Android with a runtime. Android has become one of the fastest growing mobile platforms, which is quickly creating a potential opportunity for JavaFX to thrive on the mobile scene provided Oracle seize the opportunity. Google would certainly welcome the opportunity to support JavaFX as another viable option for Android development. The ball is clearly now in Oracle's court on this one.
If Oracle are really listening to the Java/JavaFX community then a JavaFX runtime for Android will be made publicly available on the official JavaFX website, to install onto Android devices. On the JavaFX website it appears as though a runtime may be available for Android. In the JavaFX FAQ the following section adds to the mystery, “2.5 Can JavaFX applications run on an Android handset?”. There is nothing to confirm or deny if there is a JavaFX runtime available for Android at this stage.
What I would also like to add which no one else seems to have discussed in the blog sphere is JavaFX providing access to some of the Android APIs. After all the JavaFX architecture (on the mobile side) has been designed to be completely platform independent, thus it should be possible for the JavaFX runtime to have access to major platforms other than Java.
Built-in Database APIs
Already I have covered this in a previous blog post but have mentioned this since it is an important area not to neglect. Most applications that are developed will have some access to a database in one form or another. With JavaFX it really needs built-in database APIs, not mere wrappers. Surely this would be a great opportunity for JavaFX to innovate in this space. If Oracle wishes to prove that it is firmly committed to JavaFX then this is a great opportunity to show it.
Full 3D Support
Currently JavaFX has partial support in this area. I firmly believe that the area of Graphics has always been a real strength with JavaFX. It would be common sense for JavaFX to have full 3D support. Again this is a possible area that JavaFX can innovate in, and with the arrival of Prism we may see this come to fruition in the next JavaFX release.
Basic Multi-threading Support
More and more cases are being covered where there is a great need for built-in multi-threading support. Especially on the front end side which is JavaFX's domain. Multi-threading support only needs to be basic since back-end processing in not really JavaFX's focus. A real focus on the front-end should be made here as opposed to the back-end.
Low Level Media Manipulation
Plenty of JavaFX applications do low level manipulation of media, but have to use the Java APIs. Some of these applications include Indaba Console, Blue Bill mobile, JPedalFX, MetaMaps, PiriMap, and TimeShot. Why not have JavaFX provide low level media manipulation APIs (with graphics, video, and audio)?
What this means is not only creating the media but changing it as well. This is an interesting area that has not been fully exploited by the other RIA platforms. If JavaFX really wants to stand out from the crowd in a useful way then this would be the area to target in order to get ahead.
Android Support
By far this is one of the most requested ideas, JavaFX providing support for Android with a runtime. Android has become one of the fastest growing mobile platforms, which is quickly creating a potential opportunity for JavaFX to thrive on the mobile scene provided Oracle seize the opportunity. Google would certainly welcome the opportunity to support JavaFX as another viable option for Android development. The ball is clearly now in Oracle's court on this one.
If Oracle are really listening to the Java/JavaFX community then a JavaFX runtime for Android will be made publicly available on the official JavaFX website, to install onto Android devices. On the JavaFX website it appears as though a runtime may be available for Android. In the JavaFX FAQ the following section adds to the mystery, “2.5 Can JavaFX applications run on an Android handset?”. There is nothing to confirm or deny if there is a JavaFX runtime available for Android at this stage.
What I would also like to add which no one else seems to have discussed in the blog sphere is JavaFX providing access to some of the Android APIs. After all the JavaFX architecture (on the mobile side) has been designed to be completely platform independent, thus it should be possible for the JavaFX runtime to have access to major platforms other than Java.
Built-in Database APIs
Already I have covered this in a previous blog post but have mentioned this since it is an important area not to neglect. Most applications that are developed will have some access to a database in one form or another. With JavaFX it really needs built-in database APIs, not mere wrappers. Surely this would be a great opportunity for JavaFX to innovate in this space. If Oracle wishes to prove that it is firmly committed to JavaFX then this is a great opportunity to show it.
Full 3D Support
Currently JavaFX has partial support in this area. I firmly believe that the area of Graphics has always been a real strength with JavaFX. It would be common sense for JavaFX to have full 3D support. Again this is a possible area that JavaFX can innovate in, and with the arrival of Prism we may see this come to fruition in the next JavaFX release.
Basic Multi-threading Support
More and more cases are being covered where there is a great need for built-in multi-threading support. Especially on the front end side which is JavaFX's domain. Multi-threading support only needs to be basic since back-end processing in not really JavaFX's focus. A real focus on the front-end should be made here as opposed to the back-end.
Low Level Media Manipulation
Plenty of JavaFX applications do low level manipulation of media, but have to use the Java APIs. Some of these applications include Indaba Console, Blue Bill mobile, JPedalFX, MetaMaps, PiriMap, and TimeShot. Why not have JavaFX provide low level media manipulation APIs (with graphics, video, and audio)?
What this means is not only creating the media but changing it as well. This is an interesting area that has not been fully exploited by the other RIA platforms. If JavaFX really wants to stand out from the crowd in a useful way then this would be the area to target in order to get ahead.
15 June 2010
JavaFX App Development Part 2
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.
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.
06 June 2010
JavaFX App Development Part 1
Currently I am developing a JavaFX application for handling cooking recipes called Cookery. Part 1 will cover my development experiences using the JavaFX Composer in NB 6.9 RC1. Previously I had written Cookery entirely using the NB code editor and JavaFX 1.2. Unfortunately I had encountered some show stopper performance issues (with data binding) during testing, which meant I could not make any further progress with the application. This time around Cookery is undergoing a complete rewrite from scratch using JavaFX 1.3.
Since I had developed Cookery previously I had some rough screen designs on paper. Using the Composer I was able to design screens that were close to what I had on paper. Unfortunately the Composer does not yet support custom controls/classes/nodes, which meant containers had to be used during layout to hold the custom controls, thus no accurate visual feedback. On the plus side I was able to setup the layout for each screen quickly and easily.
The Composer organises control properties in a sensible way that is easily accessible. I like that fact that all commonly used properties for the selected control is presented in the top area of the Properties window. Not all properties are available in the Properties window, of particular mention is the read only properties which do not appear at all. Strangely enough there is still to way to visually manipulate the properties for the Stage (eg set the title), and properties are not sorted in ascending order for each category.
If you have ever used the previous version of the Composer you will no doubt have run into some major performance issues. Luckily with the current version it is much more responsive, and opens up design files much quicker. Also whenever a small change is made to a design file and you rerun the JavaFX project it is much quicker to build, this helped to boost productivity when the project was being built many times.
A major downside with using the Composer is the fact that it does not honour the user's formatting settings when it generates code. This slowed development down unnecessarily while I had to fix up the formatting. One major issue that is of major concern is the excessive amount of scanning that occurs whenever a change is made to a design file. This verges close to being a performance show stopper. Hopefully this issue is becoming priority number 1 with the Composer team, and will be fixed by the time the final version of NB 6.9 arrives. If necessary NB 6.9 should be delayed by about a week. It appears that the scanning issue is very common in other areas (eg JavaFX, PHP, Java).
On the positive side using the menu bar customiser proved to be a highly productive experience. Initially when I first used it I though it would not be as productive to use as Matisse's one (NB's Swing GUI builder). Who wants to manually type out the menu structure? However it proved to be the direct opposite, even saving me from manually renaming/positioning all menus/menu items. Also each menu can be customised individually without having to create the menu from scratch.
Another positive with using the Composer is that is generates very readable code that happens to be in a coding style that is very similar to my own. Any generated event handlers and binding functions/variables can be manually repositioned/changed on the fly. For handling data/state there is the Composer library which came in handy since I needed a general JavaFX database library for the application. There were two issues with the library which I was able to fix since all the source files are automatically created (for the first time only) in the project's src directory.
Listed below are the issues I encountered with the Composer and its library (most issues have workarounds):
Getting a value from a Record returns null
Ensure that the column name is correct and is in the correct case (eg in upper case).
Composer does not allow a custom control to be used visually in the Design Pane
Use a place holder Container (eg Group) in the control's place, and manually add the control to the Container.
Cannot directly resize Container's in the Design Pane
No workaround.
Cannot set any of the properties for the Stage (eg the title) in the Properties window
No workaround.
JDBC Data Source customiser does not handle a custom connection string
Change the connection property in the Properties window for the data source.
Sometimes the design file cannot be manually saved when a change is made
Close the design file and select the Save option when the dialog appears.
Excessive scrolling needs to be done with a design file in Design mode
No workaround.
Refactoring breaks when done in a design file (in Source mode)
Do manual refactoring without the assistance of the code editor's refactoring functions.
JavaFX Script code generated the Composer does not honour the user's formatting settings
Manually format the generated code.
DbDataSource returns a null RecordSet via getRecordSet function
Ensure all DbDataSource properties are correct. Also you may need to invoke the fetchData function before getting the RecordSet.
RecordSet returns null when using get(colName) function on a table column of type CLOB
Manually add code in the fetchData function (in DbDataSource) for retrieving CLOBs.
DbDataSource does not return the last insert ID used
Manually add code in DbDataSource to get the last insert id. Only a workaround if the chosen DB has a function that returns the last insert ID.
RecordSet does not have a specific function for retrieving a xxx type value from a column
Use the get function instead to retrieve the value and cast it to the specific type
Since I had developed Cookery previously I had some rough screen designs on paper. Using the Composer I was able to design screens that were close to what I had on paper. Unfortunately the Composer does not yet support custom controls/classes/nodes, which meant containers had to be used during layout to hold the custom controls, thus no accurate visual feedback. On the plus side I was able to setup the layout for each screen quickly and easily.
The Composer organises control properties in a sensible way that is easily accessible. I like that fact that all commonly used properties for the selected control is presented in the top area of the Properties window. Not all properties are available in the Properties window, of particular mention is the read only properties which do not appear at all. Strangely enough there is still to way to visually manipulate the properties for the Stage (eg set the title), and properties are not sorted in ascending order for each category.
If you have ever used the previous version of the Composer you will no doubt have run into some major performance issues. Luckily with the current version it is much more responsive, and opens up design files much quicker. Also whenever a small change is made to a design file and you rerun the JavaFX project it is much quicker to build, this helped to boost productivity when the project was being built many times.
A major downside with using the Composer is the fact that it does not honour the user's formatting settings when it generates code. This slowed development down unnecessarily while I had to fix up the formatting. One major issue that is of major concern is the excessive amount of scanning that occurs whenever a change is made to a design file. This verges close to being a performance show stopper. Hopefully this issue is becoming priority number 1 with the Composer team, and will be fixed by the time the final version of NB 6.9 arrives. If necessary NB 6.9 should be delayed by about a week. It appears that the scanning issue is very common in other areas (eg JavaFX, PHP, Java).
On the positive side using the menu bar customiser proved to be a highly productive experience. Initially when I first used it I though it would not be as productive to use as Matisse's one (NB's Swing GUI builder). Who wants to manually type out the menu structure? However it proved to be the direct opposite, even saving me from manually renaming/positioning all menus/menu items. Also each menu can be customised individually without having to create the menu from scratch.
Another positive with using the Composer is that is generates very readable code that happens to be in a coding style that is very similar to my own. Any generated event handlers and binding functions/variables can be manually repositioned/changed on the fly. For handling data/state there is the Composer library which came in handy since I needed a general JavaFX database library for the application. There were two issues with the library which I was able to fix since all the source files are automatically created (for the first time only) in the project's src directory.
Listed below are the issues I encountered with the Composer and its library (most issues have workarounds):
Getting a value from a Record returns null
Ensure that the column name is correct and is in the correct case (eg in upper case).
Composer does not allow a custom control to be used visually in the Design Pane
Use a place holder Container (eg Group) in the control's place, and manually add the control to the Container.
Cannot directly resize Container's in the Design Pane
No workaround.
Cannot set any of the properties for the Stage (eg the title) in the Properties window
No workaround.
JDBC Data Source customiser does not handle a custom connection string
Change the connection property in the Properties window for the data source.
Sometimes the design file cannot be manually saved when a change is made
Close the design file and select the Save option when the dialog appears.
Excessive scrolling needs to be done with a design file in Design mode
No workaround.
Refactoring breaks when done in a design file (in Source mode)
Do manual refactoring without the assistance of the code editor's refactoring functions.
JavaFX Script code generated the Composer does not honour the user's formatting settings
Manually format the generated code.
DbDataSource returns a null RecordSet via getRecordSet function
Ensure all DbDataSource properties are correct. Also you may need to invoke the fetchData function before getting the RecordSet.
RecordSet returns null when using get(colName) function on a table column of type CLOB
Manually add code in the fetchData function (in DbDataSource) for retrieving CLOBs.
DbDataSource does not return the last insert ID used
Manually add code in DbDataSource to get the last insert id. Only a workaround if the chosen DB has a function that returns the last insert ID.
RecordSet does not have a specific function for retrieving a xxx type value from a column
Use the get function instead to retrieve the value and cast it to the specific type
Subscribe to:
Posts (Atom)