Re: JavaFX on iOS and Android - are we there yet?
Yes, definitely. On Oct 23, 2013, at 11:52 AM, Scott Palmer swpal...@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.b...@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.bembr...@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.northo...@oracle.comwrote: 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
Re: JavaFX on iOS and Android - are we there yet?
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
Re: JavaFX on iOS and Android - are we there yet?
+1 re: Native LF. 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
Re: JavaFX on iOS and Android - are we there yet?
Another approach which would be a *lot* easier to implement would be to add a Layer public API that would allow the app developer to specify what layers there are, and where they are (this has a lot of other benefits related to performance on embedded and mobile devices). Then, don't solve the heavyweight / lightweight issue, but allow heavyweight native controls to be added wherever. Then you just be careful not to have any lightweights on the same layer as a heavyweight if they might overlap above the heavyweight. Of course, you have this API already today in the form of SubScene! I haven't tried it in this context though. Richard On Oct 22, 2013, at 6:21 AM, David Ray cognitionmiss...@gmail.com wrote: +1 re: Native LF. 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.
Re: JavaFX on iOS and Android - are we there yet?
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. Generally this should be very easy for somebody to do. There is a ui kit already out there that designers use for mocking up UI designs for both the new iOS7 look and the previous looks. Should be straight forward to take and turn into an image based CSS theme. 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
Re: JavaFX on iOS and Android - are we there yet?
I would avoid image based CSS files… we should create pure CSS based skins using pure css styles and SVG paths… That would definitely be (a lot) more work, but if you're going to be scaling up the controls you will appreciate them being normal background fills paths. Richard
Re: JavaFX on iOS and Android - are we there yet?
javafx, like for instance: a toggle button (a control that looks like a flip switch) These have are just styled CheckBoxes (or Toggle buttons, or Radio Buttons). We've done this for example for DukePad. , comboboxes where you change the value through a wheel, etc.. Yes, need this kind of integration. and in having controls that have the necessary properties so that they can be touchable. Should already work. Richard
Re: JavaFX on iOS and Android - are we there yet?
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-rthttps://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
Re: JavaFX on iOS and Android - are we there yet?
Ok, I have read your 6 Degrees… publication, and I have to say I agree wholeheartedly with points 2 - 6. I just don't see why 90% of the common set of gui widgets, rock solid dependability and performance isn't good enough? Maybe others disagree I don't know… but if it comes down to being an engineering nightmare or so complex that the dependability or upgradeability is not there, then I just don't see it as important enough to warrant the abandonment of the effort? Regards, David On Oct 22, 2013, at 3:51 PM, 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
Re: JavaFX on iOS and Android - are we there yet?
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 -
Re: JavaFX on iOS and Android - are we there yet?
Yeah, the Swing file dialog is quite embarrassing... I accept that you can ship commercial software using the Swing Windows look and feel but only to certain types of customers and certain market niches. I do not believe you could compete with native applications in a more generic market sector though so I do not feel it is viable for most software houses. And that's what I am talking about here. Sure, we can get JavaFX for iOS and Android out the door and sure we can build pretty nice apps. But I want to be able to compete with the big boys and sell *serious, high-quality commercial software*. My dream is that JavaFX will enable me to do that. On 23 October 2013 08:44, Scott Palmer swpal...@gmail.com wrote: +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
Re: JavaFX on iOS and Android - are we there yet?
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, -- Pedro Duque Vieira
Re: JavaFX on iOS and Android - are we there yet?
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,
Re: JavaFX on iOS and Android - are we there yet?
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.northo...@oracle.comwrote: 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,
Re: JavaFX on iOS and Android - are we there yet?
On Oct 22, 2013, at 9:38 AM, Pedro Duque Vieira pedro.duquevie...@gmail.com wrote: These have are just styled CheckBoxes (or Toggle buttons, or Radio Buttons). We've done this for example for DukePad. Yes that's right but I think that as it is used so much on Android, ios and windows 8 it should have a control representation. For instance the same can be said of checkbox, you can make one out of a styled toggle button but as it is used so much it merits being a control. This is true. From a class count perspective (and embedded) it probably would have been better for us not to do CheckBox and RadioButton, but just do ToggleButton with some static final ints for doing the styling. But then again, maybe not. and in having controls that have the necessary properties so that they can be touchable. I'm talking about having the appropriate size for instance for you to touch it. You can't use Modena straight out for a mobile app. Perhaps having a Modena spinoff that has touch in mind. This is something worth thinking about. I noticed the fonts weren't the right size, implying that the port on iOS isn't picking up the best font size, and all the UI controls are sized based on the font, so in theory this might be sufficient. But it is true a spin-off with bigger insets might be necessary (but it isn't clear to me at least that this will be needed). What about input controls that popup the ios keyboard for entering text. Is this already available? If not how can these be achieved. Also we should keep in mind that the keyboard has to change in accordance to what the user has to enter: address, number, email, etc.. Yes, we already show the native keyboard. One mechanism we've discussed for input methods is to have some attributes you can add to a TextInputControl's properties map, which can then be used to show the right keyboard UI. Richard
Re: JavaFX on iOS and Android - are we there yet?
This is something worth thinking about. I noticed the fonts weren't the right size, implying that the port on iOS isn't picking up the best font size, and all the UI controls are sized based on the font, so in theory this might be sufficient. But it is true a spin-off with bigger insets might be necessary (but it isn't clear to me at least that this will be needed). I don't think basing the controls size on the font used is the best solution, at least for embeded/mobile. The design guidelines for each platform mention a min size a control should have so that your finger is able to touch it and there is no way 2 controls side by side can be mistakenly touched. This differs from platform to platform as each as its own studies on the size a control should have for you to easily touch it with a finger. So this is based on studies which are in turn based on peoples finger sizes. Yes, we already show the native keyboard. One mechanism we've discussed for input methods is to have some attributes you can add to a TextInputControl's properties map, which can then be used to show the right keyboard UI. Cool!! That's kind of the way you do it in HTML5: you add an attribute saying which type of text is going to be entered on the input field. Thanks, best regards, On Wed, Oct 23, 2013 at 12:35 AM, Richard Bair richard.b...@oracle.comwrote: On Oct 22, 2013, at 9:38 AM, Pedro Duque Vieira pedro.duquevie...@gmail.com wrote: These have are just styled CheckBoxes (or Toggle buttons, or Radio Buttons). We've done this for example for DukePad. Yes that's right but I think that as it is used so much on Android, ios and windows 8 it should have a control representation. For instance the same can be said of checkbox, you can make one out of a styled toggle button but as it is used so much it merits being a control. This is true. From a class count perspective (and embedded) it probably would have been better for us not to do CheckBox and RadioButton, but just do ToggleButton with some static final ints for doing the styling. But then again, maybe not. and in having controls that have the necessary properties so that they can be touchable. I'm talking about having the appropriate size for instance for you to touch it. You can't use Modena straight out for a mobile app. Perhaps having a Modena spinoff that has touch in mind. This is something worth thinking about. I noticed the fonts weren't the right size, implying that the port on iOS isn't picking up the best font size, and all the UI controls are sized based on the font, so in theory this might be sufficient. But it is true a spin-off with bigger insets might be necessary (but it isn't clear to me at least that this will be needed). What about input controls that popup the ios keyboard for entering text. Is this already available? If not how can these be achieved. Also we should keep in mind that the keyboard has to change in accordance to what the user has to enter: address, number, email, etc.. Yes, we already show the native keyboard. One mechanism we've discussed for input methods is to have some attributes you can add to a TextInputControl's properties map, which can then be used to show the right keyboard UI. Richard -- Pedro Duque Vieira
JavaFX on iOS and Android - are we there yet?
Hi Richard, Undoubtedly you are aware of the buzz and confusion regarding possible porting of JavaFX to iOS and Android and in an effort to calm the masses and give us all a little hope, would you be kind enough to provide definitive answers to the following questions? 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? 2. Are the iOS and Android ports at roughly the same level of completeness/viability? 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 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. Thanks, Felix
RE: JavaFX on iOS and Android - are we there yet?
Hi Felix, I think you can just forget any official statement from Oracle on this. It's not their way of working. And there appears to be some legal issues that made Oracle cancel the javafx sessions on ios and android at javaone. The javafx team is indeed working on this however no official statements about this work are coming out. I believe Oracle should get some info out unofficially, perhaps by accidentally putting some articles on the openjfx wiki, or somewhere else :-). It would be nice to know what's missing and where can the community help to speed things up. Thanks, best regards, Hi Richard, Undoubtedly you are aware of the buzz and confusion regarding possible porting of JavaFX to iOS and Android and in an effort to calm the masses and give us all a little hope, would you be kind enough to provide definitive answers to the following questions? 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? 2. Are the iOS and Android ports at roughly the same level of completeness/viability? 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 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. Thanks, Felix -- Pedro Duque Vieira
Re: JavaFX on iOS and Android - are we there yet?
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
Re: JavaFX on iOS and Android - are we there yet?
Personally I feel we *have* to go with the layering approach as I don't believe look-and-feel emulation will ever give a true native experience (as outlined in my 6 Degrees post). Has *any* work been done on this layering? No there hasn't been. Are there other products on iOS for example that utilise a similar layering approach that we might be able to learn from? Maybe on other platforms? The idea is used by Safari for handling web + plugin mixing, which is a similar problem. Is any work being done on the graphics performance issues at the moment or is everyone tied up with getting JFX8 out the door? Pretty much all hands on deck for JDK 8. I am willing to get involved with this layering development once I get my soon-to-be-released new MacPro ;-) One thing you could start with is to get some bounds on the problem. Create a stock-n-standard Cocoa app and create as many CALayers as you can, and just see what happens to performance. This will give you some idea of how many native controls you could mix in. You might be able to do something like this as well: given GridPane with 20 controls followed by some more scene graph nodes, you could analyze the graph and notice that instead of 22 layers here (one behind, 20 controls, one above) you can get away with 3 since all the natives are on the same level. Its more complicated, but if you find that you cannot have more than a handful of layers and keep performance up, its your best bet. Also, it would be worth looking at the other guys (like MonoTouch). I think they all fall in one of two camps: emulation, or thin-layer over native. We're proposing a combination of the two here, which might be unchartered territory on iOS. Richard
