Should I use OkHttp with Volley library?

Question

I am using Volley library in my android app. It works fine, but I saw that OkHttp provides some more improvements also. I have integrated the OkHttp with Volley using :

Volley.newRequestQueue(mCtx.getApplicationContext(), new OkHttpStack());

My OkHttpStack class is :

public class OkHttpStack extends HurlStack {
    private final OkUrlFactory mFactory;

    public OkHttpStack() {
        this(new OkHttpClient());
    }

    public OkHttpStack(OkHttpClient client) {
        if (client == null) {
            throw new NullPointerException("Client must not be null.");
        }
        mFactory = new OkUrlFactory(client);
    }

    @Override protected HttpURLConnection createConnection(URL url) throws IOException {
        return mFactory.open(url);
    }
}

1) Is it worth it? I have not noticed any noticeable improvement, but that may be because I have still not implemented SPDY support on my server.

2) On of the enhancement by OkHttp is response caching. However, volley does that too. Will I have any issues similar to this: https://github.com/square/okhttp/issues/680

3) Also, I am using two RequestQueues in Volley - one for Images & other for JSON. Should I use OkHttp with both queues?

Coster

Answer 1

I recommend you to switch to an stack that does not use okhttp-urlconnection like this one -> https://goo.gl/ZZRSQ5

1) Yes OkHttp has a lot of advantages like speed, HTTP/2, SPDY, saves bandwidth...

2) I haven't had any problem.

3) You only need one com.android.volley.RequestQueue for both. Take a look at this -> https://goo.gl/GMn3Ls

I've written about OkHttp + Volley + Gson here -> https://goo.gl/nl2DfN. I think might be interesting for you.

Alton

Thanks! Nice article. I have been using OkHttp + Volley in my app for some time now and it works nicely. I am adding Gson support to it now. BTW, what is the problem with okhttp-urlconnection? What is the benefit of this: goo.gl/ZZRSQ5 – Coster

Does this stack tie in well with Retrofit? – Smokeless

Retrofit is a DIFERENT stack. I'm not sure I get your question @IgorGanaposlky. – Alton

Answer 2

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.

Hudgens

Actually there is a benefit. If you use Volley by default, you cannot enforce it to use TLS by default on Android 4.3 and below. If you use OkHttp as the custom stack, you can enforce it. – Draggletailed