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: