Async reading of ResponseBody

[anaisbetts]

Hey guys, I'm coding up a ModernHttpClient adapter for OkHttp 2.0 and had a question.

So far, the new API is way cleaner to use, but one thing I'm not sure that I grok is the scope of ResponseBody's underlying stream. It seems that as soon as I leave onResponse, I either crash inside Okio, or receive an IOException back that the stream is closed. The straightforward code passes the byteStream result back to the caller (wrapped in a C# type), who then proceeds to read it on a separate thread - this dies.

It seems as if I can read the bytes out immediately after receiving the Response object synchronously, but this breaks the abstraction above it, which expects to be handed an object representing the headers + a Stream that the caller can read at its leisure.

I looked through the test suite but didn't see any uses of byteStream that weren't synchronous reads.

This also might be a Xamarin Thing™, definitely don't rule that out yet either :)

[swankjesse]

I've got to document that you cannot consume the response body after onResponse() returns. In this case your best bet is to do your own threading: Call.execute() instead of Call.enqueue().

Alternately, we let you consume the response body anywhere. That's pretty straightforward actually, though it means applications must call close() when they're done.

[anaisbetts]

I've got to document that you cannot consume the response body after onResponse() returns.

That kind of kneecaps the async part of the API though, if you have to then block on a thread to read the response.

Alternately, we let you consume the response body anywhere. That's pretty straightforward actually, though it means applications must call close() when they're done.

That's not a big deal, I was assuming I'd have to do this anyways. The synchronous "Give me all the bytes" method can handle closing too, so only people who want the extra complexity have to think about the close

[swankjesse]

#913

[anaisbetts]

Nice, thanks @swankjesse!