Make Request.finish public

[google]

Make Request.finish public

[jpd236]

I'd generally be wary of making internal methods like this public because it'd be easy to misuse them by mistake.

Do you have more details on why you want a custom implementation of ResponseDelivery (e.g. what the default one doesn't offer)? Would it work to use a ExecutorDelivery delegate and add hooks as needed before delegating the method calls?

[jason-watkins]

Okay, so context. We are using a code-genned REST API client as part of and Android app. The generated client uses Volley internally to make requests using futures.

The issue we are having is that the client calls RequestFuture.get before the request completes. While executing RequestFuture.get on the main thread, the Request is executed successfully on a background thread, and the result is posted back to the main thread. This doesn't work, since the posted response is processed after the RequestFuture.get method returns claiming a timeout error.

In typing the above out, it occurs to me that we can specify a different handler to process the response on another thread, but I still don't understand the expected workflow for volley here. Ideally I would want the requesting thread to handle the work done by ResponseDeliveryRunnable . I'm not getting the rational for doing that work on some other thread.

[jpd236]

Thank for the context.

Calling RequestFuture#get on the main thread is almost certainly not the right thing to do unless you know the request is done - doing so will block the main thread on a network request completing which can take arbitrarily long and thus freeze your UI.

So why is this code using RequestFuture? If you just want your callbacks to be invoked on the main thread when the request is done, use a regular Volley Request subclass and provide it the listener/error listener to use.

[jason-watkins]

The reason for any of this is that I am really the developer of the REST server, and our hope was that the codegen'd client would work well enough that we could point users to the code generator and not need to directly support client libraries in various languages.

In any case, it seems that our issues have more to do with the code generator than Volley itself.

Thanks for the feedback.