Skip to content

feat(numeric-keyboard): expose keypad input rules for hardware keyboards - #16

Merged
romchornyi merged 1 commit into
masterfrom
feat/numeric-keypad-hardware-input
Aug 28, 2026
Merged

feat(numeric-keyboard): expose keypad input rules for hardware keyboards#16
romchornyi merged 1 commit into
masterfrom
feat/numeric-keypad-hardware-input

Conversation

@romchornyi

Copy link
Copy Markdown
Collaborator

Issue being fixed or feature implemented

NumericKeyboardView renders buttons and installs no text responder, so digits typed on a connected physical keyboard never reach it. A host that wants hardware-keyboard support has to add its own responder — and then it needs the pad's input rules, which were internal to the package.

The first host to do this (dashwallet-ios #1040) reimplemented them app-side and got the locale handling wrong: it mapped , to the decimal separator in every locale, so typing 1,000 in en_US produced 1.000 — a silent 1000x error on the send and pay screens. The on-screen pad, which routes through applyKeyPress, drops the locale's grouping separator and gets 1000.

What was done?

  • Made NumericKeyboardLocaleSupport public, along with applyKeyPress, decimalSeparator(for:) and a new deleteKey.
  • Added key(forTyped:locale:), which translates a character typed on a physical keyboard into the key the on-screen pad would have sent, or nil when the pad has no such key.

The locale-sensitive rules — which separator is decimal, which is grouping and therefore dropped, at most one decimal separator, delete — stay in applyKeyPress alone. key(forTyped:) deliberately passes the grouping separator through untouched instead of filtering it, so that rule has exactly one implementation and both input paths agree by construction.

No behavior change for existing callers: the on-screen pad's code path is untouched, and the change to the type's surface is internalpublic.

How Has This Been Tested?

  • swift build -c release — clean.
  • swift test --filter NumericKeyboardLocaleSupportTests — 8 tests, 0 failures.
  • New cases cover the character mapping, the locale-dependent decimal key (en_US, de_DE, and de_CH where the typed character is neither separator), and that typing a grouped amount keeps its magnitude in both en_US (1,000.51000.5) and de_DE (1.000,51000,5).

Breaking Changes

None.

Checklist:

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have added or updated relevant unit/integration/functional/e2e tests
  • I have made corresponding changes to the documentation

`NumericKeyboardView` renders buttons and installs no text responder, so a
host that wants physical-keyboard support has to add its own responder and
then needs the pad's input rules. They were `internal`, so the first host to
do this reimplemented them and got the locale handling wrong: it mapped ","
to the decimal separator in every locale, and typing "1,000" in `en_US`
produced "1.000".

Make `NumericKeyboardLocaleSupport` public and add `key(forTyped:locale:)`,
which translates a typed character into the key the on-screen pad would have
sent. The locale-sensitive rules — which separator is decimal, which is
grouping and therefore dropped, at most one decimal separator, delete — stay
in `applyKeyPress` alone, so both input paths agree by construction.
@coderabbitai

coderabbitai Bot commented Aug 27, 2026

Copy link
Copy Markdown

Important

  • 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 5d0ebcd7-5196-41c4-90a6-7249115da2e7


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@llbartekll llbartekll left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good

@romchornyi
romchornyi merged commit 83cf65a into master Aug 28, 2026
2 checks passed
@romchornyi
romchornyi deleted the feat/numeric-keypad-hardware-input branch August 28, 2026 08:52
romchornyi pushed a commit to PastaPastaPasta/dashwallet-ios that referenced this pull request Aug 28, 2026
dashpay/DashUIKit#16 made `NumericKeyboardLocaleSupport` public, so the
app no longer has to carry its own copy of the keypad's input rules.

`key(forTyped:locale:)` maps a typed character to the key the on-screen
keypad would have sent, and `applyKeyPress` decides what that key does to
the value. Both input paths now run the same code, so they cannot drift
apart again — which is how "1,000" typed in en_US came to produce "1.000".

The app-side tests go with the app-side copy; the rules are covered by
`NumericKeyboardLocaleSupportTests` in the package, including the
grouping-separator cases.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants