事件发生后退出功能

发布于 2024-11-19 10:26:04 字数 363 浏览 2 评论 0原文

我想要有自己的初始化函数,并且我希望它仅在 onload 事件之后退出,我该怎么办?

var qqq=0;
function init(){
    var requestClient= Ti.Network.createHTTPClient();
    requestClient.open('GET','https://mysite.com/api/123/id/5/friends');
        requestClient.onload = function() {
            alert('loaded');
        };
    requestClient.send();
};
init();
alert(qqq);

I want to have my own initialization function, and I want it exit only after onload event, what can I do for it?

var qqq=0;
function init(){
    var requestClient= Ti.Network.createHTTPClient();
    requestClient.open('GET','https://mysite.com/api/123/id/5/friends');
        requestClient.onload = function() {
            alert('loaded');
        };
    requestClient.send();
};
init();
alert(qqq);

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

∞琼窗梦回ˉ 2024-11-26 10:26:04

好吧,您可以通过使请求同步而不是异步来做到这一点。这会对用户的浏览体验产生令人不快的副作用,往往会在请求期间锁定内容,但是如果您设置 open的第三个参数为false,它将使其同步而不是异步:

var qqq=0;
function init(){
    var requestClient= Ti.Network.createHTTPClient();
    requestClient.open('GET','https://mysite.com/api/123/id/5/friends', false);
                                                           // Here------^
        requestClient.onload = function() {
            alert('loaded');
        };
    requestClient.send();
};
init();
alert(qqq);

同步请求将带来JavaScript执行在页面上(位于至少,在许多浏览器中不仅仅是 JavaScript)会突然停止,直到网络操作完成。

但是通常的做法是让您的 init 接受您在 onload 处理程序中调用的回调,因为这可以带来更好的用户体验:

var qqq=0;
function init(callback){  // <== Accept a callback
    var requestClient= Ti.Network.createHTTPClient();
    requestClient.open('GET','https://mysite.com/api/123/id/5/friends');
        requestClient.onload = function() {
            alert('loaded');
            callback();   // <== Call the callback
        };
    requestClient.send();
};
init(function() {         // <== Pass the callback into `init`
    alert(qqq);
});

有效的网络编程就是拥抱它的事件驱动的本质。我强烈推荐第二个例子。

Well, you can do that, by making the request synchronous instead of asynchronous. This has unpleasant side-effects on the user's browsing experience, tending to lock things up during the request, but if you set open's third argument to false, it will make it synchronous instead of asynchronous:

var qqq=0;
function init(){
    var requestClient= Ti.Network.createHTTPClient();
    requestClient.open('GET','https://mysite.com/api/123/id/5/friends', false);
                                                           // Here------^
        requestClient.onload = function() {
            alert('loaded');
        };
    requestClient.send();
};
init();
alert(qqq);

A synchronous request will bring the JavaScript execution on the page (at least, and in many browsers rather more than just the JavaScript) to a screeching halt until the network operation completes.

But the usual practice is to have your init accept a callback you call from within the onload handler, as this makes for a much better UX:

var qqq=0;
function init(callback){  // <== Accept a callback
    var requestClient= Ti.Network.createHTTPClient();
    requestClient.open('GET','https://mysite.com/api/123/id/5/friends');
        requestClient.onload = function() {
            alert('loaded');
            callback();   // <== Call the callback
        };
    requestClient.send();
};
init(function() {         // <== Pass the callback into `init`
    alert(qqq);
});

Effective web programming is about embracing the event-driven nature of it. I'd strongly recommend the second example.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文