General Concepts Handling Busy States

Updated: December 19, 2016
SAPUI5 Version 1.36

Handling Busy States

Intro

This article describes how to handle the busy state in SAP Fiori apps in general. The busy indicator can be set locally at control level (for example, on a page or for a button) using a busy state, or it can be set 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 the user can already carry out interaction. 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:

  • The entire UI (including SAP Fiori launchpad shell) using a busy dialog
  • At control level (for example, on a page or for a button) using a busy state

To make the right decision here, 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 first data of the application is available.

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

First the UI description and metadata is loaded. This is the minimum status needed to have at least 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, and the user would not be able to access shell features like Logout and 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. In this example, the master area is unblocked so that the user can search while the initial list is still loading.

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 list and the header information for the details are available, the busy states are removed. Because the data for the line items is loaded asynchronously, the busy state is set separately on the table control.

 

 

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