+1 on this. I don't see why having an exact copy of the look and feel of the OS has to be mandatory. You can see a lot of apps on ios that use controls that don't mimic the look and feel of the OS and yet look and feel great, in fact I would say the best looking apps are the ones that don't mimic the exact look and feel of the OS. There are even apps that go as far as not having any controls or looking way off the regular look of the OS and that are amongst the best looking apps.
That and the fact that there is a lot of criticism around the new look and feel presented on iOS 7 (lacking affordances, etc) makes this IMO a non issue. I think the real issue is in having controls that currently do not exist in javafx, like for instance: a toggle button (a control that looks like a flip switch), comboboxes where you change the value through a wheel, etc.. and in having controls that have the necessary properties so that they can be "touchable". Regards, > +1 re: Native L&F. IMO also there is nothing sacred about the "exactness" > of Apple's ui. They 'll be changing it up a lot a also. Being someone who > prefers custom looks to bland native looks anyway, I never did get the > "sacredness" of repeating "mirror-lookalike" grey :). Just my opinion, I'm > sure there are those who disagree. > David > Sent from my iPhone > > On Oct 22, 2013, at 7:17 AM, Tobias Bley <t...@ultramixer.com> wrote: > > > > 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 > > -- Pedro Duque Vieira
