JavaFX on iOS and Android: The real problem and challenge

[Felix Bembrick]

Much of what you are saying Tobi is absolutely true.

I have always said that it's simply not enough to have experimental or
"alpha" or "hobbyist" implementations of Java and JavaFX on those
platforms.  As I have stated in my blogs, we need a thoroughly professional
solution that is suitable for *serious commercial app development*.
 Anything less is a fail.  That was the motivation for my "6 Degrees" post.
 Even if one of those points is not satisfied then the port is not viable.

However, I disagree with your assertion that Oracle (or any big company)
needs to release the JVM and supporting classes/libraries themselves.
 While obviously this would be ideal, if we (the community) want this to
happen in a reasonable time frame then *we* have to make it happen or at
least contribute a lot of time and effort in support of making it happen.

To this end, we already have RoboVM.  As you have pointed out, RoboVM is
not "production ready" just yet and may indeed be a long way off that but
have you ever heard the saying "A bird in the hand is worth two in the
bush"?

Basically, RoboVM is here and now and, at least in part, seems to work
quite well.  Sure, it needs to be modified to remove the Dalvik library
dependencies and to support JDK8 but I have strong feeling that it's all we
are going to have for quite a long time and we might as well put the effort
into improving it.

So, my own feeling is that the JavaFX community is very vibrant and there
are a lot of cluey people out there and collectively we have the ability to
make RoboVM viable (6 Degrees wise).

We do not need to wait for Oracle and we shouldn't.  In fact, I am sure
that Oracle themselves (whatever they are actually working on) are taking a
very close look at RoboVM and possibly getting hints and pointers from it.
 It's no secret that JavaFX (and even Java) is not the most important
technology or product in Oracle's catalogue and I am sure the JavaFX team
is under-funded.

So why can't we the community and Oracle work together to make this happen?
 Maybe it would be better to pool our resources and focus all our energy on
a single unified solution?

Of course we would need Oracle to be a bit more cooperative and open but
who says that won't happen?

So basically I think the wonderful initiative that is RoboVM and the work
on it is not at all wasted and indeed will be a very valuable step toward
the ultimate goal.

Felix




On 24 October 2013 17:52, Tobias Bley <tobi at ultramixer.com> wrote:

> ups, I made one mistake:
>
> "So both solutions use the real Java platform (=OpenJDK)!“ should be "So
> both solutions does not use the real Java platform (=OpenJDK)!“ ;)
>
>
> Am 24.10.2013 um 08:41 schrieb Tobias Bley <tobi at ultramixer.com>:
>
> > Hello to the community,
> >
> > I read the last discussion about „JavaFX native look and feel“ and have
> to get out of my mind the following:
> >
> > In my opinion the MAIN point is not „how to bring the native look and
> feel to iOS/Android“, the real MAIN issue is: we need a professional JVM(!)
> which works performant and reliable on iOS, Android and Windows 8! Only if
> we have such a JVM, developers and companies are motivated to develop real
> commercial apps with JavaFX and contribute stuff back to OpenJFX!
> >
> > RoboVM is a good „prototype“. Niklas is currently one of the most
> important people for the JavaFX community. He and his company has build the
> first and one and only real solution to deploy Java and JavaFX code to the
> iOS platform! His work is really great! But: He is only one(!) person! This
> kind of complex task I would expect from big companies like Oracle, IBM,
> SAP or Twitter. But from this direction we don’t hear anything about it.
> >
> > It is not enough that people like Niklas (Trillian AB) or Matthias and
> me (UltraMixer) are trying to bring JavaFX to iOS and Android. It’s all
> experimental stuff! Yes, currently we can start JavaFX apps on a real
> iPhone and iPad. And yes, we have managed to start JavaFX on a real Android
> device using the Dalvik VM. BUT: this is not a long term solution and only
> experimental! RoboVM on iOS uses the android class library instead of the
> real Java = OpenJDK. Our „JavaFX on Android“ solution uses Google Dalvik VM
> and the Android class library as well! So both solutions use the real Java
> platform (=OpenJDK)!
> >
> > In my opinion there are only two solutions: 1) Oracle releases their JVM
> for iOS and Android. 2) The „community“ starts a new company who develops a
> professional, performant and reliable solution for „JavaFX on iOS and
> Android“ which contains of a JVM and the 6 degrees Felix described in his
> blog post, mainly native integration (API) and look and feel (skins, native
> controls).
> >
> > Cheers,
> > Tobi
> >
> >
> >
> > Am 23.10.2013 um 22:30 schrieb Richard Bair <richard.bair at oracle.com>:
> >
> >> Yes, definitely.
> >>
> >>> On Oct 23, 2013, at 11:52 AM, Scott Palmer <swpalmer at gmail.com> wrote:
> >>>
> >>> 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,
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>
> >
>
>