Why Android-Volley is faster

Why Android-Volley is faster - android

I am evaluating the Volley networking library for using in my next project as I heard many good things about it. I found that it makes implementing network operations easy. But it's also claimed that it makes networking faster. Can someone please explain how?

It doesn't increase the speed of the networking itself, but it has good support for local caching and response compression, which are things that the standard Java/Apache HTTP classes don't handle for you.
The result is the perception of increased performance, and also lower battery usage (due to fewer network fetches).
Having adopted Volley for my own projects over the past few weeks, I can firmly recommend it!

At this year's I/O there is a session about that, presented by the
Ficus Kirkpatrick. I suggest you to watch that video, as it will answer your questions in detail.
https://developers.google.com/events/io/sessions/325304728

Related

Android Kotlin UI Async Http request - AsyncTask or Custom Libraries? [duplicate]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
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 dont yet have experience developing with them. I'm hoping someone can 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).

I'm hoping someone can provide some concrete examples of best use cases for each.
Use Retrofit if you are communicating with a Web service. Use the peer library Picasso if you are downloading images. Use OkHTTP if you need to do HTTP operations that lie outside of Retrofit/Picasso.
Volley roughly competes with Retrofit + Picasso. On the plus side, it is one library. On the minus side, it is one undocumented, an unsupported, "throw the code over the wall and do an I|O presentation on it" library.
EDIT - Volley is now officially supported by Google. Kindly refer Google Developer Guide
From what I've read, seems like OkHTTP is the most robust of the 3
Retrofit uses OkHTTP automatically if available. There is a Gist from Jake Wharton that connects Volley to OkHTTP.
and could handle the requirements of this project (mentioned above).
Probably you will use none of them for "streaming download of audio and video", by the conventional definition of "streaming". Instead, Android's media framework will handle those HTTP requests for you.
That being said, if you are going to attempt to do your own HTTP-based streaming, OkHTTP should handle that scenario; I don't recall how well Volley would handle that scenario. Neither Retrofit nor Picasso are designed for that.

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
version 1.6 of Retrofit with OkHttp 2.0 is now dependent on Okio to support java.io and java.nio which makes it much easier to access, store and process your data using ByteString and Buffer to do some clever things to save CPU and memory. (FYI: This reminds me of the Koush's OIN library with NIO support!)
We can use Retrofit together with RxJava to combine and chain REST calls using rxObservables to avoid ugly callback chains (to avoid callback hell!!).
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):
Library
One Discussion
Dashboard (7 requests)
25 Discussions
AsyncTask
941 ms
4,539 ms
13,957 ms
Volley
560 ms
2,202 ms
4,275 ms
Retrofit
312 ms
889 ms
1,059 ms
(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.

RoboSpice Vs. Volley
From https://groups.google.com/forum/#!topic/robospice/QwVCfY_glOQ
RoboSpice(RS) is service based and more respectful of Android philosophy than Volley. Volley is thread based and this is not the way background processing should take place on Android. Ultimately, you can dig down both libs and find that they are quite similar, but our way to do background processing is more Android oriented, it allow us, for instance, to tell users that RS is actually doing something in background, which would be hard for volley (actually it doesn't at all).
RoboSpice and volley both offer nice features like prioritization, retry policies, request cancellation. But RS offers more : a more advanced caching and that's a big one, with cache management, request aggregation, more features like repluging to a pending request, dealing with cache expiry without relying on server headers, etc.
RoboSpice does more outside of UI Thread : volley will deserialize your POJOs on the main thread, which is horrible to my mind. With RS your app will be more responsive.
In terms of speed, we definitely need metrics. RS has gotten super fast now, but still we don't have figure to put here. Volley should theoretically be a bit faster, but RS is now massively parallel... who knows ?
RoboSpice offers a large compatibility range with extensions. You can use it with okhttp, retrofit, ormlite (beta), jackson, jackson2, gson, xml serializer, google http client, spring android... Quite a lot. Volley can be used with ok http and uses gson. that's it.
Volley offers more UI sugar that RS. Volley provides NetworkImageView, RS does provide a spicelist adapter. In terms of feature it's not so far, but I believe Volley is more advanced on this topic.
More than 200 bugs have been solved in RoboSpice since its initial release. It's pretty robust and used heavily in production. Volley is less mature but its user base should be growing fast (Google effect).
RoboSpice is available on maven central. Volley is hard to find ;)

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.

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).

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.

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.

