+1 for native keyboard support. Unless you want to emulate the dictation feature in iOS and all that kind of stuff, you pretty much have to use the native keyboard.
But I think native widgets in general could be postponed, so long as JNI could be used to implement settings and the sort of thing that would be expected to have a lot of "standard" controls. Often in the main part of the app on iOS the UI is very customized anyway. I do ship a commercial app with Swing and the Windows LnF and except for the file dialog, nobody cared. Scott On Tue, Oct 22, 2013 at 5:20 PM, Felix Bembrick <felix.bembr...@gmail.com>wrote: > Well I guess I am in the "once bitten, a thousand times shy" category after > my experiences with Swing over the years. > > As I have mentioned in my blog posts, I believe the "native" look-and-feels > for Swing were a monumental mistake. The first version of the Swing > Windows look-and-feel for example left most people a bit gun shy because it > was just so blatantly obviously different from the native OS and even now I > don't feel that this look-and-feel is something I would ever want to use in > an application I sold commercially. The problem is that is eerily similar > to the native UI but sufficiently different to give the user a very uneasy > feeling. It still makes a Swing application look like an imposter. > > One of the most notable issues was when Windows Vista arrived. Prior to > then it was fairly easy to render a Windows progress bar in Swing but with > Vista came an animated green progress bar that was never properly > implemented in Swing. The problems across all controls worsened with > Windows 7 and are now at their peak with Windows 8. > > The fact that Swing supports pluggable look and feels (PLAFs) is absolutely > awesome and was quite revolutionary but to extrapolate that concept into > making a native look and feel one of those was a huge mistake. The > cross-platform PLAFs like Nimbus and even more so Substance that did not at > all try to resemble any native UI were by far the best PLAFS to use. > > So I don't want to see all this repeated with JavaFX. Trust me, > mobile/tablet users *will* spot the differences between a native app and a > JavaFX app and they *will* be affected by this (especially Apple users). > Steve Jobs would never have allowed this to happen and quite rightly so. > > So for mine, there are only two possible ways forward. > > 1. Use lightweight JavaFX controls exclusively. This is akin to Nimbus or > Substance as a Swing PLAF. Then it's quite clear that the app is not > trying to impersonate a native app and there is endless flexibility in the > way the controls look and behave. The downside of course is that there can > be no native controls used but it may still be possible to integrate the > non-visual aspects of native controls like I mentioned earlier. > > 2. Implement the "layering" scheme where true native components are mixed > with JavaFX controls. The advantage is that it will look and behave > exactly like a native app with the added benefit that comes from the > addition of lightweight controls. > > Option 1 is the most likely solution and is much easier to implement than > option 2. Option 1 is limited in that it wouldn't be possible to utilise > any native control rendering which would limit the types of native controls > that could be used (iAds for example would be a no go). Option 2 is > limited in that the native controls would be rendered by the OS and then > the entire solution is limited by the range of transformations supported by > the OS and also the degree of visual customisation available. > > I would really hope we can make Option 2 happen but Option 1 would be a > perfectly acceptable way forward as well. > > FYI, here's my 6 Degrees post: > > http://justmy2bits.com/2013/09/30/javafx-on-ios-and-android-six-degrees-of-separation/ > > Felix > > > > > > On 23 October 2013 07:51, David Ray <cognitionmiss...@gmail.com> wrote: > > > I think you may be facing an "absolute" requirement which is placing > > demands on you to > > replicate the exact look and feel of one or both mobile environments? I'm > > not sure?? > > > > > 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 do not see the problem with the above? Yes, the controls in > > question would maybe > > act differently than their native counterparts and Yes there may not be > > the exact complement > > of controls each native platform has, but my reaction to that is… so > what? > > The fact is, > > these controls are born of a different gui toolkit. This only is a > problem > > if one has it "stuck" > > in their head that JavaFX has to behave <em> exactly </em> like the > native > > platform - > > I don't see why this is necessary, especially when the variations are > > minor behavioral > > aspects anyway? The CSS skinning in my opinion is to most closely > > approximate the native > > look and feel IMO. I just don't see why it is necessary to reproduce the > > iOS toolkit or the Android > > toolkit in JavaFX? > > > > This to me is a way to ensure rigidity and lack of movement. As long > > as what *does* exist > > is rock-solid, dependable and very close looking - then I say good > enough. > > Otherwise, why not just use > > Objective-C or Android?? It is way better to have vertical movement and > > obvious progress, IMO. > > > > I did find the link to your "6 - degrees…" publication - and I vow to > read > > it in case my opinion comes > > down on the "misguided" side of things, but I just don't see the need for > > such a tight constraint??? > > > > Regards, > > David > > > > > > > > On Oct 22, 2013, at 3:26 PM, Felix Bembrick <felix.bembr...@gmail.com> > > 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. Then there's the issue that every time the OS changes and the > > > behaviour or appearance of those native controls changes, the author of > > > those JavaFX controls has to react accordingly. > > > > > > The issue of keyboard type and layouts is mentioned in my 6 Degrees of > > > Separation post and is critical. There's just no way we are going to > get > > > away with any kind of text control that does not support all the native > > > features of entering text on mobiles and tablets. Whether we place a > > > borderless native text box inside a JavaFX shape or just integrate the > > > native control itself, this is one of the most important features for a > > > JavaFX app and one where it would fail spectacularly if this native > > support > > > was not in place. > > > > > > I know some excellent work has been done on OS skins like AquaFX but > > > appearance is only half the challenge. As I said, it's the behaviour > > that > > > will kill us. To attempt to emulate all native control behaviour in > > > lightweight controls is not only nearly impossible but in my view it's > a > > > massive waste of effort if it is somehow possible to integrate the > actual > > > native control itself. I am hopeful that the "layering" paradigm will > > > gives us this. > > > > > > Another issue though is that native controls are unlikely to be as > > > "skinnable" as JavaFX controls and are probably more limited in the > scope > > > of the customisation of their appearance. Integrating native controls > > may > > > then impose limitations on the richness of the interface as it mandate > an > > > LCD approach so that the native controls don't look out of place. > > > > > > To me, the ideal solution would be to just extract/integrate the > > non-visual > > > aspects of native controls (such as the auto-complete, keyboard > > > customisations, other behaviour etc.) and then render them with the > > JavaFX > > > API/scenegraph. > > > > > > > > > On 23 October 2013 05:22, Stefan Fuchs <snfu...@gmx.de> wrote: > > > > > >> Hi Richard, > > >> > > >> I currently try to release updates of the jfx78 back port in 1-3 days > > >> after https://bitbucket.org/**openjfxmirrors/openjfx-8-**master-rt< > > https://bitbucket.org/openjfxmirrors/openjfx-8-master-rt>(from whereever > > this comes from) has been updated (usually every Friday). > > >> This obviously depends on the number of changes required and my > > available > > >> time. > > >> > > >> Stefan > > >> > > >> > > >> 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… > > >>>> > > >>> What is the state of the jfx78 back port, and how often is it > updated? > > >>> I'm wondering what the time is for getting a fix put in before it > > shows up > > >>> in the back port. > > >>> > > >>> Richard > > >>> > > >> > > >> > > > > >
