Background/Context:
I am developing touch screen based kiosk application with JavaFX. The app integrates browser – WebView. The problem is that all user inputs have to be made through on screen keyboard (SW keyboard)
It would be nice to have an option to register an event-handler on WebView/WebEngine for any HTML text input element got/lost focus, so that I could show/hide on-screen-keyboard.
Even though I searched the Internet, I did not find this kind of feature.
My questions:
Does JavaFX / WebView provides any support for these cases?
If you were to tackle this problem, what would be your approach to that?
My solution so far:
I have a small button (at one corner of the screen) that allows user to show/hide on-screen-keyboard. Since they have to do that manually, it is quite annoying. Especially on sites where browsing (consuming information) and text inputs changes frequently.
It would be nice to have an option to register an event-handler on WebView/WebEngine for any HTML text input element got/lost focus, so that I could show/hide on-screen-keyboard.
A potential strategy for doing this:
Start with a jdk8 preview.
Run the application with -Dcom.sun.javafx.isEmbedded=true to enable the virtual keyboard.
Use a webengine.executeScript technique to embed jQuery into the target page.
Bind a jQuery focus handler to the relevant html elements.
In the jQuery focus handler make an Upcall from JavaScript to Java.
Upon receiving the upcall make use of JavaFX's Virtual Keyboard.
As the user enters values into the keyboard, make executeScript calls to set the value of the corresponding html field.
Some parts will likely be a bit (or totally) flaky, but perhaps other parts may prove useful to you.
In the future, if WebView is supported on touchscreen platforms on embedded devices, I'm guessing that out of the box it will work well with a virtual keyboard.
Related
I want to use the q-dialog for a form with about 20 inputs. But in the documentation it is told that it should only be used for small quick things.
From a UI perspective, you can think of Dialogs as a type of floating
modal, which covers only a portion of the screen. This means Dialogs
should only be used for quick user actions, like verifying a password,
getting a short App notification or selecting an option or options
quickly.
What should I use instead of Dialog for my modal forms ?
Quasar is a cross-platform framework. Its UI components are meant to be used for desktop and mobile devices. If you put a lot of child UI elements inside a Dialog on mobile devices, it won't fit in screen size and the whole idea of a dialog would fail. Thus, it's better if you make a dedicated view for your form with 20 inputs.
I am currently using input text fields that spawn a chooser (listview with various entries) when they are clicked on. Testing this on the appMobi emulator works flawlessly; however, when testing it on an iPhone, the default keyboard appears when the text fields are touched and then quickly disappears to be replaced by the chooser.
Is there a way I can prevent the default keyboard from showing with JQM?
If they require user input, then you can't prevent the browsers' default implementation (at least in a x-browser friendly way). They is certainly no solution with JQM.
I suggest you style your own text box from a div or similar, using html/css. With js you can then wire up the chooser to this element.
I'm aware of how to make invisible elements keyboard focusable and read by screenreaders, however for the purpose of a student-led survey - I would like certain elements to be invisible to screenreaders / keyboard focus to be less distracting, but have them visible for tutors to use using a mouse.
I've tried using iframes, however the keyboard can still 'tab' into them. I was considering a pop-up window that can control the parent window? - but might have some issues with blockers etc.
Many thanks! Mike
One of the simplest ways to get content ignored by a screen reader is to place it into an image and then set the alt text on the image to be "" in your HTML. This will cause the screen reader to skip this content since it can't interpret it. This will also eliminate any tabbing or keyboard focus since the web browser will treat it like any other image in your page.
Another way to do this, and a bit more complicated, is to detect if your page is being pulled into a screen reading browser and set the CSS properties of the content you don't want read by the reader to be have the following:
visibility: hidden; display:none;
Screen readers will ignore anything that is invisible and/or not displaying, thus it will not be read to the user. This is also a bit cleaner since you're not destroying the SEO ranking of the page but are just modifying the content displayed to users who don't need to see/hear it.
a good way to prevent screen readers from viewing an element is to apply the aria-hidden="true" attribute; this is fairly well supported by browsers, and will prompt JAWS and other screen readers to skip the content. You can also use role="presentation" - there's a good article on this here: http://john.foliot.ca/aria-hidden/
Applying tabindex=-1 will only only allow the element to be focused on by scripts and not keyboard input, so this will work too. Additionally, although I don't recommend it, I found while tearing my hair out over someone else's script, that if you don't have an 'href' attribute defined for a link element, (making it invalid) this also prevents focus.
For single form UI's the form assistant in the mobile safari virtual keyboard doesn't provide much value and reduces the useable space in the viewport. Is it possible to remove this section of the keyboard for forms that do not benefit from this?
In essence, you must wait till the keyboard responds and then forcibly grab and remove that top bar. It's not pretty and definitely not perfect but it is a starting place. I'll post the refinement of this process as I work on it myself.
Here is the question. I implemented this using Trigger.IO and native plugins but, naturally, you can ignore that and just run it on your UIWebView: How can I hide Form Assistant with iOS native plugins using Trigger.IO?
I am developing a blackberry application using j2me and LWUIT (blackberry port). Everything works great except for the TextField in numeric mode. Basically when you have focus on the TextField you have to first go into "NUMERIC" mode (by pressing alt + aA) in order to input, which is not user friendly and a problem.
The proposed solution is to use a TextArea instead that allows you to open a NATIVE type input box. The problem there is that the user needs to focus the field and then press the fire button which again is unfriendly.
Does anyone know of any simple solutions?
The few solutions i have in mind (but not sure how to do them):
1) Capture any keypress on the TextArea and go into NATIVE mode, instead of just the fire key.
2) Put the blackberry input mode into numeric using code for the whole form.
Any advice will be appreciated.
Many Thanks,
Paul
I'm not sure whether this solution is one that would appeal to your needs or not, but you could add j2me onKeyPress handling that "translates" the letter keypresses into the numbers that correspond to the same key and adds the "correct" number to the textfield instead of what the user actually pressed. Do keep in mind that such a solution would require you to worry portability issues as far as not all blackberry models using the same keyboard layout (qwerty vs. reduced qwerty for example) and handling the variation in layouts sufficiently.
Okay well to answer my own question.
I overrided the keyRelease method on a TextArea. And in this method if the keypress is not an arrow key i the call editString method (this causes the native textfield to open). The only downside to this is that it will always miss the first keypress in the text box.