Overview of action views on mobile devices

This is a short overview about action view rendering with the front-ends for mobile devices.

Action views on mobile in Native Rendering and Universal Rendering mode

Action view rendering will depend on the Native Rendering mode versus Universal Rendering mode.

  • When using the Native Rendering mode, action views are rendered by GMA and GMI frond-ends with native platform widgets, as described in the next topics.
  • When using the Universal Rendering mode, action views are rendered with GBC front-end rules.

Action view rendering on mobile

The top and/or bottom part of the app screen can be used to place action views (UI button controls).

Key functions of these areas:
  • Make important actions prominent and accessible in a predictable way (such as New or Search).
  • Support consistent navigation and view switching within apps.
  • Reduce clutter by providing an action overflow for less-used actions.
  • Provide a dedicated space for giving your app an identity with text and/or an image.
How actions are rendered on the mobile device depends on:
  • The order of the ON ACTION statements in the current dialog of the running app.
  • The type of platform (Android™/iOS).
  • The type (phone/tablet) and orientation of the device.
  • The usage of Native Rendering or Universal Rendering mode.
Actions are mapped to the Android or iOS platform in a specific way, following the platform standard.

Actions can be programmatically enabled and disabled, and hidden and shown.

The text, image and other properties of the action can be controlled with action attributes.

GUI elements to trigger actions on mobile devices

In the Native Rendering mode, each mobile platform provides its own standard to display action triggers.

GMA and GMI follow respectively the Android and iOS standards:

Decorating action views on mobile

Actions are typically decorated using the IMAGE or the TEXT action attribute. If these attributes are not defined or if the specified image resource is not available, the mobile front-end uses a default decoration in the Native Rendering mode.

For some actions, the front-end always uses the platform-specific decoration. For example, on iOS devices, the "refresh" action always renders as a typical circular arrow icon.

Well-known actions use a default icon or text corresponding to the mobile platform GUI guidelines. As these follow the mobile OS standards, do not define your own text or icons for common actions such as "accept" or "cancel".

For a complete list of predefined action decorations, see:

The "Back" button on Android devices

In the Native Rendering mode, the physical back button on an Android device is considered a default action view for the "close", "cancel", or "accept" action in the current dialog:
  • If a close action is defined and active, it is assigned to the back button.
  • If no active close action exists in the current dialog, but the cancel action is defined and active, it is assigned to the back button.
  • If neither close nor cancel actions are defined / active, but the accept action is defined and active, it is assigned to the back button.

If accept or cancel cannot be assigned to the back button, a default action view appears in the action panel. For example, if all three actions (close, cancel and accept) exist and are active, the action panel shows a check mark for the accept action and a cross icon for the cancel action, while the back button fires the close action.

The "Back" button on iOS devices

In the Native Rendering mode, the physical back button on an iOS device is considered a default action view for the "close", "cancel", or "accept" action in the current dialog:
  • If a cancel action is defined and active, it is assigned to the back button.
  • If no active cancel action exists in the current dialog, but a close action is defined and active, it is assigned to the back button.
  • If neither close nor cancel actions are defined / active, but accept action is defined and active, it is assigned to the back button.
  • Exception with single DISPLAY ARRAY dialog: The accept action binds by default to the back button if it is not bound as DOUBLECLICK action. This is intentional to match the IOS behavior for simple selection lists.

Default action views rendering with MENU

On mobile devices, the rendering of the MENU dialog depends on whether or not the current window has a form.

If a MENU is active and the current Window has no form, then the MENU is shown as a list of actions.

If a MENU is active and has a FORM, then the menu actions are rendered like all other dialog actions.

Default and toolbar action views with GBC (Universal Rendering)

When using the GBC on mobile with Universal Rendering, the default action views of the action panel, ring menu panel and the toolbar action views are by default displayed in the GBC chromebar, to adapt to mobile device GUI standards.

For more details, see Action views with GBC.