JavaFX on iOS and Android - are we there yet?

[David Ray]

I think you may be facing an "absolute" requirement which is placing demands on you to
replicate the exact look and feel of one or both mobile environments? I'm not sure??

> 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.


	I do not see the problem with the above? Yes, the controls in question would maybe
act differently than their native counterparts and Yes there may not be the exact complement
of controls each native platform has, but my reaction to that is… so what? The fact is, 
these controls are born of a different gui toolkit. This only is a problem if one has it "stuck"
in their head that JavaFX has to behave <em> exactly </em> like the native platform -
I don't see why this is necessary, especially when the variations are minor behavioral
aspects anyway? The CSS skinning in my opinion is to most closely approximate the native
look and feel IMO. I just don't see why it is necessary to reproduce the iOS toolkit or the Android 
toolkit in JavaFX? 

    This to me is a way to ensure rigidity and lack of movement. As long as what *does* exist
is rock-solid, dependable and very close looking - then I say good enough. Otherwise, why not just use
Objective-C or Android??  It is way better to have vertical movement and obvious progress, IMO.

I did find the link to your "6 - degrees…" publication - and I vow to read it in case my opinion comes
down on the "misguided" side of things, but I just don't see the need for such a tight constraint???

Regards,
David
 


On Oct 22, 2013, at 3:26 PM, Felix Bembrick <felix.bembrick at gmail.com> wrote:

> 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
> API/scenegraph.
> 
> 
> 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
>> time.
>> 
>> Stefan
>> 
>> 
>> 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.
>>> 
>>> Richard
>>> 
>> 
>>