Another \"how to remove the pre, next, done button\" -question you may think. Not really actually. I\'ve done some rather thorough research on this and tried out di
This worked for me: https://github.com/don/KeyboardToolbarRemover
You will have to know though, there is no Cordova.plist file as of Phonegap 2.3.0 - instead edit your config XML file with the following:
<plugin name="KeyboardToolbarRemover" value="KeyboardToolbarRemover" />
in the branch
For anyone still struggling with this, Phonegap now has two properties for disabling the form accessory bar issue and the problem of page scrolling when input and text area fields trigger the keyboard.
Just set the following in your config.xml and your good to go.
<preference name="HideKeyboardFormAccessoryBar" value="true" />
<preference name="KeyboardShrinksView" value="true" />
Link to Phonegap Documentation
If you are using phonegap/cordova 3 CLI, you now require a plugin to remove the toolbar. Install it via the terminal..
$ cordova plugin add org.apache.cordova.keyboard
and use this in your javascript
Keyboard.hideFormAccessoryBar(true);
But... it's not perfect. Firstly if you intend to use input.focus() to bring up the keyboard, then the toolbar is shown briefly before being hidden. From then on it's fine. If you allow a user to click directly in the input field it will be fine.
Then there can be movement at the top of the screen, which can be solved with this answer.. How to fix keyboard issues with Cordova 3.1 on iOS?
It can be difficult to get right, so I'd ask yourself if you really need to hide it, or can you make it useful for the user instead?
There is no public (so, App Store-allowed) way to disable the form assistant bar on web views for UIWebView (which AFAIK is what PhoneGap uses) form elements in any version of iOS.
This looks like the cordova plugin we have all been waiting for... https://github.com/don/KeyboardToolbarRemover
This allows a simple toolbar.hide()
and toolbar.show()
Here you go, I'm using this in an app I'm currently developing. Fingers crossed that it gets to the app store, although going on other 'hacks' that make it to the store this is no worse than others, so should stand a fair chance.
No annoying side effects with this method - it cleanly removes the bar by making sure it's never created in the first place. Ta da!
Credit goes to https://gist.github.com/2048571, this is his code with a small fix.
#import <objc/runtime.h>
#import <UIKit/UIKit.h>
@interface UIWebView (HackishAccessoryHiding)
@property (nonatomic, assign) BOOL hackishlyHidesInputAccessoryView;
@end
@implementation UIWebView (HackishAccessoryHiding)
static const char * const hackishFixClassName = "UIWebBrowserViewMinusAccessoryView";
static Class hackishFixClass = Nil;
- (UIView *)hackishlyFoundBrowserView {
UIScrollView *scrollView = self.scrollView;
UIView *browserView = nil;
for (UIView *subview in scrollView.subviews) {
if ([NSStringFromClass([subview class]) hasPrefix:@"UIWebBrowserView"]) {
browserView = subview;
break;
}
}
return browserView;
}
- (id)methodReturningNil {
return nil;
}
- (void)ensureHackishSubclassExistsOfBrowserViewClass:(Class)browserViewClass {
if (!hackishFixClass) {
Class newClass = objc_allocateClassPair(browserViewClass, hackishFixClassName, 0);
IMP nilImp = [self methodForSelector:@selector(methodReturningNil)];
class_addMethod(newClass, @selector(inputAccessoryView), nilImp, "@@:");
objc_registerClassPair(newClass);
hackishFixClass = newClass;
}
}
- (BOOL) hackishlyHidesInputAccessoryView {
UIView *browserView = [self hackishlyFoundBrowserView];
return [browserView class] == hackishFixClass;
}
- (void) setHackishlyHidesInputAccessoryView:(BOOL)value {
UIView *browserView = [self hackishlyFoundBrowserView];
if (browserView == nil) {
return;
}
[self ensureHackishSubclassExistsOfBrowserViewClass:[browserView class]];
if (value) {
object_setClass(browserView, hackishFixClass);
}
else {
Class normalClass = objc_getClass("UIWebBrowserView");
object_setClass(browserView, normalClass);
}
[browserView reloadInputViews];
}
@end