JavaFX on iOS and Android - are we there yet?

[Richard Bair]

To do this we need to either solve the auto-layer problem in the NG nodes / Glass / Quantum, or we need to ask the app developer to use SubScene and put all the native stuff in a single SubScene, and all lightweight content above and below it. For the short term, we could use the SubScene approach ("Just be careful and don't draw lightweight on top of heavyweights unless you layer an entire sub scene above them") which is probably a perfectly workable solution in the short term. Then somebody just needs to write a set of skins (which can be done in an external project) that map various UI controls directly to native controls. This approach would allow people to have completely native controls while using the FX API, or they can use the lightweight controls (with Modena or with an iOS 7 skin or iOS 6 skin etc).

I'm thinking about how to implement the auto-layer, and I'm not sure of the best approach. It seems like you need to hook into the sync-time to determine which nodes can be batched into the same layer, reusing previous layers where possible. If there is a way to then setup the NG peer side so that it thinks it was setup in sub scenes etc, although it really wasn't, then that would leave prism out of the problem (which makes this an easier thing to pull off). hmmm. SubScene itself has a peer. So what I'm thinking is, suppose I have a package:

com.sun.javafx.ext.ios.controls

and in this package you have all the skins. There is also someplace in here a map of skin -> sub scene peer, indicating which of the nodes is in which sub scene peer ("layer"). Then when the sync takes place, a skin node looks back at siblings etc to determine if it can be placed in the same layer as something before it. If so, then it sets itself as a child on the sub scene as needed. If not, then it creates a new sub scene peer and sets itself on there and then carry on. So then it isn't sync'd to the "real" scene but instead to one of these fake sub scenes that was created.

The idea can be refined, but actually I think this approach might be workable for doing auto-layering.

Richard

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

> Yes, having viable implementations of both options would be ideal.
> 
> How long till Oracle and/or the community gets to that point? ;-)
> 
> 
> On 23 October 2013 10:06, Stephen F Northover
> <steve.x.northover at oracle.com>wrote:
> 
>> Rather than arguing this point, the correct answer is to provide both and
>> let the application developer choose.
>> 
>> Do you guys know how old this argument is?  Hint: It predates Java.
>> 
>> Steve
>> 
>> 
>> On 2013-10-22 6:17 PM, Pedro Duque Vieira 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.
>>>> 
>>> 
>>> I don't think this is exactly this straight forward. Ideally you would
>>> want
>>> to have this kind of native behavior on every platform. But having this
>>> native behavior involves having a different version of your app for each
>>> OS
>>> you want to deploy in, which might not be what the developers want.
>>> Remember JavaFX is a cross platform development kit and the major reason a
>>> developer would choose JavaFX over doing native mobile development is that
>>> his app can run on a variety of mobile platforms: windows 8, ipad,
>>> android,
>>> iPhone, etc with the same code base and *MOST* importantly with much less
>>> development time than building an app for each platform.
>>> For the sake of development time an app that doesn't go against any of the
>>> different platforms UX but that has the least common denominator so that
>>> each user in each different platform understands the UI might be a better
>>> solution for the sake of development time. One such example is the back
>>> button that appears when you drill down a list on an ios app but doesn't
>>> appear in an android app because every android phone as a physical back
>>> button.
>>> 
>>> I do agree with you that there are some places where a native looking
>>> control is ideal and doesn't involve any extra effort from the developer
>>> to
>>> customize it for the given platform like for instance comboboxs where a
>>> kind of wheel appears where the user can choose an option, or input
>>> controls where the native keyboard pops up.
>>> 
>>> Thanks, best regards,
>>> 
>>> 
>>> 
>>