JavaFX on iOS and Android - are we there yet?
felix.bembrick at gmail.com
Tue Oct 22 13:26:00 PDT 2013
Even the most fab skins or CSS is not going to get us away from the need to
integrate JavaFX controls with true native controls. As has been pointed
out, there are some native controls on both iOS and Android for which there
is no JavaFX equivalent and this will always be the case. Even if someone
were to develop near identical lightweight controls in JavaFX, they would
need to behave slightly differently on iOS than they do on Android and vice
versa. Then there's the issue that every time the OS changes and the
behaviour or appearance of those native controls changes, the author of
those JavaFX controls has to react accordingly.
The issue of keyboard type and layouts is mentioned in my 6 Degrees of
Separation post and is critical. There's just no way we are going to get
away with any kind of text control that does not support all the native
features of entering text on mobiles and tablets. Whether we place a
borderless native text box inside a JavaFX shape or just integrate the
native control itself, this is one of the most important features for a
JavaFX app and one where it would fail spectacularly if this native support
was not in place.
I know some excellent work has been done on OS skins like AquaFX but
appearance is only half the challenge. As I said, it's the behaviour that
will kill us. To attempt to emulate all native control behaviour in
lightweight controls is not only nearly impossible but in my view it's a
massive waste of effort if it is somehow possible to integrate the actual
native control itself. I am hopeful that the "layering" paradigm will
gives us this.
Another issue though is that native controls are unlikely to be as
"skinnable" as JavaFX controls and are probably more limited in the scope
of the customisation of their appearance. Integrating native controls may
then impose limitations on the richness of the interface as it mandate an
LCD approach so that the native controls don't look out of place.
To me, the ideal solution would be to just extract/integrate the non-visual
aspects of native controls (such as the auto-complete, keyboard
customisations, other behaviour etc.) and then render them with the JavaFX
On 23 October 2013 05:22, Stefan Fuchs <snfuchs at gmx.de> wrote:
> Hi Richard,
> I currently try to release updates of the jfx78 back port in 1-3 days
> after https://bitbucket.org/**openjfxmirrors/openjfx-8-**master-rt<https://bitbucket.org/openjfxmirrors/openjfx-8-master-rt>(from whereever this comes from) has been updated (usually every Friday).
> This obviously depends on the number of changes required and my available
> 2) After starting RoboVM JavaFX needs round about 10 seconds to start the
>>> simple list example on iPhone4. So it’s too long. I tried to use the
>>> preloaded class via property „-Djavafx.preloader“ but it doesn’t work, my
>>> preloaded class is not instantiated…
>> What is the state of the jfx78 back port, and how often is it updated?
>> I'm wondering what the time is for getting a fix put in before it shows up
>> in the back port.
More information about the openjfx-dev