See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/329310551

Android REST APIs : Volley vs Retrofit

Conference Paper · November 2018

DOI: 10.1109/ISAECT.2018.8618824

CITATIONS READS

5 2,635

3 authors:

Mohamed Lachgar Hanane Benouda

Université Chouaib Doukkali University Sultan Moulay Sliman
23 PUBLICATIONS   93 CITATIONS    8 PUBLICATIONS   67 CITATIONS   

SEE PROFILE SEE PROFILE

Selwa Elfirdoussi
Université Mohammed VI Polytechnique
22 PUBLICATIONS   71 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

reverse engineering mobile apps View project

Web Service Discovery View project

All content following this page was uploaded by Hanane Benouda on 03 March 2021.

The user has requested enhancement of the downloaded file.

 Android REST APIs : Volley vs Retrofit
Mohamed LACHGAR Hanane BENOUDA
LAMAI, FSTG, UCA MATSI Labo, EST, UMP
Marrakech, Morocco Oujda, Morocco
lachgar.m@gmail.com benouda.han@gmail.com
Abstract— In the old days, networking in Android was a
nightmare. Nowadays the problem is to find out which solution
fits better the project’s necessities. Therefore, almost every
Android applications use a Web REST API for data transfer.
Previously, developers preferred to write their own code to
retrieve and analyze data. However, they now have a whole range
of REST client libraries, which can speed up development by
reducing the coding efforts, and efficiently analyze data. The
REST (Representational State Transfer) has become the most
commonly used way for creating, publishing, and consuming
Web services, exploiting JavaScript Object Notation (JSON) as a
data exchange format. Android Volley and Retrofit are the most
used libraries for accessing the REST Web APIs today.
In this paper, we will present a comparative study between
these two libraries, in order to disclose the advantages and
limitations of each of them.
Index Terms — RESTful Web Services, Networking, Volley,
Retrofit, Android OS.
I. Introduction
Mobile Applications (apps) are defined as softwares that
can be installed and executed on mobile devices like smart
phones, and personal digital assistance (PDA). Mobile
applications continue to emerge as a powerful and universal
service delivery channel enabling companies to offer
consumers a variety of products and services [1]. Indeed, the
rapid advancement of mobile technology and the subsequent
service innovation deriving from it is leading many companies
to develop relations with consumers through mobile
applications [2]. In addition, with lower prices of mobile
devices with higher memory size and longer battery life have
all resulted in a surge in usage of mobile phone and application
services [3].
The increasing development platforms for apps represent a
major revolution in software development. Rather than
hardware or software firms managing the majority of software
development, third-party developers now play a substantial role
in industries. On that point, some research was focalized on the
use of apps. The authors in [4] present a study exploring the
factors that lead towards the decision to uninstall mobile
application and cause smaller life cycle for the app. The study
reveals factors concerning user behavior as well as describing
app features, as responsible for the decline in app life cycle. In
other context, a data clustering techniques to predict temporal
Selwa Elfirdoussi
EMINES, UM6P
Ben Guerir, Morocco
Selwa.Elfirdoussi@emines.um6p.ma
characteristics of data consumption behavior of different
mobile applications via wireless communications proposed in
[5]. The authors exploit mobile application usage logs provided
by a Wi-Fi local area network service provider to characterize
temporal behavior of mobile applications. Specifically, “what”
types of mobile applications users’ access and “when” users
access them.
Based this revolution, The OCAD University has
published a report [6] concerning the Mobile Innovation in
service and its industrial applications. The team explains the
important role that mobile technologies play in increasing the
competitively of industrial companies. For this purpose,
companies must focus on acquiring and developing better
marketing skills using mobile applications. They should
explore avenues to obtain additional real-time data and
information to inform their decision-maker.
With the growing number of smartphone users around the
world, the best thing to do is to have a mobile application
strategy that can acclimate the service or product to this
growing market. Recently, any web application it is expected
to have a version of the mobile application, and we cannot
always rely solely on responsive design. The case of having a
web and a mobile app has several complications; one of them
is the need for a standardized and centralized way to store data
from the web and mobile. To avoid redundancy we can save
development time by creating a storage layer once, as an API,
and reuse it with multiple application versions.
The only variation would be the presentation of the
application. Whether on the web, iOS, android or any other OS,
we only need a way to communicate with our API and we well
have your centralized data storage. Fortunately, there are
libraries that support launching and running concurrent
programs in the background in separate threads, network
caching, and other features that significantly clean up network
code.
In this paper we present a comparative study between
Volley [7, 8] and Retrofit [9], which are both great networking
libraries for modern Android apps, but each has its own
strengths that are worth weighing for critical projects.
The first library we studied is Volley, a networking library
developed by Google. It is currently used in most applications
developed by Google engineers. The other library we reviewed
is Retrofit, which is a simple and a light library for Android
developed by Square.
 The rest of the paper is organized as follows: the second According to the important points, we notice that volley
