JavaFX on iOS and Android - are we there yet?

[Scott Palmer]

This is starting to sound like it may also partially address the issue in
the desktop space of supplying a native surface (the heavyweight) to draw
in that is part of the scene graph.  It may not be the ideal solution, but
could be useful for specific use cases, like a video preview overlay. Would
that make any sense?


Scott



On Tue, Oct 22, 2013 at 7:59 PM, Richard Bair <richard.bair at oracle.com>wrote:

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