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:

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.

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>.