1) Look and Feel: IMO it’s enough to build „native looking“ css based skins! That could be very quickly without complex technologies like CALayer etc.
2) After starting RoboVM JavaFX needs round about 10 seconds to start the simple list example on iPhone4. So it’s too long. I tried to use the preloaded class via property „-Djavafx.preloader“ but it doesn’t work, my preloaded class is not instantiated… Tobi Am 21.10.2013 um 21:48 schrieb Richard Bair <richard.b...@oracle.com>: >> 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
