sap.ca.ui.utils.busydialog scenario discussion

Created by Jerry Wang, last modified on Jun 29, 2015

Key message we could find in the source code:

1. after sap.ca.ui.utils.busydialog.requireBusyDialog() is called in application, we can only see the rotating wheel in UI after 1.5 seconds - defined in BUSYDIALOG_TIMEOUT.

2. the requireBusyDialog and releaseBusyDialog must be called in pair. There is private variable _iRequiredCount maintained inside the implementation. When require function is called, _iRequiredCount++; release for _iRequiredCount--.

3. it is obsolete. New application should use sap.m.BusyDialog instead.


sap.ca.ui.utils.busydialog scenario discussion

Take the process to open Opportunity tile as example.

1. The bindAggregation in S2.controller.js will trigger the Odata request sent to backend:

sap.ca.ui.utils.busydialog scenario discussion

request url:

sap.ca.ui.utils.busydialog scenario discussion

And connectionManager is responsible to call requireBusyDialog:

sap.ca.ui.utils.busydialog scenario discussion

iRequiredCount changed from 0 to 1:

sap.ca.ui.utils.busydialog scenario discussion

2. OpportunityAttachment data is requested. ConnectionManager calls another requireBusyDialog, iRequiredCount changed from 1 tp 2:


sap.ca.ui.utils.busydialog scenario discussion

3. in detail view, ETAG refresh operations makes iRequiredCount changed from 2 to 3:

sap.ca.ui.utils.busydialog scenario discussion

4. At this time, the response of request in step1 has been returned to frontend, ConnectionManager calls releaseBusyDialog:

sap.ca.ui.utils.busydialog scenario discussion

iRequiredCount changes from 3 to 2:

sap.ca.ui.utils.busydialog scenario discussion

Since now iRequiredCount still > 0, the busyDialog will not be closed.

sap.ca.ui.utils.busydialog scenario discussion

5. the response for request in step2 is returnd, iRequiredCount changes from 2 to 1:

sap.ca.ui.utils.busydialog scenario discussion

6. the ETAG request sent in step3 has response now, iRequiredCount changes from 1 to 0:

sap.ca.ui.utils.busydialog scenario discussion

now busy dialog is closed:

sap.ca.ui.utils.busydialog scenario discussion

test1:

 

在header ETAG的implementation里加了一个10秒的时延:测试结果是直到header ETAG的response回来之后,busy dialog才消失。

sap.ca.ui.utils.busydialog scenario discussion

test2:将timeout从默认的1500ms改成30000ms:

sap.ca.ui.utils.BUSYDIALOG_TIMEOUT = 30000;

第一个video timeout_1500.wmv: 虽然list和detail的数据都ready了,但是因为ETAG需要10s才能返回,整个UI被这个ETAG的request造成的busy dialog锁住了,直到10s后UI才能点击

第二个video是把默认的timeout从1500毫秒改成30秒,即busy dialog不会显示。从video里看出UI始终是可操作的,尽管后台的ETAG还没有回来。


上一篇:where is os type and version determined for a ui5 html


下一篇:Shell openSomething - how is application component loaded in the runtime