Every day, we rely more and more on our smartphone to do a huge variety of our daily life tasks. We have on average 80 apps installed on our smartphones and most of them rely on web services to be useful to the end-user. Typically, such apps make use of HTTP requests to fetch and push data to the web services.
While developing Bolina, I had to make some research around this, so I decided to share what I've learned. As an overview, this post discusses the current landscape of HTTP libraries for the Android environment: I look into the most used HTTP libraries, to their intended use case and how they compare to each other, in general. If you're looking for iOS HTTP Libs, follow this link.
You can also check my performance comparisons:
Even though I focus on HTTP libraries for the Android system, most of the discussed libraries are Java-based, which means they can also be used in any Java application. Despite such, I am not going to dive into details on the particularities of each library that refers to the general Java environment.
Apache HTTP Client was one of the first HTTP libraries included since Android’s API 1 (alongside HttpURLConnection). As its name implies, it was developed by the same guys that brought us the Apache web server - which, from my point of view, inspires confidence from the start. Thus, it became the default answer for many developers (myself included) in the early days of Android development.
However, the actual implementation of the library in Android was more of a work performed by Google and lacked many updates and bug fixing implemented by the Apache team. Therefore, with API 23 release (Android 6.0), Google decided to deprecate the default Android’s Apache HTTP Client APIs.
Notice that the guys from Apache.org also provides a full up-to-update port of the original Apache HTTP Client for Android. However, the usage of this port may cause some headache due to the conflict with the library and the native Apache HTTP Client implementation.
Similar to Apache HTTP Client, HttpURLConnection also appeared with Android API 1. However, it only became stable enough starting from API 9, when it became the recommend HTTP library to be used by Google. The benefit of being the default choice for many years is the huge amount of tutorials that can be found.
As an effort to improve Android’s HTTP capabilities and in order to simplify the life of developers, in 2013 Google released the Volley HTTP library. This library provides methods to handle typical apps web requests, such as calls to RESTful APIs and image downloads. It also simplifies the management of the HTTP lifecycle by providing asynchronous calls, transparent HTTP caching, automatic scheduling of network requests and request prioritization. Also, Volley allows the developer to chose which HTTP he wants to use.
By default, Volley relies on Apache HTTP Client for older versions of Android and on HttpURLConnection for newer ones. However, it can also be configured to use OkHttp and make use of some of its features.
OkHttp is Square’s answer for their HTTP needs, by being “an HTTP client that’s efficient by default”. It becomes efficient by automatically caching HTTP response, automatically compression HTTP data and performs connection pooling. Besides being efficient, OkHttp also has robustness as a goal: it employs a few strategies to automatically recover in case of a connection fail. Moreover, it has developed to support HTTP/2 from the beginning.
As if all these features were not enough, its APIs are simple and very well documented. It is so popular that Google, on Android 4.4, decided to use OkHttp as the HTTP engine of HttpURLConnection.
One of the characteristics of OkHttp, is its lack of helper for RESTful APIs and image downloads. I am calling it a characteristic and not a problem because that’s a design choice. Square created OkHttp as a very capable HTTP engine that can also be easily used by other libraries, in this case, Retrofit. Retrofit, as with OkHttp, is also developed by Square. It turns a RESTful API into a Java interface, by using annotations to describe the HTTP request. Retrofit is also very customizable, allowing the developer to set various converters, to handle for e.g. XML requests.
Besides Retrofit, Square also developed another helper: Picasso. This time, to help with image loading directly into ImageViews. As with Retrofit, Picasso relies on OkHttp to perform its HTTP requests and to handle all network related challenges. Regarding image management, Picasso handles the ImageView recycling cycles, the complexity of image transformations with minimal memory use and finally manages memory and disk caching automatically.
These are the most used and acclaimed HTTP libraries for the Android universe. Each one of them has their strengths and weaknesses. However, in my opinion, there’s one library clearly surpasses the others: OkHttp. The guys from Square did a great job with their HTTP library, making it simple, fully customizable, full of features and very well documented. Plus, it is the base for many other amazing libraries.