section defines the Android REST APIs. The third section and retrofit are more specific and adapted for Android
compares the Volley and Retrofit libraries according to various applications, also, can be integrated with other HTTP client
parameters. The fourth section discusses the response time of such as OkHttp. Therefore, in the following of this paper we
both libraries through a case study. The synthesis of this case present a study of these two APIs.
study is the main object of the fifth section. Conclusion and
future work are presented in the last section.
III. Architecture of Volley and
II. Android Networking APIs Retrofit
In recent years, several networking libraries for Android This section describes the architecture of Volley and
have emerged. The most commonly used are listed in the table Retrofit APIs.
below:
TABLE 1. NETWORKING LIBRARIES FOR ANDROID
A. Volley API
API Definition License Important Volley is an HTTP library developed by Google that makes
points networking tasks in Android apps easier and most importantly,
Android An asynchronous callback- Apache - Views that faster. It was announced by Ficus Kirkpatrick at Google IO
Asynchronous based Http client for License require
Http Client Android built on top of 2.0 multiple API
2013 and it is part of the Android Open Source Project
Apache's HttpClient calls. (AOSP). Volley is very useful for network request involving
libraries. - Run images, JSON and Strings. It has been built to offer great
extremely features like asynchronous request, synchronous request,
slow. making multiple request at the same time, prioritization,
- Take
multiple
ordered requests and caching.
seconds to The Volley library can pretty much do everything with that
load.
has to do with Networking in Android. It provides transparent
KSOAP 2 [10] The ksoap2-android project MIT - Allows
provides a lightweight and License loading Data disk and memory caching, powerful customization abilities,
efficient SOAP client from SOAP debugging and tracing tools and automatically schedules all
library for the Android web service network request such as fetching responses for images from
platform. in Android web. Fig.1 describe the Volley architecture.
Application.
PICASSO [11] Picasso allows for image Apache - Allows
loading in the application License loading
by handling ImageView 2.0 images from
recycling, downloads assets,
cancelation, and offering resources,
memory efficient image files, URLs
transformations, including and content
automatic memory and providers.
disk caching. - Does not
support
GIFs.
OKHTTP [12] OkHttp is an efficient Apache - OkHttp is an
HTTP client providing License HTTP client,
features such as SPDY, 2.0 which
transparent compression, supports
connection pooling and HTTP/2 and
response caching. SPDY. Fig. 1 Volley Architecture
- OkHttp
depends on B. Retrofit API
Okio. Retrofit is a clean, simple and lightweight library for
Volley An HTTP library that Apache - Volley can Android developed by Square, Inc. In other words, Retrofit is a
makes networking for License integrate
Android apps easier and 2.0 with most
REST client for Android, through which we can make easy-to-
faster. popular use interfaces that can turn any Android application into a
HTTP powerful application that can communicate with remote
clients databases. What makes it different is that Retrofit can perform
such as Async and Sync queries with automatic JSON scanning
OkHttp, without any effort. This feature alone makes it powerful
etc.
Retrofit Retrofit is a REST client Apache - Retrofit is a
enough to make a candidate for this comparison. Although it
that sits on top of OkHttp License type-safe has many features easier to use.
and makes very easy 2.0 HTTP client
common networking tasks. for Android
and Java.

