Should I use OkHttp with Volley library?-open source projects square/okhttp

I don’t know.

But I am in a similar position and I am coming down on the side of “no, not for now.” I have some ideas though, I’ll elaborate:

I haven’t found any real benefits to using OkHttp underneath Volley for my use. (The HTTPS servers I connect to don’t support SPDY, and I know I’m already getting connection pooling and I believe also gzip encoding, and I know Volley has a working cache in it.) And it adds another few hundred K to the app which can only hurt performance, I believe.

What OkHttp does have, that Volley could be changed to make use of, is real connection aborting. This is what interests me the most, because my app makes a lot of requests, and cancels a lot of them as well. Right now Volley does not actually stop a request that has made it all the way to opening a connection (or thereabouts), it just marks it canceled and throws away the server response.

This is fine for semantics, but has serious performance implications in my case. Specifically, if I make a bunch of requests to a dying server, and those requests are going to time out, it will take Volley something like 30 seconds apiece to time those out, during which time other queued requests are unable to make use of the network connection because the pool is busy waiting on timing out connections.

So what I am thinking is that it would be great to write an “OkHttpStack” and plumb the #cancel() event down to OkHttp and actually abort the connection, that would be a big win for me.

FWIW, on the Android 4.4 phones I’ve looked at they all use OkHttp implementation of HTTPUrlConnection, and you get that ‘for free’ moving forward.