Question
From: Wang, Jerry
Sent: Friday, 19 June, 2015 4:31 PM
Subject: RE: [Follow up] Why the synchronous request did not BLOCK the UI
Hi all,
这个issue很有意思，昨天和德国同事开会时，他们问我们为什么我们code里写的odata request是同步的，但是并没有block 住UI。当时我没答上来，因为确实我看起来也是没block UI。
今天我做了研究，通过图表和视频 理直气壮地告诉他们：代码没问题，是我们眼睛犯错了。视频在下面的share folder里。研究思路在下面的邮件里。
Please read more detail from Jerry’s mail.
Jerry’s analysis process
手动在后台reques响应里加上一个延时，来模拟后台耗时很长的scenario.
Then I test in UI with this modified Odata implementation. Now as expected it took around 13 seconds to get the returned image url.
During this timeframe, UI is completely freezed: end user does not have any chances to click anything in UI.
Synchronous mode
Afterwards the synchronous behavior is quite obvious now. I click one item in navigation list to trigger the synchronous request for Image url retrieval. And after that, I cannot do any operation on UI - it is completely freezed.
Please refer to attached video “synchronous.wmv”.
Asynchronous mode
Then I change the manual latency to 20 seconds and retest the UI.
Now every time I click one opportunity in the navigation list, still one http request for image logo is sent out. Compared with synchronous mode, this time the UI is not blocked - I can continue to work on UI without waiting for the response.
This asynchronous behavior could also easily be found in the timechart in Chrome network: