Soft Keyboard

On a touch device the on-screen keyboard pops up whenever an input receives focus. Sometimes you do not want it — in a warehouse, on a handheld used mainly for barcode scanning, the keyboard covers half the screen and nobody ever types into the field. Sometimes you want a different one: a digit pad for a quantity, a phone layout for a number.

Both are the HTML inputmode attribute, and abap2UI5 exposes it as a bound property of a companion control.

The control

z2ui5.cc.InputExt is a sap.m.Input in every respect — same value binding, same suggestions, same value state, same events — with one property added:

Property	What it does
inputMode	the HTML inputmode of the inner <input>: none keeps the keyboard down, numeric, decimal, tel, email, url, search, text ask for that layout. Empty leaves the field exactly as sap.m.Input rendered it

Declare the namespace on the view and build the field as z2ui5:InputExt:

DATA(view) = z2ui5_cl_ui5_view_builder=>factory(
    )->ele( n = `View` ns = `mvc`
        )->a( n = `xmlns`       v = `sap.m`
        )->a( n = `xmlns:mvc`   v = `sap.ui.core.mvc`
        )->a( n = `xmlns:z2ui5` v = `z2ui5.cc` ).

view->ele( `Shell`
    )->ele( `Page`
        )->a( n = `title` v = `abap2UI5 - Soft Keyboard`

        )->tag( n = `InputExt` ns = `z2ui5`
            )->a( n = `value`     v = client->_bind( value )
            )->a( n = `inputMode` v = client->_bind( mode ) ).

client->view_display( view->stringify( ) ).

mode is an ordinary TYPE string attribute of the app. Switching the keyboard is therefore a model update and nothing else:

CASE client->get_event( ).
  WHEN `NUMERIC`.
    mode = `numeric`.
  WHEN `OFF`.
    mode = `none`.
ENDCASE.

No follow-up action travels, and there is no ordering to get right between an action and the next render.

Why it is a property and not an action

inputmode lives on one DOM attribute, and UI5 throws that DOM away on every re-render. A frontend action that writes the attribute therefore holds only until the next thing redraws the field — a model update on the same input included — and nothing reports that it is gone: the field still works, the keyboard just comes back.

InputExt writes the mode on every rendering, so it is part of what the control is. That is also why the mode survives a roundtrip without the app restoring anything.

The frontend action that once wrote the attribute directly is gone for exactly this reason — see Deprecations.

An unknown mode is refused, not guessed

inputMode is checked against the HTML keyword list before it is written. A browser silently falls back to its default for a keyword it does not know, which on screen is indistinguishable from the property having had no effect at all — so the control logs the bad value instead and writes nothing.

Working Samples

Complete apps from the sample catalog that use what this page describes. Each is a single class in abap2UI5/samples unless its row names another of the three sample repositories — pull that repository with abapGit and start the class with ?app_start=<class>.

Sample	Class
Keyboard Layout of an Input (inputmode) (C)	Z2UI5_CL_SMP_APP_516
Scan Field with Submit (InputExt) (A,C)	Z2UI5_CL_SMP_APP_530