> 1. Can you provide me with a detailed summary of where the iOS/Android
> ports are currently? This includes the platform specific stuff to make
> either RoboVM or an Oracle JVM work?
I would say, it is in a good prototype stage. It hasn't had heavy testing, so
the biggest risk is the unknown. Luckily, on iOS at least there are only a very
few devices so it should be relatively easy for an app developer to feel
confident it works for their app. But for the OpenJFX project, to test and
certify a whole variety of APIs, will be quite a challenge. We have a huge pile
of tests, we just need:
1) To have a way to run our unit tests on the actual devices
2) Have a way to run graphical tests on devices (basically a port of
Jemmy??)
I haven't scoped either of these efforts, but both are ripe areas for
collaboration with anybody in the community.
If it were heavily tested, I'd say most of the remaining work is actually in
the graphics / performance side. Path rendering performance is fairly bad
(though I've seen similar complaints for Cocoa path rendering performance, so
it may be we're not that "bad" relatively speaking, but it is still horrendous
IMO and needs to be looked at).
The code is all there for the integration layer -- anybody with familiarity
with Objective-C and Cocoa, I'd say, go read the glass code! This is a huge
opportunity for community initial community involvement because:
1) There is a ton of existing documentation and code in the Apple universe
describing all the sorts of things we need to do in Glass
2) Glass is pretty decoupled from the rest of the platform, so you can
easily understand what is going on there without having to understand
everything else
Contributing on the Graphics side is more work and requires more specialized
skills. The fortunate thing here is that the graphics code is shared with
embedded (and desktop Mac and Linux) so there is a lot of overlap.
So those would be the main things from my perspective: performance testing,
functional / unit testing, native platform integration, and graphics.
Another thing we've designed for from the beginning, but never validated, is
the ability to use a native control as the skin. The iOS prototype "hot swaps"
a native text field in when a TextInputControl gets focus, but this is kinda
funky (and there are lots of bugs here). The "right" thing to do here would be
to have a set of native skins for controls, and the ability to create multiple
core layers. So if you have a scene graph where on the bottom you draw stuff,
then have a native control, then draw more stuff over the native control, then
what you would want is, on the Prism side, use 3 hardware layers (one for below
the native, one for the native, and one for above the native). I don't know:
1) How well this would work in practice with input events (but one could
imagine putting a native 'glass pane' on the top to intercept all events and
vector them through FX, forwarding to native controls as necessary as part of
the normal FX event dispatch)
2) How many layers you could have before things would explode.
Alternatively, using image skinning to get the look right, and only do the
funky native control swap in for text input, like we're doing today.
> 2. Are the iOS and Android ports at roughly the same level of
> completeness/viability?
I think so, David / Tomas, can you guys add some insight as to where we're at
from your perspective?
> 3. Exactly what is left in making these ports viable? Here the word
> "viable" is defined in my 6 Degrees of Separation post here
> http://justmy2bits.com/2013/09/30/javafx-on-ios-and-android-six-degrees-of-separation
1. Their look and feel is indistinguishable from native apps
As described above, there is work to be done here either by beefing up the
emulation, or adding the ability to intersperse native controls. The latter
approach I expect to be significant work, although technically feasible.
Also, I expect people will want to add more iOS specific controls (like
breadcrumb bars) to make this easier to do (rather than everybody styling their
own).
2. They must load as quickly as a native apps
I've heard RoboVM starts up very quickly. Also you will package your app with a
splash screen. Also I believe the Preloader APIs work now with iOS (I haven't
tested on RoboVM but try it out and let me know if it works! You will probably
need to launch a bit differently, providing the preloader as a system property
I think). So I expect this to work reasonably well.
3. They must perform as well as a native apps once loaded
This is the open question. We may find the graphics to be the bottleneck, or we
may find that the CPU usage is the bottleneck. On the CPU side, one problem may
be the large number of method calls to set / get property values. Going to a
"full lazy" style for many properties on Node might help here, for instance.
4. They must be able to utilise all (or at least most) of the native APIs,
devices and features that native apps can utilize
I would say this is a given, since you can use JNI to invoke any API. However
if you want to embed a native widget in the app (such as iAd banners), then we
(as a community) need to solve the problem of embedding natives in the scene
graph (layers issue described above).
5. They must be as available as native apps and available from the same
channels (e.g. iOS app store)
I think this is a given (nothing to do here, except making whatever tweaks
Apple deems necessary)
6. They must be as easy to update as native apps and through the same channels
Again, this is a non-issue I think because if you can submit via the app store,
then you can update via the app store.
> I know it's a pain to have to attempt to pacify the mob but I am sure I
> speak on behalf of all JavaFX developers when I say that many of us have
> serious financial or personal investment in JavaFX and *need* to know that
> a mobile/tablet future is indeed possible.
Not a problem at all, it is important that we work together to make this a
reality. I'll spend the time necessary to help anybody who wants to get their
hands dirty with where to go in the code, how it works, and what needs to be
done!
Richard
