asking property
What keyboard the platform would be showing right now, or null for none.
The two signals, and the whole state machine they drive. The framework computes this and hands it to whatever control is installed, so nothing downstream needs a heuristic for when a phone would raise its keyboard: it is up between a show and the hide after it.
Three things about the traffic are worth knowing before reading it.
show arrives twice per focus — an EditableText asks on focus and
again on tap — so a listener must be edge-triggered on the value rather
than counting calls, which a ValueNotifier does for free. Moving from
one field to the next produces no hide at all: TextInput defers it
to a microtask that cancels itself if anything re-attaches
(_scheduleHide), which is why nothing here needs a debounce. And the
variant can change without the keyboard ever going down — a text field
to a number field is one keyboard morphing into a shorter one — which is
why this carries which keyboard rather than only whether there is one.
Implementation
final asking = ValueNotifier<KeyboardVariant?>(null);