- Orientation
- The On-Screen Keyboard
- The Hardware Keyboard
- The User Interface
- The Code-Behind
- The Finished Product
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Hardware Keyboard
Although you probably have a Windows phone for testing your apps, you may very well not have a model with a hardware keyboard. Don't worry—as long as you support both orientations for any page involving typing, your app should work just fine on such a device without further testing. Still, it is helpful to understand how the hardware keyboard works.
A Windows phone can have a hardware keyboard in a number of different configurations. It could slide out, flip out, swivel out, or just be stationary. It could be placed anywhere, and be oriented for either portrait, landscape left, or landscape right.
When a non-stationary keyboard is tucked away, the phone acts as if there is no hardware keyboard, and the on-screen keyboard behaves as it always does. When a non-stationary hardware keyboard is pulled/flipped/swiveled out, the screen's orientation automatically changes to match the orientation of the keyboard (if the current page is marked as supporting this orientation). This happens regardless of the phone's physical orientation, so it may temporarily produce a sideways screen. However, the user will presumably rotate the phone appropriately before using the keyboard.
When the hardware keyboard is activated, the on-screen keyboard goes away (if it was visible at the time) and stays away, except for a few special circumstances. Pressing the symbol (SYM) key on the hardware keyboard invokes the on-screen keyboard with pages of numbers and symbols. Pressing the emoticons key on the hardware keyboard invokes the on-screen keyboard with pages of emoticons. Pressing the accent key after typing certain letters automatically cycles through the accented variations, but it also shows the accented variations as on-screen keyboard buttons. Text suggestions, when used by the current input scope, also appear on the screen. And so on. The last two circumstances are demonstrated in Figure 3.3 inside the built-in Alarms app.
)
Figure 3.3 Two examples of small on-screen supplements for an activated hardware keyboard, displayed at the edge of the screen adjacent to the keyboard.
The most important thing to understand about the hardware keyboard is what it is and isn't intended for. It is meant to provide an alternate way to type text into a text box. And that is it. It should never be used for any kind of navigation (scrolling, panning, changing control focus)—even for a game. Although it may have arrow keys for moving the caret within a text box, those arrows should be used for any other purpose. The hardware number keys can't even be used with the built-in Calculator app, because that is not the same thing as typing into a text box!
You can mimic the use of a hardware keyboard with the Windows Phone Emulator. The Pause key on your computer's keyboard toggles between having an on-screen keyboard and a hardware keyboard. To use the hardware keyboard, simply use your computer's keyboard! This mimics the behavior of a portrait slide-out keyboard, as pages always stay in the portrait orientation (if they support it).
The emulation is not perfect, however. Custom logic that processes keystrokes might not work in the emulator due to some keys not being reported correctly. For example, on my laptop, the Enter key appears as Key.Unknown inside a KeyDown event handler rather than Key.Enter.
Although these restrictions make the hardware keyboard less compelling than it could have been, it frees developers from having to worry about exploiting such optional features. It also protects users from the existence of apps that only work well with a hardware keyboard. Windows Phone and its apps are clearly optimized for touch screen usage, and users without a hardware keyboard should not feel like they are missing out on anything other than arguably easier typing.
Is there a way to know when the user has activated (e.g. slid out) a hardware keyboard?
No. There are no APIs specific to hardware keyboards.
Is there a way to know when the user has typed something on the hardware keyboard?
Not reliably. You can attach a KeyDown and/or KeyUp event handler to Silverlight elements other than a text box or password box, and this can sometimes be exploited in strange ways that aren't guaranteed to continue working. For example, if a scroll viewer—even an empty one—has focus (e.g. the user has tapped it), its KeyDown and KeyUp events get raised when keys on the hardware keyboard are pressed and released! (This does not happen for other elements, such as a grid.) Inside such event handlers, you know that the source must have been the hardware keyboard, because no on-screen keyboard could have possibly been involved.
Is there a way to know if the current phone even has a hardware keyboard?
Not reliably. You can possibly infer this information after checking the values of DeviceManufacturer and/or DeviceName from the static Microsoft.Phone.Info.DeviceExtendedProperties class (which requires the ID_CAP_IDENTITY_DEVICE capability).