Sent: Thursday, June 18, 2015 4:50 PM

研究一下进入MY OPPORTUNITY的时候，BUSY INDICATOR为什么消失的很晚（似乎是LIST和DETAIL都好了后才消失）

概括地说，Ross描述的busy dialog在LIST和DETAIL的数据都回来了才消失的，这个behavior是working as designed的。具体看下面的代码。

为了更深入理解busy dialog，可以看附件两个视频。

我在Opp header ETAG的后台实现里加了一个10s的延时。

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

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

这个busy dialog实际上也是一种保护措施。如果UI上某些操作必须依赖于最新的ETAG，采用这种方式可以让user同步的ETAG请求返回UI之前就能够进行操作，会造成state的inconsistency。

Key message we could find in the source code:

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.

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–.

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

Take the process to open Opportunity tile as example.

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

request url:

And connectionManager is responsible to call requireBusyDialog:

iRequiredCount changed from 0 to 1:

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

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

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

iRequiredCount changes from 3 to 2:

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

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

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

now busy dialog is closed: