KeyCharacterMap

A keyboard with all the letters, and maybe some numbers.

An alphabetic keyboard supports text entry directly but may have a condensed layout with a small form factor. In contrast to a full keyboard, some symbols may only be accessible using special on-screen character pickers. In addition, to improve typing speed and accuracy, the framework provides special affordances for alphabetic keyboards such as auto-capitalization and toggled / locked shift and alt keys.

This type of keyboard is generally designed for thumb typing.

The id of the device's primary built in keyboard is always 0.

Mask the return value from get(int, int) with this value to get a printable representation of the accent character of a "dead key."

A full PC-style keyboard.

A full keyboard behaves like a PC keyboard. All symbols are accessed directly by pressing keys on the keyboard without on-screen support or affordances such as auto-capitalization.

This type of keyboard is generally designed for full two hand typing.

This private-use character is used to trigger Unicode character input by hex digits.

Modifier keys may be chorded with character keys.

Modifier keys may be chorded with character keys or they may toggle into latched or locked states when pressed independently.

A numeric (12-key) keyboard.

A numeric keyboard supports text entry using a multi-tap approach. It may be necessary to tap a key multiple times to generate the desired letter or symbol.

This type of keyboard is generally designed for thumb typing.

This private-use character is used to bring up a character picker for miscellaneous symbols.

A keyboard with all the letters, but with more than one letter per key.

This type of keyboard is generally designed for thumb typing.

A keyboard that is only used to control special functions rather than for typing.

A special function keyboard consists only of non-printing keys such as HOME and POWER that are not actually used for typing.

The id of a generic virtual keyboard with a full layout that can be used to synthesize key events. Typically used with getEvents(char[]).

Describe the kinds of special objects contained in this Parcelable's marshalled representation.

Queries the framework about whether any physical keys exist on the any keyboard attached to the device that are capable of producing the given key code.

Queries the framework about whether any physical keys exist on the any keyboard attached to the device that are capable of producing the given array of key codes.

Gets the Unicode character generated by the specified key and meta key state combination.

Returns the Unicode character that the specified key would produce when the specified meta bits (see MetaKeyKeyListener) were active.

Returns 0 if the key is not one that is used to type Unicode characters.

If the return value has bit COMBINING_ACCENT set, the key is a "dead key" that should be combined with another to actually produce a character -- see getDeadChar(int, int) -- after masking with COMBINING_ACCENT_MASK.

Get the character that is produced by putting accent on the character c. For example, getDeadChar('`', 'e') returns è.

Gets the primary character for this key. In other words, the label that is physically printed on it.

Get an array of KeyEvent objects that if put into the input stream could plausibly generate the provided sequence of characters. It is not guaranteed that the sequence is the only way to generate these events or that it is optimal.

This function is primarily offered for instrumentation and testing purposes. It may fail to map characters to key codes. In particular, the key character map for the built-in keyboard device id may be empty. Consider using the key character map associated with the virtual keyboard device id instead.

For robust text entry, do not use this function. Instead construct a KeyEvent with action code ACTION_MULTIPLE that contains the desired string using KeyEvent(long, String, int, int).

Get the character conversion data for a given key code.

Gets the keyboard type. Returns NUMERIC, PREDICTIVE, ALPHA, FULL or SPECIAL_FUNCTION.

Different keyboard types have different semantics. Refer to the documentation associated with the keyboard type constants for details.

Gets the first character in the character array that can be generated by the specified key code.

This is a convenience function that returns the same value as getMatch(keyCode, chars, 0).

Gets the first character in the character array that can be generated by the specified key code. If there are multiple choices, prefers the one that would be generated with the specified meta key modifier state.

Gets a constant that describes the behavior of this keyboard's modifier keys such as KEYCODE_SHIFT_LEFT.

Currently there are two behaviors that may be combined:

• Chorded behavior: When the modifier key is pressed together with one or more character keys, the keyboard inserts the modified keys and then resets the modifier state when the modifier key is released.
• Toggled behavior: When the modifier key is pressed and released on its own it first toggles into a latched state. When latched, the modifier will apply to next character key that is pressed and will then reset itself to the initial state. If the modifier is already latched and the modifier key is pressed and release on its own again, then it toggles into a locked state. When locked, the modifier will apply to all subsequent character keys that are pressed until unlocked by pressing the modifier key on its own one more time to reset it to the initial state. Toggled behavior is useful for small profile keyboards designed for thumb typing.

This function currently returns MODIFIER_BEHAVIOR_CHORDED when the keyboard type is FULL or SPECIAL_FUNCTION and MODIFIER_BEHAVIOR_CHORDED_OR_TOGGLED otherwise. In the future, the function may also take into account global keyboard accessibility settings, other user preferences, or new device capabilities.

Gets the number or symbol associated with the key.

The character value is returned, not the numeric value. If the key is not a number, but is a symbol, the symbol is retuned.

This method is intended to to support dial pads and other numeric or symbolic entry on keyboards where certain keys serve dual function as alphabetic and symbolic keys. This method returns the number or symbol associated with the key independent of whether the user has pressed the required modifier.

For example, on one particular keyboard the keys on the top QWERTY row generate numbers when ALT is pressed such that ALT-Q maps to '1'. So for that keyboard when getNumber(int) is called with KEYCODE_Q it returns '1' so that the user can type numbers without pressing ALT when it makes sense.

Returns true if the specified key produces a glyph.

Loads the key character maps for the keyboard with the specified device id.

Flatten this object in to a Parcel.

Invoked when the garbage collector has detected that this instance is no longer reachable. The default implementation does nothing, but this method can be overridden to free resources.

Note that objects that override finalize are significantly more expensive than objects that don't. Finalizers may be run a long time after the object is no longer reachable, depending on memory pressure, so it's a bad idea to rely on them for cleanup. Note also that finalizers are run on a single VM-wide finalizer thread, so doing blocking work in a finalizer is a bad idea. A finalizer is usually only necessary for a class that has a native peer and needs to call a native method to destroy that peer. Even then, it's better to provide an explicit close method (and implement Closeable), and insist that callers manually dispose of instances. This works well for something like files, but less well for something like a BigInteger where typical calling code would have to deal with lots of temporaries. Unfortunately, code that creates lots of temporaries is the worst kind of code from the point of view of the single finalizer thread.

If you must use finalizers, consider at least providing your own ReferenceQueue and having your own thread process that queue.

Unlike constructors, finalizers are not automatically chained. You are responsible for calling super.finalize() yourself.

Uncaught exceptions thrown by finalizers are ignored and do not terminate the finalizer thread. See Effective Java Item 7, "Avoid finalizers" for more.