Detect virtual keyboard vs. hardware keyboard

问题:

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.

回答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.

回答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.

回答3:

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.

回答4:

WURFL is a serverside framework that offers you a lot of information about the requesting device's capabilities. With wurfel in place, your application will able to serve the various devices / device groups with optimised output/markup.

One of the simpliest scenarious would be to distiguish between desktops, tables and smartphones.

The database (xml file) is updated regularly and official api's are available for java, php and .net

回答5:

I came across a newer question the other day and a great answer that may help with your keyboard issue.

Time out on jquery hover (touch)

Essentially it uses a JQuery function that returns a boolean if it was able to create a touch event.

$(document).ready(function() {

    function hasTouch() {
        try {
           document.createEvent("TouchEvent");
           return true;
        } catch (e) {
           return false;
        }    
    }

    var touchPresent = hasTouch();
});

回答6:

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);
});