JavaFX on iOS and Android: The real problem and challenge

Sven Reimers sven.reimers at gmail.com
Thu Oct 24 04:27:10 PDT 2013 

So in case of VM  - what are we talking about?

a) Running a real JVM with JIT all the good stuff on iOS? (I can't see this
happening for official appstore apps)
b) Adding a possibility to OpenJDK to get AOT?

What is the aim?

-Sven



On Thu, Oct 24, 2013 at 11:29 AM, Felix Bembrick
<felix.bembrick at gmail.com>wrote:

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



-- 
Sven Reimers

* Senior Expert Software Architect
* NetBeans Dream Team Member: http://dreamteam.netbeans.org
* Community Leader  NetBeans: http://community.java.net/netbeans
                              Desktop Java:
http://community.java.net/javadesktop
* Duke's Choice Award Winner 2009
* Blog: http://nbguru.blogspot.com

* XING: https://www.xing.com/profile/Sven_Reimers8
* LinkedIn: http://www.linkedin.com/in/svenreimers

Join the NetBeans Groups:
* XING: http://www.xing.com/group-20148.82db20
* NUGM: http://haug-server.dyndns.org/display/NUGM/Home
* LinkedIn: http://www.linkedin.com/groups?gid=1860468
                   http://www.linkedin.com/groups?gid=107402
                   http://www.linkedin.com/groups?gid=1684717
* Oracle: https://mix.oracle.com/groups/18497

More information about the openjfx-dev mailing list