From yan...@google.com on May 11, 2011 08:33:21

Copied from previous project from: https://code.google.com/p/google-api-java-client/issues/detail?id=151 Please describe the feature requested. It would be nice to provide an executeAsync method in HttpRequest that started a new thread to execute the request and when it got the final response would call an implementation of an HttpAsyncCallback interface similar to the one in GWT: http://google-web-toolkit.googlecode.com/svn/javadoc/2.2/com/google/gwt/user/client/rpc/AsyncCallback.html Sample usage:

public static void run(HttpRequest request) {
request.executeAsync(new HttpAsyncCallback() {
public void onSuccess(HttpResponse response) {
if (response.isSuccessStatusCode) {
// server sent a success response
} else {
// server sent an error response
}
}

   public void onFailure(Throwable caught) {
     // Convenient way to find out which exception was thrown.
     try {
       throw caught;
     } catch (IOException e) {
       // some networking problem?
     } catch (Throwable e) {
       // last resort -- a very unexpected exception
     }
   }
});

}

Comment 1 by imjas...@gmail.com, Mar 19, 2011

+1 on the feature, I think it would be nice to provide this.

A couple comments on the sample usage as it is:

1.) onSuccess() gives you a response, which you then have to check for whether or not it was actually a success? Maybe it should be called onResponse() if it's not actually going to be a sign of success.

2.) I would argue that re-throwing the Throwable and catching it to find out what it was is not very convenient. Try/catch blocks should not be a control flow mechanism, they should be an error handling mechanism. It might be better to have instanceof check, but even that feels a little gross.

Also, for brevity, it might be nice to provide an abstract class, DefaultCallback, that implements onFailure() in a default way, so that developers don't have to write both branches for every request. This may be a recommendation for samples more than a recommendation for the library itself, since "the default way" might depend a lot on the environment, but either way I thought I'd mention it.

Also (also), for App Engine, since you can't spawn threads, you could use an asynchronous urlfetch as described here: http://ikaisays.com/2010/06/29/using-asynchronous-urlfetch-on-java-app-engine/ Comment 2 by project member yan...@google.com, Mar 19, 2011

Thanks for the feedback!

I agree with the onResponse() name. That makes more sense.

The most interesting question is what to do about this for App Engine. executeAsync as outlined here just wouldn't work with fetchAsync since that uses a Future. I suppose we could still have executeAsync but throw an exception on App Engine.

Alternatively, we could use a Future-style interface like App Engine has, e.g.:

public class HttpRequest {
public Future fetchAsync();
}

and provide a way to override the behavior in the HttpTransport such that UrlFetchTransport would use URLFetchService.fetchAsync().

Comment 3 by project member ai...@google.com, Mar 20, 2011

while we're doing this reconfiguration, maybe it's time to think about streaming
as well. The async callbacks would be

OnFailure - called immediately if you get an error return
OnHeaders(HttpResponse response) - called with all the header data
OnData(HttpRespose response, byte [] data, length) - on each successive chunk of data.
OnSuccess(HttpResposne response) - when we are finally done.

An app could get away with just OnFailure and OnSuccess, but an app that
did streaming responses could start parsing the JSON as it arrives.

-tony

Original issue: http://code.google.com/p/google-http-java-client/issues/detail?id=2