How to make synchronous call to server in GWT

[sac]

Hi All ,
I had made two client side classes , in which i used to
call the method of second class , in this method i have to give
synchronous call to server . because if we give asynchronous call to
server then this method get completed before the response from the
server came and my objects remain uninitialized because they will
initialized after the response from the server .

If any body know how to give synchronous call to server in GWT
please tell me

Thanks with Regards
Sachin Jain.

[Magno Machado]

What about initialize your objects in the AsyncCallback.onSuccess event?

Anyway, I think it will work as you want:
Implement a method in your AsyncCallback implementation that returns a boolean. This method returns a flag that is set to true only when the asynchronous call has returned, and your call will be something like this:
myService.doSomething(arguments, arguments, myAsyncCallback);
while (!myAsyncCallback.finished()) {}

But I'm not sure if this is a good practice.

2007/9/26, sac < sachin.j...@gmail.com>:

[Bruce Johnson]

Unfortunately, the loop would run forever. Since JS is single-threaded, XHR (XmlHttpRequest, the underlying comm mechanism) calls can never get dispatched until the event handler returns. In other words, it is literally impossible to fake synchronous calls in this way.

There is a mode for XHR that lets you do synchronous interaction, but it is Evil. It locks up the browser chrome, removing the user from control. Plus, blocking calls are Evil for UIs anyway: if a call takes longer than a few hundred milliseconds, the user is going to want at least a little bit of UI notification of what's happening.

Like event-driven programming vs. old-school polling, async is fundamental to designing effective web UIs.

[Thomas]

You really can't. The easy way out is to have the request be made,
then sleep in a loop waiting for an event object or bool. On
response, set the bool to true, and have the loop check for it. Yes,
Javascript is single threaded, however, sleeps are simulated by using
a timer which literally causes the code to stop executing, and
continue after the timer has been fired.

This is an off the cuff quick and dirty. The better way would be to
write you applications to assume that the object may not be ready yet,
and not use the object untill it is ready. During this process,
display a 'Loading, Please Wait' or something.

Thomas

[Reinier Zwitserloot]

None of the answers I've seen so far really nail the issue here.

1) You CANNOT DO SYNCHRONOUS CALLS.

2) Trying to fake it so it feels a bit like one doesn't work, because,
you CANNOT DO SYNCHRONOUS CALLS.

There are workarounds. There are hacks. None of them are reliable.
Don't use them.

The solution is simple in one way, and very complex in another: Get
used to thinking in terms of events. For some this is natural, for
others it takes a little work. The act of completing the call is an
event. On receiving this event, you make the second call. Hopefully
that makes complete sense to you. In practice this would mean you put
the code for the second call inside the onSuccess of the first (as
that's the 'event hook' - the code that gets called to signal the
event's occurrence). Probably you want to offload this to a separate
method lest you find yourself tabbing 20 lines in. That would be bad.

NB: Thomas' suggestion does work in theory, but in practice it's a
giant waste of CPU cycles. This is actually important in javascript
land, as everything will feel slightly to extremely sluggish depending
on how many of those loops are going on, how complex your DOM is, and
how fast your user's computer is, and what browser they use.

NB2: If your problem is that some future code needs to be triggered
ONLY after both calls complete, keep boolean flags for both around,
and call a 'checkup' method from both onSuccess calls, which just does
nothing and returns unless both booleans have been set.

[Peter Blazejewicz]

Hi Reinier,

On Sep 27, 5:40 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> None of the answers I've seen so far really nail the issue here.
> 1) You CANNOT DO SYNCHRONOUS CALLS.
> 2) Trying to fake it so it feels a bit like one doesn't work, because,
> you CANNOT DO SYNCHRONOUS CALLS.

we the poeple can make synchronous requests:
http://ajaxpatterns.org/XMLHttpRequest_Call
.
gwt toolkit impementation forces asynchronous execution,
Synchronous execution is BAD thing simply in current browsers:
http://www.oreillynet.com/xml/blog/2007/01/do_sync_calls_freeze_browsers.html

regards,
Peter

[Thos]

While you can't / shouldn't make the calls synchronous you can chain
together anonymous classes to get do get things to execute in
sequence. I'm not sure I fully understand what the original question
is saying about the nature of the code problem but here's some sample
code of what I'm suggesting.

public void doSomething (final MyServiceAsync service) {

doSomeStuff();

service.fetchSomething(new AsyncCallback(){
public void onFailure(Throwable caught) {
RootPanel.get().add(new Label(caught.getMessage()));
}

public void onSuccess(Object result) {
final MyObject myObject = (MyObject)result;
doSomeOtherStuff(myObject);

service.fetchSomethingElse(new AsyncCallback(){
public void onFailure(Throwable caught) {
RootPanel.get().add(new
Label(caught.getMessage()));
}

public void onSuccess(Object result) {
MyOtherObject myOtherObject =
(MyOtherObject)result;
finishUpWhateverIWasDoing(myOtherObject);
}
});
}
});
}

Please note this is not an example of how one should do error handling!

[mP]

Technically you can do sync ajax requests but as RZ has explained its
never a good idea. If your server is really slow the browser will lock
up for just as long. This is never a good thing.

[Reinier Zwitserloot]

Peter, as I said, there are hacks, workarounds, and other things, and
you should never use them because they are a BAD idea. Between GWT-
compatible browsers, so far there is at least 1 that does really dumb
things with a synchronous AJAX calls. Like freeze up completely if
your server is slow or some proxy or other drops a packet too many.
That would be a bad thing.

GWT doesn't allow sync calls because there's no way (or at least no
easy way and no one has come up with a good proposal that emulates it
somehow) to 'get it right' on all GWT-compatible browsers.

I'm aware that it's simply a side-effect of current browser
implementations, but 99.9995% of all GWT decisions are made simply
because 'current browsers suck'. That's what GWT is for, in fact.
Eliminate a lot of those idiosyncracies. If I had to caveat every
advice I gave with 'but in a perfect world we could all just do this
and it would work', you'd all get very bored very quickly.

[Peter Blazejewicz]

hi Reinier,

On Sep 29, 6:43 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> Peter, as I said, there are hacks, workarounds, and other things, and
> you should never use them because they are a BAD idea.

I think I posted the same:
On Sep 27, 9:55 pm, Peter Blazejewicz <peter.blazejew...@gmail.com>
wrote:
> Synchronous execution is BAD thing simply in current browsers:http://www.oreillynet.com/xml/blog/2007/01/do_sync_calls_freeze_brows...
;)
regards,
Peter

[Thomas]

On Sep 27, 11:40 am, Reinier Zwitserloot <reini...@gmail.com> wrote:
> None of the answers I've seen so far really nail the issue here.

> NB: Thomas' suggestion does work in theory, but in practice it's a
> giant waste of CPU cycles. This is actually important in javascript
> land, as everything will feel slightly to extremely sluggish depending
> on how many of those loops are going on, how complex your DOM is, and
> how fast your user's computer is, and what browser they use.

Hehe, correct. I hope the suggestion didn't infer I recommended the
approach. It was simply a way to perform a sync request without it
actually being sync. :-) A 'fake out' so to speak. I was assuming
he'd use a sleep time of something like a second or some other crude
number.

Thomas