Detect virtual keyboard vs. hardware keyboard
Solution 1
I don't think overriding default onscreen keyboard is a good idea, and I'd recommend going with what Jani suggested - virtual keyboards adapt too.
But I'm sure it is possible to detect most keyboards with the resize
event paired with focus on the field or by monitoring window.innerHeight
(or some other [a-z]*Height) and comparing value before and after field focus.
This is a weird case of feature detection, so it will need plenty of experimentation. I wouldn't do it if I were you.
Solution 2
I think the best approach would be to combine HTML5 form attributes with an optional virtual keyboard link.
HTML5 form attributes can be used to trigger different types of keyboards. For example, <input type="email">
, <input type="number">
and <input type="tel">
will trigger the appropriate keyboard types on iOS (not sure about Android/WinPho/other, but I would imagine it does the same), allowing the user to input the data more easily.
If you want, you could additionally offer a button to trigger a custom numpad under the text field for older non-HTML5 compliant mobile browsers. Those will display the new HTML5 fields as standard text fields.
You can use browser sniffing to detect mobile browsers, but don't forget that those can still support things such as bluetooth keyboards. Sniffing additionally has the problem that it will almost certainly miss some browsers, and incorrectly detect others, thus you shouldn't rely on it solely.
Solution 3
The most bullet prof solution that works across Chrome/Safari etc.. and on both Android and iOS as of 20-nov-2017 will be to detect a change in the height of a div
that has a vh
height units (viewport height)
Then on any blur/focus change of an input/textarea check if that div
now has a height of 30% less (in pixels) than it used to have before that blur/focus event.
CSS:
#height-div{height: 10vh;}
jQuery:
$(document).ready(function() {
var initialHeight = $("#height-div").height();//gives current height in pixels! We save it for later comparisons
}
Now here is the magic:
$("input, textarea").focus(function(){
setTimeout(function(){
if((initialHeight*0.7) > $("#height-div").height()){//if the current viewport height is smaller than 70% of the original size, it means that the keyboard is up
//ENTER YOUR LOGIC HERE
}else if((initialHeight*0.7) < parent.$submit.height()){//if the current viewport height is larger than 70% of the original size, it means that the keyboard is down
//ENTER YOUR LOGIC HERE
}
},500);
});
$("input, textarea").blur(function(){
setTimeout(function(){
if((initialHeight*0.7) > $("#height-div").height()){//if the current viewport height is smaller than 70% of the original size, it means that the keyboard is up
//ENTER YOUR LOGIC HERE
}else if((initialHeight*0.7) < parent.$submit.height()){//if the current viewport height is larger than 70% of the original size, it means that the keyboard is down
//ENTER YOUR LOGIC HERE
}
},500);
});
Solution 4
It may not be detecting the keyboard. But I would try detecting if the user is on a mobile browser. Since the devices that have native virtual keyboards almost unanimously run on mobile browsers.
Here is a nice little script that uses jquery
If they aren't mobile present your standard input field.
If they are mobile do not display the input field (So they don't get the virtual keyboard), instead have a hidden field or list that gets updated with jquery when they click the buttons for your pinpad.
Andreas Louv
Updated on November 21, 2020Comments
-
Andreas Louv over 3 years
I have been thinking about this a while now, and I can't figure a way to deal with it. Is there any way to detect if the user uses a virtual (software) keyboard or a traditional (hardware) keyboard?
The new Windows Surface has its own keyboard in the cover, and for Android / iPad there are a ton of different bluetooth keyboards.
So, do any of you have any input about this?
I'm aiming for Android, IOS & Windows Tablet/Phone.
Motivation: (very subjective)
When developing web applications for tablet/smartphone I have come to the understanding that it's easier - in many situations - to use a JavaScript keyboard instead of the OS's software keyboard.
Lets say you want to enter a PIN code. Instead of having a keyboard filling half of the screen:
Software (OS) keyboard:
|----------------| | [ input] | | | |----------------| | 1 2 3 4 5 | | 6 7 8 9 0 | |----------------|
JavaScript keyboard:
|----------------| | [ input] | | | 1 2 3| | | | 4 5 6| | | |_7_8_9| | | | | | |----------------|
If you need to handle a lot of inputs, maybe you want to make an overlaying
div
with the inputs and use the software keyboard:|----------------| | P1 P2 P3 P4 | | [inp 1][inp 2] | |----------------| | KEYBOARD | | | |----------------|
But if the user has their own hardware keyboard, we want to make the edit inline in place.
I have been looking around SO and found this post: iPad Web App: Detect Virtual Keyboard Using JavaScript in Safari? ... but this seams to only work in IOS - not sure about browser.
-
Kendall Frey over 11 yearsI have a tablet with no keyboard running a nearly normal installation of Windows 7. I use the same browsers I would on a PC, so this wouldn't work for me. Nice catch though.
-
adi518 about 6 years30% is just a guess. Seems like a fragile approach.
-
Kamil Bęben almost 5 years1. Keyboards on android device can be customized to be in various sizes. 2. User can rotate his phone. 3. User can use split-screen. Sadly, this approach is not bullet prof at all.
-
sean over 4 yearsTouchEvent can be created on devices without touchscreens.
-
André Caldas over 3 yearsI want to make a LaTeX virtual keyboard. You push buttons like "matrix", "integral", "double integral". Using the keyboard, I can choose the type of delimiter, etc. The keyboard is already big... on a mobile device, the virtual keyboard gets in the way. Maybe it's me... :-(
-
Aidin over 2 yearshasTouch() !== hasVirtualKeyboard(). Consider convertible laptops with touchscreen.