JavaFX on iOS and Android: The real problem and challenge

Felix Bembrick felix.bembrick at gmail.com
Thu Oct 24 04:45:54 PDT 2013 

Probably a mix of a couple of things.  Mostly AOT with interpreting where
necessary.  No JIT possible on iOS.


On 24 October 2013 22:27, Sven Reimers <sven.reimers at gmail.com> wrote:

> 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