GWT:将阻止调用替换为异步 RPC



我正在将原生Java应用程序转换为GWT。与服务器的通信仅在状态更改期间发生,到目前为止一直由阻塞操作处理。

例如,当前同步逻辑:

void onUserClickedSync() {
    downloadData(); // blocking operation
    uploadData(); // blocking operation
    setState(DONE);
}

如何用利用异步回调的操作替换阻塞操作?

我目前的想法是基本上添加一堆额外的"忙碌"状态,这些状态什么都不做。然后,我将使用 RPC 的回调来触发下一个状态,在该状态中,逻辑可以继续。

例如,同步逻辑将变为:

void onUserClickedSync() {
    rpc.downloadData(new AsyncCallback<Data> {
        public void onSuccess(Data result) {
            //...
            onDownloaded();
        }
        //...
    });
    setState(WAITING_FOR_DOWNLOAD);
}
void onDownloaded() {
    rpc.uploadData(new AsyncCallback<Void> {
        public void onSuccess(Void void) {
            //...
            setState(DONE);
        }
    //...
    });
    setState(WAITING_FOR_UPLOAD);
}

这种方法有效吗?有什么需要注意的吗?

编辑:用伪代码重写了我的例子,因为它们非常不清楚。

好的,很抱歉用问题缠着你,但这个例子对我来说不太清楚。

现在我更好地处理了这种情况,是的,我认为你的方法是可行的。请注意,当回调更改系统状态时,没有可能与同时发生的其他事件发生冲突的"副作用"。

具体来说,不清楚您是否可能"等待多个回调"(即用户开始 4 次上传,因此您可能会收到 4 次回调,不一定是"正确的顺序")。另外,上传数据方法是否有可能在相应的下载数据之前结束?

一般来说,你必须小心,因为虽然你以前的代码为了可预测性而牺牲了响应能力(例如,在第一次下载完成之前什么都不会发生),但现在事情以更不可预测的顺序发生,你有时可能会引入一些微妙的错误,这些错误很难正确诊断或重现。

我们看不到应用程序的其余部分,所以不太清楚回调之间还会发生什么,但我敦促你对此非常小心,并使回调错误处理特别健壮(即,如果上传中途失败会发生什么?你是否仍然收到来自服务器的回调,告诉你它中止了?然后你移动到什么状态?)

在设计用于远程交互的接口时,通常应使操作尽可能粗粒度,以减少延迟。

特别是,您可以将"下载"和"上传"合并到单个操作中。这样,您可以将延迟减少到单次往返,并消除多个等待状态。

最新更新