Gau-Yi / google-api-java-client

Automatically exported from code.google.com/p/google-api-java-client
0 stars 0 forks source link

HttpRequest.executeAsync #151

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
External references, such as a standards document, or specification?

N/A

Java environments (e.g. Java 6, Android 2.3, App Engine 1.4.2, or All)?

All

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/cli
ent/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
         }
       }
    });
  }

Original issue reported on code.google.com by yan...@google.com on 19 Mar 2011 at 9:07

GoogleCodeExporter commented 9 years ago
+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/

Original comment by imjas...@gmail.com on 19 Mar 2011 at 10:11

GoogleCodeExporter commented 9 years ago
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().

Original comment by yan...@google.com on 20 Mar 2011 at 2:38

GoogleCodeExporter commented 9 years ago
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 comment by ai...@google.com on 21 Mar 2011 at 12:53

GoogleCodeExporter commented 9 years ago

Original comment by yan...@google.com on 30 Mar 2011 at 7:50

GoogleCodeExporter commented 9 years ago
Moved to:
http://code.google.com/p/google-http-java-client/issues/detail?id=2

Original comment by yan...@google.com on 11 May 2011 at 3:34