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()
Related
i'm developing a simple three tabs app for Android and iPhone, using IBM Worklight as framework. Every tab links to a div with data-role="page", as jQuery Mobile specifications.
If I implement the jquery fixed persistent tabbar like is explained there (http://jquerymobile.com/demos/1.2.0/docs/toolbars/footer-persist-a.html), i'm encountering some flickering on the tab item in page transition (with any transiction effect).
If I set the default transition to "none", I could resolve this problem, but I lost the transiction native-like effect.
This behavior appears only if i test the App with a real android device (Xperia Neo, GS2).
If i navigate trough the pages of http://jquerymobile.com/demos/1.2.0/ with my smartphone, especially here: http://jquerymobile.com/demos/1.2.0/docs/toolbars/footer-persist-d.html i can't see the strange behavior, but the footer won't be persistent trough the pages, it just re-render like the whole content and this is worse (this happen with the stock browser or Dolphin, instead looks very well by using Chrome).
Is there a way to improve this effect or there is another way to implement fixed persistent tab bar?
I used as reference the default Android Contacts App.
Maybe you're getting this flicker because you're navigating between pages using rel="external". Try to pass from one page to the other without ajax and you'll see that flickering will dissapear
The problem is due to poor performance of the WebView of the Android environment in rendering 3d transition.
Solved by removing the transition effect with:
$.mobile.defaultPageTransition = "none";
Something else that could help is putting these attributes in the AndroidManifest.xml:
<supports-screens
android:anyDensity="true"
android:largeScreens="false"
android:normalScreens="true"
android:smallScreens="false"
android:xlargeScreens="false" />
<application
android:debuggable="false"
android:hardwareAccelerated="true"/>
I am building a cross-platform app using jQueryMobile and Phonegap. Currently using jQM 1.1.0 and Phonegap 1.6.1.
The page transition function sometimes just seems to break down when the user clicks a button or list item that links to another page in the app.
<a href="#page2">
This kind of link is what the whole app is made of. But depending on god knows what, sometimes when you click a link the app stalls. External links will still be followed, and buttons that don't trigger any page changing work fine. But anything with href and $.mobile.changePage seems to be broken.
This problem occurs in iPad Simulator and iPhone Simulator, not in Chrome. It seems to have something to do with the type of page transition specified (i.e. fade or slide or flip etc). Some transitions seem to cause problems, sometimes it seems to be the lack of a specified transition that is the cause, and sometimes neither of those explanations have any traction.
Before I add a whole bunch of code, I'm interested if anyone has similar experiences.
I have a PhoneGap application in iOS to display a web app. I want to modify the browser control that is displaying the web app to have a few buttons at the bottom that function as "back" "forward" "refresh" etc. is this possible? Do I need to use a plugin?
I suggest using html to implement those buttons, which is pretty easy with javascript. Since it's not performance-critical, doing this with native code is unnecessary.
I don't know any plugins for what exactly you want, but I have used the android version of this iOS ChildBrowser plugin which provides a pop-up browser with "back", "forward" and "refresh" buttons. It's quite convenient for browsing external web pages.
I have a requirement to set the focus to a textbox in a page when the page loads. My target device is ipad.
I heard that, by design, it is not supported in ipad.
But is there a workaround for this?
Maybe this can help you:
By design, some focus() events in Mobile Safari are ignored. A lot of sites would do focus() unnecessarily and bringing up the keyboard is slow/intrusive.
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?