JavaFX on iOS and Android - are we there yet?

[David Ray]

Ok, I have read your "6 Degrees…" publication, and I have to say I agree wholeheartedly with points 
2 - 6. I just don't see why 90% of the common set of gui widgets, rock solid dependability and performance
isn't good enough? Maybe others disagree I don't know… but if it comes down to being an engineering nightmare
or so complex that the dependability or upgradeability is not there, then I just don't see it as important enough
to warrant the abandonment of the effort?

Regards,
David




On Oct 22, 2013, at 3:51 PM, David Ray <cognitionmission at gmail.com> wrote:

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