Fig. 2 Retrofit Architecture
IV. Volley vs Retrofit
Nowadays, almost every mobile application includes some
sort of network hits to perform its functionality. Networking
libraries are one of the best options to do this. Volley and
Retrofit are both great networking libraries for modern android
applications, but each has its own forces that are worth
weighing for critical projects. Therefore, here is a comparison
of both the libraries with various parameters (see Figure 3 for
more details).
Fig. 3 Criterions for comparison
A. Code Complexity
Both Volley and Retrofit are easy to use. They provide the
functionality to make network calls to both Sync and Async
requests with minimal code. If we talk about request and
handling of the responses that API calls, they are treated by
Retrofit as simple java method calls, so we only define the
URLs to hit and specify the request and response parameters as
classes Java. While with Volley, we need to make extra code to
get the same thing for parsing. It is a bit more general and the
only types of responses supported are Image, Sring,
JSONArray and JSONObject.
B. Image loading
Volley library has a special type of request to get images
from network named ImageRequest. If this type of request is
made, the response is captured as a bitmap. In addition, it has
rudimentary support for image loading, which saves a lot of
coding. Volley has a NetworkImageView class used with
ImageLoad class, to load automatically images, whenever the
NetworkImageView appears. Up to now, Retrofit does not
provide a support for loading images from the network, in the
same way as they are loaded in Volley. But Retrofit library
can be combined with OkHttpClient to support the loading of
images.
C. Performance and caching
Volley and Retrofit libraries use thread pools and execute
multiple requests in parallel, and they support the venerable
OKHttp library. Using Retrofit library, the caching should just
work if your server sets the correct cache control headers. If
not, we may be out of luck. The HTTP client layer
(HttpUrlConnection, OkHttp, etc.) is the only level that you
can turn here. But, Volley definitely has a more flexible and
elaborate caching mechanism.
D. Request prioritization
The Retrofit does not support setting priority. It supports
manual request retries and cancellation since v2. In contrary,
the Volley can supports prioritization with a little extra code,
cancellation and customizable.
E. POST requests
Retrofit library has full support for POST requests and
multi part file uploads, with a sweet API to boot. Volley
supports POST requests, but the conversion of Java objects to
JSONObjects is done by the developers. And it supports
multipart requests, but we need to add these additional
equivalent classes.
F. Extensibility
Retrofit has an intuitive API with a small number of
extension points for common use-cases, such as
(de)serialization and request threading. On the other hand,
Volley is very open to extension and even relies on that fact
for common features as request priority, bitmap caching and
setting up a global long lived Request Queue. The success of
Glide proof the great extensibility of Volley’s.
G. Dynamic URLs
Android Retrofit library supports dynamic URLs since v2.
But Volley obviously supports dynamic URLs, the URL can
be the second parameter in the String Request constructor.
H. Caching
Android Retrofit library does not support caching. Android
Volley on the other hand, has a flexible and very elaborate
caching mechanism. When a request is made using Volley
library, first the cache is checked for appropriate response if it
is found there than it is returned parsed else network hit is
made.

V. Case study
In this case study, we have created simple employees
management system with PHP language, hosted in an Apache
server, and we have developed an API for retrieving data
stored in the MySQL database in JSON format. The
architecture of the application is shown in the figure
below:

Fig. 5 Evaluation of execution time of insertion requests

C. Evolution of execution time of select queries

In this study, we treated the response time when loading
data from a database hosted in a distant server. To do this, we
simulate the response time for 50, 150, 200, …, and 1000
queries executed successively. This study also shows that
running queries with Volley is faster than running queries
using Retrofit (see Figure 6 below for more details).

Fig. 4 Application Architecture

In the remainder of this section, we present the different

results, In order to evaluate the execution time of inserting and
requesting data to/from database, for each API. Also, we have
evaluated the response time of loading images form
Apache server.

A. Test environment
This case study was conducted in the following test
environment.
TABLE 2. TEST ENVIRONMENT
Notebook PC
Memory 8192 MB RAM
Intel ® Core ™i5-4300U CPU @ 1.90GHZ (4 CPUs), -
Processors
2.5GHz
OS Windows 10 Professionnel 64 bits Fig. 6 Evaluation of execution time of select Queries
Database MySQL 5
PHP The table below illustrates the obtained results.
5.5.38
version

B. Evolution of execution time of insertion requests TABLE 3. EXECUTION TIME OF SELECT QUERIES
Execution Time Execution Time
In this study, we simulate the evolution of execution time Number of Requests
with Volley (in ms) with Retrofit (in ms)
of insertion requests in a database hosted in a distant server. 50 (First Call) 1,116 12,753
The figure 5 below shows that Volley carries this challenge.
100 0,113 0,154
150 0,103 0,153
200 0,143 0,151
250 0,136 0,17
300 0,113 0,133
 350 0,126 0,181 6 20ko 0,208 0,309
