Updated: December 19, 2016

Handling Busy States

Intro

This article describes how to handle the busy state in SAP Fiori apps in general. You can set a busy indicator locally at control level (for example, on a page or for a button) using a busy state, or set it globally using the busy dialog. In SAP Fiori, the aim is to keep the blocking of UIs to a minimum, and to unblock areas where user interaction is possible. Because response time depends on available bandwidth and server performance, unblocking can take a second or more. In this case, we need to inform the user that the process is ongoing.

Usage

Busy indicators are used in the following areas:

  • Initial page loading
  • Dynamic fields and forms (asynchronous loading of fields based on user preselection)
  • Lazy loading of content, for example, in lists and tables
  • Searching and filtering, for example, lists, tables, and global searches
  • Primary actions such as Save, Update, and Delete
  • Deleting and updating lists or modifying tables
  • Partial loading of content

Setting the Busy State

The challenge here is to decide at what level and when the busy state needs to be set. The options are as follows:

  • Show the entire UI as busy (including SAP Fiori launchpad shell) using a busy dialog
  • Set a busy state at control level (for example, on a page or for a button)

To make the right decision, we first need to understand how a page or app is loaded.

In this example, we will use the reference app “Manage Products”, based on the split-screen layout.  We will also assume that the necessary data for labels, tables, and so on is loaded asynchronously, and that the mapping is done via binding.

The app is launched from a tile on the home page. The “flower” animation is shown until the initial application data is available.

Flower animation to indicate busy state
Flower animation to indicate busy state

First, the UI description and metadata are loaded. This is the minimum for a basic functional UI. Until this data is available, the app UI needs to be blocked. In this case, we set the busy state from the split-screen layout control (sap.m.SplitApp).

Do not use the busy dialog to block the entire UI. Otherwise, this would also affect the shell bar, and the user would not be able to access shell features such as Sign Out or Search.

Handling busy states in a split-screen app (at app level)
Handling busy states in a split-screen app (at app level)

Once the metadata has been loaded, we can partially unblock the UI where it makes sense.

The busy state is set for the master list and the details area until the data has been loaded.

Handling busy states in a split-screen app (at app level)
Handling busy states in a split-screen app (at app level)

Once the data for the master list area is available, the busy state is removed. Because the data for the details area is loaded asynchronously, its busy state is set separately.

Handling busy states in a split-screen app (at app level)
Handling busy states in a split-screen app (at app level)

Guidelines

  • Only use the busy dialog if you do not want to allow the user to use the shell, for example, to navigate to the home page. In some cases, long-running processes require the user to be informed about the result in order to continue, for example, to a second step.
  • If multiple busy indicators overlap, the SAPUI5 framework ensures that only the one at the uppermost level is shown.

  • Do not use the busy dialog for app or page loading. Set the busy state at app level.

Resources

Want to dive deeper? Follow the links below to find out more about related controls, the SAPUI5 implementation, and the visual design.

Elements and Controls

Implementation