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?
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.
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.
I am using the ListPicker from the toolkit. I have managed to apply a style template so that when the user is selecting from a list of items in fullscreen mode, it looks somewhat similar to the native WP7 implementation.
However, there are a few things missing that appear on the native implementation:
On full mode enter, the items appear via an animation
When at item is selected, it stays highlighted for an instant, then the items disappear via an animation
Am I missing something or is this simply just not exposed to 3rd party developers using silverlight at this point in time?
Animations are provided in November Toolkit. Download the latest version, please
Check the other posts in the same site .. http://www.windowsphonegeek.com/tips/how-to-customize-the-listpicker-selected-item
When running on a touchscreen device (iPhone, in my case, but I presume it does this on others), when the virtual keyboard pops up for a form field, there are added navigation buttons at the top of the keyboard: "previous", "next", "done". (And sometimes "autofill").
This is apparently the Mobile Safari "form assistant".
I find this redundant, superfluous, and confusing. iPhone users aren't used to this in native apps, and it's unnecessary. It's a touch device. You touch what you want to change. There's no need for navigation buttons!
I suppose users may be familiar with this, IF they use their device often to fill forms on websites. I've had an iPhone since the 3G, and never noticed this. I don't think I've ever filled a form on Mobile Safari! (I would use my desktop...)
The form assistant is there for navigating forms on websites, which might not be designed appropriately for a mobile device. So, in that context it serves a useful purpose.
But when using JQuery Mobile, you ARE designing an interface for use on a touchscreen mobile device. There shouldn't be a need for the form assistant. I find it particularly annoying in a local app (PhoneGap, Rhodes, etc.).
I've done some searches, and haven't come up with a solution.
Does anybody know how to turn this off?
sorry, its not possible to remove the Form Assistant inside mobile safari.
There is no solution for mobile Safari, but for PhoneGap there certainly is.
As of 2.6.0 there is an option in the config.xml
<preference name="HideKeyboardFormAccessoryBar" value="true" />
For versions before 2.6.0, or more sophisticated use, there is the KeyboardToolbarRemover, which even allows to dynamically show and hide the keyboardAcessoryView.
In your Javascript, include the module
var toolbar = cordova.require('cordova/plugin/keyboard_toolbar_remover');
To disable the toolbar
toolbar.hide()
To re-enable the toolbar
toolbar.show()
I am using the new BrowserField2 in BlackBerry OS5 to display HTML content in my app. There are 3 options available for navigation through links in that content.
CURSOR navigation uses a block cursor and actually moves through the characters of the page. Not very useful for me.
POINTER navigation uses a mouse like pointer that you move around the screen and hover over elements. This could work but there is a bug however in that the browser field captures navigation and never lets go so this mode is effectively broken if you share a screen with any other managers. Once your focus enters the browser field you cannot move focus back out and into neighboring fields. RIM has acknowledged the bug but has no work around.
NONE which is for custom navigation but they offer no explanation as to how you would do this.
What I ideally want is to simply have trackpad movements move the focus through the links and highlight them. Then a click would activate the link. I assume I would select the NONE option above and implement my own focus navigation but I am not clear how this can be accomplished with the new APIs.
Is anyone familiar with the new browser2 component could give some guidance?
Thanks!
There's a workaroudn to getting back the focus out of the BrowserField using the NAVIGATION_POINTER.
I found it in this thread:
http://supportforums.blackberry.com/t5/Java-Development/BrowserField-2-Navigation-Mode/td-p/632172
"farahh" posted this:
I found out a hack..
with the navigation set to pointer mode, a click outside the browserfield manager invokes Manager.invokeAction(int). I used the getFieldWithFocus to verify which field has focus and then switch the focus to something else.
Cheers.
Nahuel
PD: i havent found out how to get the behaviour you want, i need that as well so if you got it working please let me know, its kinda urgent in my project =(
I actually reverted back to the older browser1 (OS4) component because the navigation problems in browserField2 (OS5) were a deal breaker for me. Luckily the OS4 browser does everything I need in terms of functionality and it has the exact navigation behavior I need and there are no focus problems mixing it with other views.