400 0,113 0,146 7 17ko 0,21 0,314
450 0,111 0,193 8 20ko 0,231 0,33
500 0,112 0,119 9 21ko 0,241 0,316
550 0,103 0,178 10 17ko 0,274 0,845
600 0,102 0,128
650 0,104 0,138
VI. Synthesis
700 0,103 0,124
After thoroughly comparing the major features between
750 0,11 0,169 Android Volley and Retrofit, from an exterior perspective,
800 0,101 0,209 they look alike in terms of use. They provide a “callback”,
850 0,102 0,156
which is an interface with two methods: success and failure.
One of the methods will be called on the main thread at the
900 0,103 0,15 end of the asynchronous network call. The big difference lies
950 0,101 0,175 in endpoint specification of the API and the nature of obtained
1000 0,119 0,13
data.
On one hand, with Android Volley library, we dynamically
D. Loading time of the images specify the endpoint at the time of the API call. By default,
Volley returns a JSONArray or a JSONObject based on the
In this study, we propose to load 10 images with different
type of request.
sizes from a remote server, and we calculate the time taken to
On the other hand, Android Retrofit library allows to set
load each image. The figure below shows that loading images
the base endpoint URL for all API calls, and then create static
with Volley is faster compared to loading images with Retrofit
interfaces that specify endpoints using Java annotations. Then,
(see Figure 7 below for more details).
to make an API call with Retrofit, we call a method of the
interface that transmits the necessary parameters, after
returning a Java template object. By default, Retrofit
automatically performs JSON analysis using GSON (that is
fast in terms of development time).
In order to obtain benchmarks of performance. We
developed a very basic application that allowed us to switch
between an easy API with little JSON analysis and a complex
API with a long answer. The total number of API calls to be
made can also be changed in the application. The benchmark
showed us two important things:
1. Android Volley and Retrofit are easy to use.
2. They are faster than AsyncTasks.
In the three tests, with varying repetitions (1 to 1000 times),
the Android Volley is faster and offers much more features
than Retrofit API.

VII. Conclusion
Fig. 7 Execution time of download images In this paper, we presented a comparative study of the most
used libraries in mobile applications to consume distant
The table below illustrates the achieved results. services, namely Volley and Retrofit. And we found that
Volley has great advantage in terms of execution time
TABLE 4. EXECUTION OF DOWNLOAD IMAGES compared to Retrofit, which is easier to implement. For future
Execution Time Execution Time
Image Weight
with Volley (in ms) with Retrofit (in ms)
work, we will study the security mechanisms offered by each
of the APIs
1 20ko 1,864 8,834
2 18ko 0,308 0,544
References
3 17ko 0,294 0,725
[1] G. McLean, K. Al-Nabhani et A. Wilson, “ Developing a Mobile
4 21ko 0,579 1,095 Applications Customer Experience Model (MACE) - Implications for
Retailers”, 2018, Journal of Business Research, Vol. 85, pp. 325–336.
5 50ko 0,235 1,222
[2] A. Tarute, S. Nikou et R. Gatautis, “Mobile application driven consumer
engagemen“, 2017, Telematics and Informatics, Vol. 34, pp. 145–156.
[3] J. Song, et al , “Platform adoption by mobile application developers: A
multimethodological approach”,2018, Decision Support Systems, Vol.
107, pp. 26–39.
[4] A. Vagrani, N. Kumar et P. V. Ilavarasan, “Decline in Mobile
Application Life Cycle”, 2017, Procedia Computer Science, Vol. 22, pp.
957–964.
[5] K. W. Lima, et al. “Characterizing and predicting mobile application
usage”, 2016, Computer Communications, Vol. 95, pp. 82–94.
[6] L. Andrew, P. Sam et W. Kathleen,“ Mobile Innovation: Ontario’s
Growing Mobile Content, Services, and Applications. Toronto : Mobile
Experience Innovation Centre”, 2012.
[7] S. Yang, and H. Jieping. "Research and implementation of Web Services
in Android network communication framework Volley." Service
Systems and Service Management (ICSSSM), 2014 11th International
Conference on. IEEE, 2014.
View publication stats
[8] F. Kirkpatrick, “Volley, easy, fast networking for android”, Google.
[9] Square.github.io. (n.d.). “Retrofit”. [online] at:
http://square.github.io/retrofit/ [Accessed 4 Jan. 2018].
[10] H. Seigel and S. Haustein. "kSOAP 2." Online at: http://ksoap2.
sourceforge. net/Last accessed 7 (2010): 16.
[11] Y. J. SONG, S. B. OU , and J. W. LEE, "An Analysis of Existing
Android Image Loading Libraries: Picasso, Glide, Fresco, AUIL and
Volley.", DEStech Transactions on Engineering and Technology
Research imeia (2016).
[12] M. Backes, S. Bugiel and E. Derr, "Reliable third-party library detection
in android and its security applications." Proceedings of the 2016 ACM
SIGSAC Conference on Computer and Communications Security.
ACM, 2016.