Two-part question from an iOS developer learning Android, working on an Android project that will make a variety of requests from JSON to image to streaming download of audio and video:
On iOS I have used the AFNetworking project extensively. Is there an equivalent library for Android?
I've read up on OkHTTP and Retrofit by Square, as well as Volley but don't yet have experience developing with them. I'm hoping someone could provide some concrete examples of best use cases for each. From what I've read, seems like OkHTTP is the most robust of the three, and could handle the requirements of this project (mentioned above).
This question is related to
android
networking
retrofit
android-networking
android-webservice
AFNetworking for Android:
Fast Android Networking is here
Fast Android Networking Library supports all types of HTTP/HTTPS request like GET, POST, DELETE, HEAD, PUT, PATCH
Fast Android Networking Library supports downloading any type of file
Fast Android Networking Library supports uploading any type of file (supports multipart upload)
Fast Android Networking Library supports cancelling a request
Fast Android Networking Library supports setting priority to any request (LOW, MEDIUM, HIGH, IMMEDIATE)
Fast Android Networking Library supports RxJava
As it uses OkHttp as a networking layer, it supports:
Fast Android Networking Library supports HTTP/2 support allows all requests to the same host to share a socket
Fast Android Networking Library uses connection pooling which reduces request latency (if HTTP/2 isn’t available)
Transparent GZIP shrinks download sizes
Fast Android Networking Library supports response caching which avoids the network completely for repeat requests
Thanks: The library is created by me
Async HTTP client loopj vs. Volley
The specifics of my project are small HTTP REST requests, every 1-5 minutes.
I using an async HTTP client (1.4.1) for a long time. The performance is better than using the vanilla Apache httpClient or an HTTP URL connection. Anyway, the new version of the library is not working for me: library inter exception cut chain of callbacks.
Reading all answers motivated me to try something new. I have chosen the Volley HTTP library.
After using it for some time, even without tests, I see clearly that the response time is down to 1.5x, 2x Volley.
Maybe Retrofit is better than an async HTTP client? I need to try it. But I'm sure that Volley is not for me.
Adding to the accepted answer and what LOG_TAG said....for Volley to parse your data in a background thread you must subclass Request<YourClassName>
as the onResponse
method is called on the main thread and parsing on the main thread may cause the UI to lag if your response is big.
Read here on how to do that.
I've recently found a lib called ion that brings a little extra to the table.
ion has built-in support for image download integrated with ImageView, JSON (with the help of GSON), files and a very handy UI threading support.
I'm using it on a new project and so far the results have been good. Its use is much simpler than Volley or Retrofit.
And yet another option: https://github.com/apptik/jus
And many other handy features like markers, transformers, etc.
RoboSpice Vs. Volley
From https://groups.google.com/forum/#!topic/robospice/QwVCfY_glOQ
Looking at the Volley perspective here are some advantages for your requirement:
Volley, on one hand, is totally focused on handling individual, small HTTP requests. So if your HTTP request handling has some quirks, Volley probably has a hook for you. If, on the other hand, you have a quirk in your image handling, the only real hook you have is ImageCache. "It’s not nothing, but it’s not a lot!, either". but it has more other advantages like Once you define your requests, using them from within a fragment or activity is painless unlike parallel AsyncTasks
Pros and cons of Volley:
So what’s nice about Volley?
The networking part isn’t just for images. Volley is intended to be an integral part of your back end. For a fresh project based off of a simple REST service, this could be a big win.
NetworkImageView is more aggressive about request cleanup than Picasso, and more conservative in its GC usage patterns. NetworkImageView relies exclusively on strong memory references, and cleans up all request data as soon as a new request is made for an ImageView, or as soon as that ImageView moves offscreen.
Performance. This post won’t evaluate this claim, but they’ve clearly taken some care to be judicious in their memory usage patterns. Volley also makes an effort to batch callbacks to the main thread to reduce context switching.
Volley apparently has futures, too. Check out RequestFuture if you’re interested.
If you’re dealing with high-resolution compressed images, Volley is the only solution here that works well.
Volley can be used with Okhttp (New version of Okhttp supports NIO for better performance )
Volley plays nice with the Activity life cycle.
Problems With Volley:
Since Volley is new, few things are not supported yet, but it's fixed.
Multipart Requests (Solution: https://github.com/vinaysshenoy/enhanced-volley)
status code 201 is taken as an error, Status code from 200 to 207 are successful responses now.(Fixed: https://github.com/Vinayrraj/CustomVolley)
Update: in latest release of Google volley, the 2XX Status codes bug is fixed now!Thanks to Ficus Kirkpatrick!
it's less documented but many of the people are supporting volley in github, java like documentation can be found here. On android developer website, you may find guide for Transmitting Network Data Using Volley. And volley source code can be found at Google Git
To solve/change Redirect Policy of Volley Framework use Volley with OkHTTP (CommonsWare mentioned above)
Also you can read this Comparing Volley's image loading with Picasso
Retrofit:
It's released by Square, This offers very easy to use REST API's (Update: Voila! with NIO support)
Pros of Retrofit:
Compared to Volley, Retrofit's REST API code is brief and provides excellent API documentation and has good support in communities! It is very easy to add into the projects.
We can use it with any serialization library, with error handling.
Update: - There are plenty of very good changes in Retrofit 2.0.0-beta2
Cons of Retrofit for version 1.6:
Memory related error handling functionality is not good (in older versions of Retrofit/OkHttp) not sure if it's improved with the Okio with Java NIO support.
Minimum threading assistance can result call back hell if we use this in an improper way.
(All above Cons have been solved in the new version of Retrofit 2.0 beta)
========================================================================
Update:
Android Async vs Volley vs Retrofit performance benchmarks (milliseconds, lower value is better):
(FYI above Retrofit Benchmarks info will improve with java NIO support because the new version of OKhttp is dependent on NIO Okio library)
In all three tests with varying repeats (1 – 25 times), Volley was anywhere from 50% to 75% faster. Retrofit clocked in at an impressive 50% to 90% faster than the AsyncTasks, hitting the same endpoint the same number of times. On the Dashboard test suite, this translated into loading/parsing the data several seconds faster. That is a massive real-world difference. In order to make the tests fair, the times for AsyncTasks/Volley included the JSON parsing as Retrofit does it for you automatically.
RetroFit Wins in benchmark test!
In the end, we decided to go with Retrofit for our application. Not only is it ridiculously fast, but it meshes quite well with our existing architecture. We were able to make a parent Callback Interface that automatically performs error handling, caching, and pagination with little to no effort for our APIs. In order to merge in Retrofit, we had to rename our variables to make our models GSON compliant, write a few simple interfaces, delete functions from the old API, and modify our fragments to not use AsyncTasks. Now that we have a few fragments completely converted, it’s pretty painless. There were some growing pains and issues that we had to overcome, but overall it went smoothly. In the beginning, we ran into a few technical issues/bugs, but Square has a fantastic Google+ community that was able to help us through it.
When to use Volley?!
We can use Volley when we need to load images as well as consuming REST APIs!, network call queuing system is needed for many n/w request at the same time! also Volley has better memory related error handling than Retrofit!
OkHttp can be used with Volley, Retrofit uses OkHttp by default! It has SPDY support, connection pooling, disk caching, transparent compression! Recently, it has got some support of java NIO with Okio library.
Source, credit: volley-vs-retrofit by Mr. Josh Ruesch
Note: About streaming it depends on what type of streaming you want like RTSP/RTCP.
I am using both in my app.
Robospice works faster than Retrofit whenever I parse the nested JSON class. Because Spice Manger will do everything for you. In Retrofit you need to create GsonConverter and deserialize it.
I created two fragments in the same activity and called the same time with two same kind of URLs.
09-23 20:12:32.830 16002-16002/com.urbanpro.seeker E/RETROFIT? RestAdapter Init
09-23 20:12:32.833 16002-16002/com.urbanpro.seeker E/RETROFIT? calling the method
09-23 20:12:32.837 16002-16002/com.urbanpro.seeker E/ROBOSPICE? initialzig spice manager
09-23 20:12:32.860 16002-16002/com.urbanpro.seeker E/ROBOSPICE? Executing the method
09-23 20:12:33.537 16002-16002/com.urbanpro.seeker E/ROBOSPICE? on SUcceess
09-23 20:12:33.553 16002-16002/com.urbanpro.seeker E/ROBOSPICE? gettting the all contents
09-23 20:12:33.601 16002-21819/com.urbanpro.seeker E/RETROFIT? deseriazation starts
09-23 20:12:33.603 16002-21819/com.urbanpro.seeker E/RETROFIT? deseriazation ends
Just to add a bit to the discussion from my experience working with Volley:
Volley does not handle streaming uploads or downloads in any sense. That is, the entire request body has to be in memory and you cannot use an OutputStream
to write the request body to the underlying socket, nor can you use an InputStream
to read the response body, as basic HttpURLConnection
does. So, Volley is a poor choice for uploading or downloading large files. Your requests and responses should be small. This is one of the biggest limitations of Volley that I have personally encountered. For what it's worth, OkHttp does have interfaces for working with streams.
The lack of official documentation is annoying, although I have been able to work around that by reading the source code, which is pretty easy to follow. What is more bothersome is that, as far as I can tell, Volley has no official release versions and no Maven or Gradle artifact, and therefore managing it as a dependency becomes more of a headache than, say, any of the libraries Square has released. You just clone a repo, build a jar, and you're on your own. Looking for a bug fix? Fetch and hope it's there. You might get some other stuff, too; it won't be documented. In my opinion, this effectively means that Volley is an unsupported 3rd party library, even though the code base is reasonably active. Caveat emptor.
As a nit, having the Content-Type tied to the class/request type (JsonObjectRequest, ImageRequest, etc.) is kind of awkward and reduces the flexibility of the calling code a bit, as you are tied to Volley's existing Request type hierarchy. I like the straightforwardness of just setting Content-Type as a header like any other (don't do this with Volley, by the way; you'll end up with two Content-Type headers!). That's just my personal opinion, though, and it can be worked around.
That is not to say that Volley does not have some useful features. It certainly does. Easily customizable retry policies, transparent caching, a cancellation API, and support for request scheduling and concurrent connections are great features. Just know that it's not intended for all HTTP use cases (see item 1 above), and that there are some headaches involved in putting Volley into production use in your app (item 2).
Source: Stackoverflow.com