Retrofit 1.9.0 vs. RoboSpice
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

And yet another option:
https://github.com/apptik/jus
It is modular like Volley, but more extended and documentation is improving, supporting different HTTP stacks and converters out of the box
It has a module to generate server API interface mappings like Retrofit
It also has JavaRx support
And many other handy features like markers, transformers, etc.

Android Volley vs Retrofit. Which is better and why? [duplicate]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
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 dont yet have experience developing with them. I'm hoping someone can 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).

I'm hoping someone can provide some concrete examples of best use cases for each.
Use Retrofit if you are communicating with a Web service. Use the peer library Picasso if you are downloading images. Use OkHTTP if you need to do HTTP operations that lie outside of Retrofit/Picasso.
Volley roughly competes with Retrofit + Picasso. On the plus side, it is one library. On the minus side, it is one undocumented, an unsupported, "throw the code over the wall and do an I|O presentation on it" library.
EDIT - Volley is now officially supported by Google. Kindly refer Google Developer Guide
From what I've read, seems like OkHTTP is the most robust of the 3
Retrofit uses OkHTTP automatically if available. There is a Gist from Jake Wharton that connects Volley to OkHTTP.
and could handle the requirements of this project (mentioned above).
Probably you will use none of them for "streaming download of audio and video", by the conventional definition of "streaming". Instead, Android's media framework will handle those HTTP requests for you.
That being said, if you are going to attempt to do your own HTTP-based streaming, OkHTTP should handle that scenario; I don't recall how well Volley would handle that scenario. Neither Retrofit nor Picasso are designed for that.

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
version 1.6 of Retrofit with OkHttp 2.0 is now dependent on Okio to support java.io and java.nio which makes it much easier to access, store and process your data using ByteString and Buffer to do some clever things to save CPU and memory. (FYI: This reminds me of the Koush's OIN library with NIO support!)
We can use Retrofit together with RxJava to combine and chain REST calls using rxObservables to avoid ugly callback chains (to avoid callback hell!!).
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):
Library
One Discussion
Dashboard (7 requests)
25 Discussions
AsyncTask
941 ms
4,539 ms
13,957 ms
Volley
560 ms
2,202 ms
4,275 ms
Retrofit
312 ms
889 ms
1,059 ms
(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.

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.

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.

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.

Retrofit 1.9.0 vs. RoboSpice
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

And yet another option:
https://github.com/apptik/jus
It is modular like Volley, but more extended and documentation is improving, supporting different HTTP stacks and converters out of the box
It has a module to generate server API interface mappings like Retrofit
It also has JavaRx support
And many other handy features like markers, transformers, etc.

How to invoke a call to a URL from an Andorid app?

Disclaimer. I'm asking this on someone else's behalf and given that I know as much about Android development as penguins about flight, it may be clumsy. In such case, let me know and I'll remove it or try to reformulate.
I've created a web service that's reachable at the URL on the following form.
http://server/Blopp.svc/Store/value1/value2
The back-end part I've got covered but I'm worried about the front-end development. I've got a colleague that's making the app and he's got the rudimentary GUI done. However, in order not to do a lot of convoluted coding, he's heard that there's a certain library for making such URL calls.
What's the name of it? Is there certain other aspects to take into consideration or is there an (almost) standard one that everybody uses?
Please not that the app's functionality is at the moment limited to providing the web service with data. All the logic and presentation is done on the website and not inside the app.
I've never built up an Android app, so I'm asking for understanding if this is a dumb formulation. I just want to help my co-worker and he seemed to struggle with the details.
Is there perhaps a smoother way to make the call to a web service if I substitute the patter of the URL to use query strings? Any other approach that makes it easier for an Android developer? I'm not familiar with the area but I want to make things easy for my team-mate.

There are quite a few different HTTP libraries available and it would really depend on your specific requirements which one you used (if any - you can roll your own HTTP requests using HttpURLConnection) Two of the more popular ones are:
Volley
http://developer.android.com/training/volley/index.html
Written by one of the guys on the Google Play team and part of the AOSP. Very flexible and easy to use however I would hesitate to recommend it as it relies on the now deprecated Apache Http classes in its public API.
Retrofit
http://square.github.io/retrofit/
From Square. Version 2 is currently in late stages of beta. It allows you to define your API as an interface. It has dependancies on their OkHttp library as well. Very fast and also has RxJava support baked in.

HttpUrlConnection with HttpResponseCache or Volley for better caching implementation in android

I am developing an app for Android in which there are a lot of http requests to server to fetch some data. My response includes a lot of images as well along with texts in JSON format.
I would like to make my application work faster using proper caching like Google Play, Google plus and other application uses.
I already know about android Volley library and tried and developed some samples to test and it is serving great and caching my images perfectly as expected . But recently while doing a research for the same on internet , I came to know about HttpResponseCache classes where you install an cache for Http request response.
Now I am bit confused with which I should go, I already tried Volley but did not tries using HttpResponseCache.
My Question is :
Are they doing the same thing internally ?
If not which will be better to go with.
You expert advice or experience will save a lot time of mine.

I can tell about my experience. My task was the same. I had to download a lot of images and other requests. My first attemp was based on HttpUrlConnection with using HttpResponseCache. It worked, but speed of download wasn't fast enough (12kb image has been downloading about 1.5-2 seconds, this is too long). So I had to find new faster solution.
I knew about volley, but didn't know about some features in it, especially priority of downloading. And main purpose was exactly priority, so I began to create own solution. I tried to use apache HttpClient instead of HttpUrlConnection, and it was realy faster, same image has been downloading from 200 to 300 miliseonds.
I wasn't able to achieve faster speed with HttpUrlConnection, but as I'm not expert, I think that there was small mistake and HttpUrlConnection can works faster, unfortunately this question is still closed for me.
If look through the Volley source, it uses HttpUrlConnection class after API >= 9, and HttpClient class before API level 9. I didn't measure download speed with volley, so I can't say is it fast or no.
So, what conclusions I came, my solution costed me at least 3 or 4 days, and if I knew that volley have priority of download, maybe I hadn't have to write it (if it is fast too).
Answering on your question, yes Volley doing the same, and if you don't need to do something special you can use Volley, it will be much faster than writing own solution.

Comparison of Android networking libraries: OkHTTP, Retrofit, and Volley [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
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 dont yet have experience developing with them. I'm hoping someone can 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).

I'm hoping someone can provide some concrete examples of best use cases for each.
Use Retrofit if you are communicating with a Web service. Use the peer library Picasso if you are downloading images. Use OkHTTP if you need to do HTTP operations that lie outside of Retrofit/Picasso.
Volley roughly competes with Retrofit + Picasso. On the plus side, it is one library. On the minus side, it is one undocumented, an unsupported, "throw the code over the wall and do an I|O presentation on it" library.
EDIT - Volley is now officially supported by Google. Kindly refer Google Developer Guide
From what I've read, seems like OkHTTP is the most robust of the 3
Retrofit uses OkHTTP automatically if available. There is a Gist from Jake Wharton that connects Volley to OkHTTP.
and could handle the requirements of this project (mentioned above).
Probably you will use none of them for "streaming download of audio and video", by the conventional definition of "streaming". Instead, Android's media framework will handle those HTTP requests for you.
That being said, if you are going to attempt to do your own HTTP-based streaming, OkHTTP should handle that scenario; I don't recall how well Volley would handle that scenario. Neither Retrofit nor Picasso are designed for that.

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
version 1.6 of Retrofit with OkHttp 2.0 is now dependent on Okio to support java.io and java.nio which makes it much easier to access, store and process your data using ByteString and Buffer to do some clever things to save CPU and memory. (FYI: This reminds me of the Koush's OIN library with NIO support!)
We can use Retrofit together with RxJava to combine and chain REST calls using rxObservables to avoid ugly callback chains (to avoid callback hell!!).
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):
Library
One Discussion
Dashboard (7 requests)
25 Discussions
AsyncTask
941 ms
4,539 ms
13,957 ms
Volley
560 ms
2,202 ms
4,275 ms
Retrofit
312 ms
889 ms
1,059 ms
(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.

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.

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.

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.

Retrofit 1.9.0 vs. RoboSpice
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

And yet another option:
https://github.com/apptik/jus
It is modular like Volley, but more extended and documentation is improving, supporting different HTTP stacks and converters out of the box
It has a module to generate server API interface mappings like Retrofit
It also has JavaRx support
And many other handy features like markers, transformers, etc.

Develop Reference

The Android operating system is a mobile operating system that was developed by Google (GOOGL?) to be primarily used for touchscreen devices, cell phones, and tablets.