Adapting Applications to Different Device Types

Objective

After completing this lesson, you will be able to use a device model to adapt applications to different device types.

Controls with Built-In Device Adaptation

SAPUI5 comes with several controls that are already able to react to the available screen real estate and resolution by themselves. Some require particular properties to be set, and with some, everything just works out of the box.

Such controls with built-in device adaptation are for example sap.m.SplitApp, sap.m.ResponsivePopover, sap.m.OverflowToolbar, and sap.m.PullToRefresh.

The forms sap.ui.layout.form.SimpleForm and sap.ui.layout.form.Form can also adapt to the available screen size. It is recommended to set the sap.ui.layout.form.ColumnLayout for them, as its responsiveness allows the available space to be used in the best way possible.

XML table definition with responsive attributes for columns. Desktop and tablet display shows Customer Name, City, and Email in table format. Phone display shows Customer Name and Email in a stacked list.

One control that is widely used across all kinds of different applications is sap.m.Table (also called the "Responsive Table"), which has several features you can use for device adaptation. On smaller devices, for example, you can set certain properties that will make particular columns pop in instead of being displayed as a normal column, or show and hide columns completely.

For example, you can set a minScreenWidth for the columns. This will cause columns to only show up if a certain screen width is matched. You can define this minScreenWidth in px or rem, but here you can also use the standard categories that come from the Device API (Phone, Tablet, or Desktop). Setting the additional property demandPopin to true for a column will also react to the minScreenWidth you specify. In such a case, the column will be shown as a popin on smaller screens, instead of being completely hidden.

In the example in the figure Responsive Table, three columns are defined in an XML view for a sap.m.Table: Customer Name, City and Email.

No minScreenWidth attribute is set for the Customer Name column. It is therefore displayed on all device types, i.e. desktops, tablets and phones.

For the City column, the minScreenWidth="Tablet" attribute is specified. This column is therefore displayed only on tablets and desktops, but not on phones.

In the Email column, the attribute demandPopin="true" has been added to the attribute minScreenWidth="Tablet". As a result, this column does not disappear completely on phones, but is displayed there as a popin (see the figure). On tablets and desktops, the Email column is displayed in the same way as the City column.

Device Model

Instantiating a Device Model

Depending on the capabilities of the device running an application, the functionality and design of an application may vary.

For example, on a desktop device, it is not necessary to display a back button on a detail view in a list-detail scenario because the list and detail views are displayed simultaneously. On a phone, on the other hand, where there is navigation between list and detail view, such a back button is required. To control the visibility of the back button, a device model can be used.

A device model is based on the Device API (sap.ui.Device). This API provides information about device specifics, like the operating system along with its version, the browser and browser version, screen size, current orientation and support for specific features such as, touch event support, orientation change, and so on. For more information, see the API reference for the sap.ui.Device namespace.

With a device model, you can make most properties of the Device API available as a JSON model.

Sample device model code in the component.js file, as described in the following text.

Typically, a device model is created in the initialization method of the component controller Component.js, as shown in the figure Creating a Device Model in the Component Controller.

To create a device model, dependencies to modules sap/ui/Device and sap/ui/model/json/JSONModel are added to the component controller. The device model is then instantiated in the controller's initialization method by simply passing the loaded Device module to the constructor function of the JSON model. The binding mode is set to OneWay since the device model is read-only. The device model is set as a named model (name: device) for the component.

Using a Device Model

Sample binding control properties, as described in the following text.

After the device model has been created, the properties from the Device API (such as /system/desktop) can be used in the data binding to adapt controls to the current platform. The figure, Binding Control Properties to Device Capabilities, shows some examples of how this is achieved.

Note

Do not forget to prefix the binding path with the name of the device model ("device") plus a ">" character.

If property values from the Device API are to be negated, the expression binding syntax can be used as shown in the figure.