Web Services Guide : Cookbook : How to Make Web Service Requests That Affect A User Interface
How to Make Web Service Requests That Affect A User Interface
The Web Service requests should not be made on the UI process. The UI process should run only operations which affect the widgets. The recommended design for a web service application which needs to perform lengthy operations to get data with which to refresh widgets is to perform that operation on another process and then use asyncExecInUI: or syncExecInUI: to update the widgets when the necessary data is retrieved. The reason for this is that any method that sends 'wait' (either explicitly or implicitly) will lock the UI. Further, if the receiver of the 'wait' message is Delay, then it is quite possible that the wait will be done as a spin-loop (causing the 100% CPU).
For instance the following Smalltalk code snippets can be used to call a web service.
[
"web services call"
CwAppContext default asyncExecInUI: [
"code to update the UI with the results of the web services call"
]
] fork.
Or
[
"web services call"
CwAppContext default syncExecInUI: [
"code to update the UI with the results of the web services call"
]
] fork.
 
Finally,
[
" web services call "
} fork
Sample code snippet
The methods beginning with execLongOperation like EtWindow>>#execLongOperation:message:allowCancel:showProgress: should not be used since they belong to the development image and should not be packaged into a runtime image. However, they do demonstrate the proper technique.
Last modified date: 08/16/2019