# KeyType Enum Values and Behavior in the JapaneseKeyboard Rendering System

> Explore KeyType enum values in the JapaneseKeyboard rendering system. Understand nine modes like NORMAL and HIERARCHICAL_FLICK for key behavior and flick gestures in FlickKeyboardView.

- Repository: [Kazu/japanesekeyboard](https://github.com/kazumaproject/japanesekeyboard)
- Tags: api-reference
- Published: 2026-03-05

---

**The `KeyType` enum in kazumaproject/japanesekeyboard defines nine distinct rendering and interaction modes—from `NORMAL` for standard taps to `HIERARCHICAL_FLICK` for deep menu navigation—that determine how each key is drawn and how flick gestures are interpreted by `FlickKeyboardView`.**

The `KeyType` enum is the core abstraction that controls how individual keys appear and behave in the JapaneseKeyboard open-source project. Defined in [`KeyModels.kt`](https://github.com/kazumaproject/japanesekeyboard/blob/main/KeyModels.kt), this sealed-style enumeration allows the rendering system to support everything from simple alphanumeric input to complex multi-directional flick gestures essential for Japanese text entry.

## What Is the KeyType Enum?

Located at **[`custom_keyboard/src/main/java/com/kazumaproject/custom_keyboard/data/KeyModels.kt`](https://github.com/kazumaproject/japanesekeyboard/blob/main/custom_keyboard/src/main/java/com/kazumaproject/custom_keyboard/data/KeyModels.kt)** (lines 94-112), the `KeyType` enum serves as a type-safe discriminator that the view layer uses to select appropriate drawing routines and touch handlers. Each enum value represents a specific visual template and interaction model, enabling the keyboard to support diverse input methods—from standard tapping to sophisticated hierarchical flick navigation.

## Complete List of KeyType Enum Values and Behaviors

The JapaneseKeyboard rendering system recognizes nine distinct key types, each optimized for specific input scenarios.

### NORMAL

**Visual representation:** Standard rectangular key with a text label.

**Interaction model:** Simple tap detection; optional long-press for secondary actions.

**Typical usage:** Alphanumeric keys such as "A" or "1" where flick gestures are not required.

### CIRCULAR_FLICK

**Visual representation:** Round key background that displays a circular overlay when pressed.

**Interaction model:** Polar-coordinate flick detection in any direction around the key center; the direction determines character output.

**Typical usage:** Keys supporting 4-way flick input for Japanese kana families.

### CROSS_FLICK

**Visual representation:** Plus-shaped overlay indicating four cardinal directions.

**Interaction model:** Flick detection restricted to up, down, left, and right axes only.

**Typical usage:** Punctuation or modifier keys requiring a concise set of directional alternatives.

### STANDARD_FLICK

**Visual representation:** Default flick layout featuring a small central arrow with surrounding options.

**Interaction model:** Same directional detection as `CIRCULAR_FLICK` but with standardized visual cues.

**Typical usage:** Most Japanese kana keys providing the "a/i/u/e/o" vowel variations.

### PETAL_FLICK

**Visual representation:** Flower-like overlay with 5-6 petal-shaped regions radiating outward.

**Interaction model:** Flick detection mapped to distinct petal regions, each emitting a different character.

**Typical usage:** Keys requiring more than four alternatives, such as small kana or voiced kana variations.

### TWO_STEP_FLICK

**Visual representation:** Two-stage interaction where the first flick reveals a sub-menu.

**Interaction model:** Initial flick selects a character group; second flick chooses the specific character within that group.

**Typical usage:** Rarely used kana or symbols grouped together to save screen space.

### STICKY_TWO_STEP_FLICK

**Visual representation:** Similar to `TWO_STEP_FLICK` but the sub-menu remains active.

**Interaction model:** The selected sub-menu stays open (sticky) until the user taps elsewhere, allowing rapid sequential entry from the same group.

**Typical usage:** Emoji categories or extended symbol sets where users select multiple items from one group.

### HIERARCHICAL_FLICK

**Visual representation:** Deep tree-like hierarchy with multiple traversal levels.

**Interaction model:** Repeated flick gestures descend through hierarchical levels, each revealing more specific character subsets.

**Typical usage:** Extensive character sets like emoji categories with deep classification trees.

## How KeyType Drives the Rendering Pipeline

The enum itself contains no rendering logic; instead, it acts as a declarative signal to the view layer. The primary consumer is **`FlickKeyboardView`** ([`custom_keyboard/src/main/java/com/kazumaproject/custom_keyboard/view/FlickKeyboardView.kt`](https://github.com/kazumaproject/japanesekeyboard/blob/main/custom_keyboard/src/main/java/com/kazumaproject/custom_keyboard/view/FlickKeyboardView.kt)), which examines the `keyData.keyType` field during the draw cycle.

When `FlickKeyboardView` encounters a specific `KeyType`, it selects the appropriate strategy:

- **`KeyType.CIRCULAR_FLICK`**: Draws a circular background and registers a polar-coordinate flick detector that measures angle and distance from the key center.
- **`KeyType.CROSS_FLICK`**: Renders a plus-shaped overlay and constrains gesture detection to the four cardinal axes.
- **`KeyType.PETAL_FLICK`**: Generates a flower-like visual with radial segments and maps touch coordinates to specific petal regions.

This separation of concerns—using `KeyType` as a pure data descriptor while `FlickKeyboardView` handles implementation—allows the keyboard to support complex interaction models without cluttering the data layer with view logic.

## Defining Keys with KeyType: Code Examples

In the JapaneseKeyboard codebase, keys are instantiated as **`KeyData`** objects where the `keyType` property determines rendering and behavior. Here are practical examples from the layout definitions:

```kotlin
// Standard alphanumeric key - no flick capability
val keyA = KeyData(
    label = "A",
    row = 0,
    column = 0,
    isFlickable = false,
    action = KeyAction.InputText("A"),
    keyType = KeyType.NORMAL
)

```

```kotlin
// Japanese kana with standard 4-way flick (a/i/u/e/o variations)
val keyKa = KeyData(
    label = "か",
    row = 1,
    column = 2,
    isFlickable = true,
    action = KeyAction.InputText("か"),
    keyType = KeyType.STANDARD_FLICK
)

```

```kotlin
// Small kana with petal-style multi-option flick
val keySmallKa = KeyData(
    label = "ヵ",
    row = 2,
    column = 1,
    isFlickable = true,
    action = KeyAction.InputText("ヵ"),
    keyType = KeyType.PETAL_FLICK
)

```

```kotlin
// Emoji category with two-step hierarchical selection
val keyEmoji = KeyData(
    label = "😊",
    row = 3,
    column = 3,
    isFlickable = true,
    action = null,  // Resolved after second flick step
    keyType = KeyType.TWO_STEP_FLICK
)

```

These examples demonstrate how `KeyType` works with the `isFlickable` flag and `action` properties to create the complete interaction model for each key.

## Key Files in the Rendering Architecture

Understanding `KeyType` requires familiarity with three primary files that form the rendering pipeline:

- **[`custom_keyboard/src/main/java/com/kazumaproject/custom_keyboard/data/KeyModels.kt`](https://github.com/kazumaproject/japanesekeyboard/blob/main/custom_keyboard/src/main/java/com/kazumaproject/custom_keyboard/data/KeyModels.kt)**  
  Defines the `KeyType` enum (lines 94-112) and the `KeyData` class. This file serves as the source of truth for all available key types.

- **[`custom_keyboard/src/main/kotlin/com/kazumaproject/custom_keyboard/layout/KeyboardDefaultLayouts.kt`](https://github.com/kazumaproject/japanesekeyboard/blob/main/custom_keyboard/src/main/kotlin/com/kazumaproject/custom_keyboard/layout/KeyboardDefaultLayouts.kt)**  
  Contains the default keyboard configurations where `keyType` values are assigned to specific keys. For example, lines 3323-3385 demonstrate `KeyType.PETAL_FLICK` assignments for small kana variations.

- **[`custom_keyboard/src/main/java/com/kazumaproject/custom_keyboard/view/FlickKeyboardView.kt`](https://github.com/kazumaproject/japanesekeyboard/blob/main/custom_keyboard/src/main/java/com/kazumaproject/custom_keyboard/view/FlickKeyboardView.kt)**  
  Implements the view layer that consumes `KeyType` to determine drawing routines and gesture detection strategies. This file translates enum values into actual user interface behavior.

## Summary

- The **`KeyType`** enum in [`KeyModels.kt`](https://github.com/kazumaproject/japanesekeyboard/blob/main/KeyModels.kt) defines nine distinct rendering and interaction modes for keyboard keys in the JapaneseKeyboard project.
- Values range from **`NORMAL`** for simple tap keys to complex hierarchical modes like **`HIERARCHICAL_FLICK`** for deep emoji navigation.
- The enum acts as a declarative signal to **`FlickKeyboardView`**, which selects appropriate drawing routines and gesture detectors based on the `keyType` value.
- Layout definitions in **[`KeyboardDefaultLayouts.kt`](https://github.com/kazumaproject/japanesekeyboard/blob/main/KeyboardDefaultLayouts.kt)** assign specific `KeyType` values to `KeyData` objects to configure the visual and behavioral properties of each key.

## Frequently Asked Questions

### What is the difference between CIRCULAR_FLICK and STANDARD_FLICK?

Both `CIRCULAR_FLICK` and `STANDARD_FLICK` support four-directional flick input around a central key, but they differ in visual presentation. `CIRCULAR_FLICK` renders a round key background with a circular overlay when pressed, while `STANDARD_FLICK` displays the default flick layout featuring a small central arrow with surrounding options. The interaction model remains similar—both use polar-coordinate detection—but the visual cues help users distinguish between different key families in the layout.

### How does the keyboard handle TWO_STEP_FLICK versus STICKY_TWO_STEP_FLICK?

`TWO_STEP_FLICK` implements a transient two-stage selection process where the first flick opens a sub-menu and the second flick selects a specific character, after which the menu closes immediately. In contrast, `STICKY_TWO_STEP_FLICK` keeps the sub-menu active after the first selection, allowing users to input multiple characters from the same group without re-opening the menu. The sticky variant is particularly useful for emoji categories or extended symbol sets where users typically select several items sequentially.

### Where is the KeyType enum defined in the source code?

The `KeyType` enum is defined in **[`custom_keyboard/src/main/java/com/kazumaproject/custom_keyboard/data/KeyModels.kt`](https://github.com/kazumaproject/japanesekeyboard/blob/main/custom_keyboard/src/main/java/com/kazumaproject/custom_keyboard/data/KeyModels.kt)** at lines 94-112. This file serves as the central data model for the keyboard, containing the sealed-style enumeration that describes all possible key rendering modes. The enum is referenced throughout the codebase, particularly in [`KeyboardDefaultLayouts.kt`](https://github.com/kazumaproject/japanesekeyboard/blob/main/KeyboardDefaultLayouts.kt) where specific values are assigned to keys, and in [`FlickKeyboardView.kt`](https://github.com/kazumaproject/japanesekeyboard/blob/main/FlickKeyboardView.kt) where the rendering logic consumes these type definitions.

### Can I use KeyType.NORMAL for flickable keys?

While technically possible, using `KeyType.NORMAL` for flickable keys contradicts the intended design of the JapaneseKeyboard system. `KeyType.NORMAL` is optimized for simple tap interactions and lacks the visual overlays and gesture detectors required for flick input. If you assign `KeyType.NORMAL` to a key with `isFlickable = true`, the view layer will not render the necessary flick UI elements, resulting in a broken user experience. For flickable keys, you should use appropriate types such as `STANDARD_FLICK`, `CIRCULAR_FLICK`, or `PETAL_FLICK` depending on the number of directional options required.