I decided to give it a go at testing javafx in an android device. My android device might be considered a low end device, it’s a nexus 4 from LG. The result can be seen below in a video. The quality of the video isn’t the best, I had to scale down the quality because the video was occupying 2GB.
My conclusion is that java/javafx runs with a very good performance in a low end android device with a pretty decent start up time. There were just 2 problems with this test, the first was with a demo which tested multi touch but didn’t run with top notch responsiveness but that might be the demos fault and not an issue with javafx itself. The second problem were dialogs: they aren’t showing up well.
The demo toke about 6 seconds to start which is more than the standard android app but not too much.
And on to the video:
Going through JMetro I just remembered the Toggle Switch control that I have created. It reminded me that this should be in a control repository next to other controls, publicly available for anyone to grab. I think this is one of those controls that should be part of the java sdk, it’s very popular especially on touch based devices. For more information read my previous blog post on the Toggle Switch control.
I have heard more than once people saying why a new control, why not simply style the Checkbox to appear the same way as a Toggle Switch. I think Toggle Switch merits being its own control the same way the Radio Button and Checkbox aren’t just skins of the Toggle Button, besides being conceptually a different control a Checkbox has the indeterminate state which doesn’t make sense in a Toggle Switch. Toggle Switch are usually also animated which can’t be achieved by skinning. And finally creating a Toggle Switch control makes it easier for others to style the control in different ways via css (styling a Checkbox to look like a Toggle Switch is difficult and hacky) .
So I decided to submit this control to the ControlsFX project.
One of the pertinent feedbacks I’ve received from the project members was that the default skin should be inline with the Modena theme. And so I created a new css stylesheet that I think is inline with Modena and is the default look of the control (if you don’t override the default stylesheet):
ToggleSwitch – modena theme
This time the ListView which is called ListBox in the windows sdk:
ListView – light theme
ListView – dark theme
If you are using JMetro please send me pics of your applications.
This time the Choice Box. Another control that’s not part of the windows framework (XAML UI Framework).
ChoiceBox – light theme
ChoiceBox – dark theme
Update: The check mark that appears in the ChoiceBox popup has been changed.
This time the DatePicker gets the jmetro treatment. Another control that is not part of the windows framework (XAML UI Framework) at least not in the form JavaFX presents it.
Here are the screen captures:
DatePicker – light theme
DatePicker – dark theme
As always you can get this at: https://github.com/JFXtras/jfxtras-styles
It’s been a while since I’ve worked on JMetro.
This time a control that’s not part of the windows framework: the spinner.
I opted to style the control in its STYLE_CLASS_SPLIT_ARROWS_HORIZONTAL style, that is horizontal arrows split between left and right sides. To style the control you need to add the style you want to the StyleClass observable list:
the other possible styles are:
And here are the controls in their light and dark theme:
Spinner – light theme
Spinner – dark theme
As always you can get this at jfxtras.
Java 8u40 is a small release but never the less has some interesting improvements:
Text entry control that displays formatted text such as phone number, date etc. Restricts input to a certain format and can also be used for validation of user input to a certain format. Kind of like JFormattedTextfield in Swing.
This as seen much debate from the community regarding its API. For more details on the final API read this blog post: http://code.makery.ch/blog/javafx-dialogs-official/
More details can be viewed here: https://wiki.openjdk.java.net/pages/viewpage.action?pageId=15368236
- Accessibility support
- Java Packager improvements
Another news is that since 8u33 ARM will no longer be officially supported. This happened because:
“This is a resource trade off within Oracle. Included in that difficult
trade off decision was the ongoing investment needed to properly support
FX in a world where so much the hardware is not standardized — it
really is difficult to have enough hardware and testing resources
committed to support FX on ARM”
Hopefully this support will unofficially continue in JavaFX Ports.
Java8u40 is scheduled to hit G.A. by early March.