-
Notifications
You must be signed in to change notification settings - Fork 452
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Asynchronous requests #2
Comments
From [email protected] on June 01, 2011 08:14:18 Labels: -Milestone-Version1.5.0 Milestone-Version1.6.0 |
From [email protected] on October 04, 2011 10:28:23 Owner: [email protected] |
From [email protected] on February 28, 2012 17:13:52 Labels: Milestone-Version1.8.0 |
From [email protected] on March 27, 2012 07:22:33 Labels: Milestone-Version1.9.0 |
From [email protected] on May 14, 2012 07:14:06 Labels: -Milestone-Version1.9.0 Milestone-Version1.10.0 |
From [email protected] on May 24, 2012 05:33:00 Labels: -Milestone-Version1.10.0 Milestone-Version1.11.0 |
From [email protected] on August 02, 2012 07:30:23 Cc: [email protected] |
From [email protected] on September 27, 2012 18:33:10 See also David Chandler's HTTP library that provides async support on Android: http://turbomanage.wordpress.com/2012/06/12/a-basic-http-client-for-android-and-more/ Labels: -Priority-Medium Priority-High |
From [email protected] on October 01, 2012 19:35:10 Owner: [email protected] |
From [email protected] on January 24, 2013 05:51:19 Labels: Milestone-Version2.1.0 |
From [email protected] on February 06, 2013 15:54:01 Labels: -Milestone-Version2.1.0 Milestone-Version1.16.0 |
From [email protected] on June 10, 2013 06:07:42 Labels: -Milestone-Version1.16.0 Milestone-Version1.17.0 |
From [email protected] on July 29, 2013 10:33:52 |
From [email protected] on August 13, 2013 03:01:53 Owner: [email protected] |
From [email protected] on August 19, 2013 13:18:12 Labels: -Milestone-Version1.17.0 Milestone-Version1.18.0 |
From [email protected] on September 27, 2013 04:55:23 Labels: -Milestone-Version1.18.0 |
From [email protected] 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
}
}
}
Comment 1 by [email protected], 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 [email protected], 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 [email protected], 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
The text was updated successfully, but these errors were encountered: