REST DESIGN PATTERN FOR ANDROID SOCIAL NETWORK
APPLICATIONS
Jovan Ristić1, Milan Milojić1
Morena inženjering, Niš
1
Abstract – Android is currently fastest growing mobile
platform with great number of applications based on
social networks. With social networks gaining
momentum and with growing number of people using
them it is essential to take every possible precaution
when creating mobile application clients that provide
access to them. Choosing the right protocol for data
access is only half the work done. Android applications
need to be fast, responsive and use as few resources
possible in order to satisfy growing needs of the end
users. This paper aims to provide analysis for choosing
appropriate web service protocol as well as guidelines
for developing android social network applications.
We will present possible worst case scenario when
dealing with remote web server calls and a solution
that can overcome that obstacles.
1.
INTRODUCTION
We are currently witnessing rapid changes that are
happening in the ever-growing IT world. Mobile
devices are taking the spotlight and market share from
what was once untouchable PC sector. Every year, over
one billion mobile devices are sold. Among them,
Android platform is dominating with its smartphone
market share that it currently over 40% and even more
with its growth rate [1]. Many enterprises make mobile
applications that are designed for different types of
users who are usually at different geographical points.
Different groups that have different interests can be
connected using mobile social networks. The aim is to
make communication easier between familiar groups.
It should be taken into consideration that there are
major gaps between the different places around the
world. The gap primarily reflects in cultural
differences, level of education, different written and
moral laws etc. Because of this, application must be
available to use for all users equally. This means that
application can be used on language that is native for
user and to achieve communication with friend that is
on different side of the world and who speaks with his
locale language. Also, using this application must be
simple and intuitive.
2.
SOAP AND REST COMPARISON
Many web applications are created using services that
are based on SOAP. SOAP is short for Simple Object
Access Protocol and it is a protocol specification for
exchanging
structured
information
in
in
implementation of Web Services in computer
networks. [2] Because of its popularity many
developers make mistake of choosing SOAP
architecture for complex mobile applications like social
network clients. Other options available to developers
are REST based services. Representational state
transfer (REST) is a style of software architecture for
distributed systems, of which the World Wide Web is
the best known example. RESTful means that the
service is conforming to the REST constraints. [3]
Most important constraint is that implementations must
be based on client-server architecture. Every request
must be stateless, which means that server will not
store client context in its memory. Responses must be
cacheable. Other constraints include that system must
be layered, with uniform interface and optionally,
servers may allow code on demand. Commitment to
REST means serialization of data using JSON format
instead XML. This is good approach no matter if the
client application is based on iOS, Android, Blackberry
technology or even in the case of mobile Web.
In the following paragraph we will compare XML and
JSON format for data representation. JSON format is
much simpler then XML. JSON format provides scalar
data types and the possibility of expressing structured
data through arrays and objects. This is more familiar
to the developers because it is object oriented. On the
other side in case of XML there is no concept of data
type. Data types can be added through an XML schema
because XML is document based. Support for arrays is
possible but it is very complicated. Objects must be
expressed through conventions, often using elements
and attributes. Both formats provide a good
opportunity to exchange data with other similar
applications so interoperability is good supported.
Also, internationalization is possible because both
formats use Unicode. This is especially important when
social networks are concerned because these
applications are used all over the world so different
international characters must be supported. Next, in
case of XML developers can add their own attributes
and tags to represent data, which provides good
expandability options, but with the consequence of
complex XML schema. On the other hand, JSON
format supports a wide range of types. Also, developer
can serialize user defined objects inside JSON String.
JSON is gaining on his popularity mostly because it is
very simple format that provides easy conversion of
XML to JSON. This makes JSON more adoptable than
XML, because XML has very complicated structure.
XML is widely adopted by the computer industry and
newer versions of inter-connected systems need to
migrate from XML to JSON, but only if it is suitable.
JSON is much more readable for developers and it is
also easier for the machine to read and write data into
JSON format because of its simpler structure. XML is
less readable because of the extensive scheme with
tags. It is more complex for processing and functions
for parsing XML data can sometime require too much
time to execute. Because social networks are complex
systems that change frequently, process various types
of objects and because they must support integration
with other subsystems in the future, it is clear that
using JSON for data serialization is a better choice.
Next we will show differences between SOAP and
REST architecture when it comes to use within mobile
applications. These differences can help us decide
when choosing the right architecture for the specific
application implementation on multiple platforms.
SOAP is a technology that has been efficiently
implemented within SOA framework for a long period
of time. [4] Many companies have introduced
additional new layers that are based on services within
the existing IT infrastructure and enable the connection
of various applications. SOAP is designed to take
advantage of many protocols for data transfer
(HTTP/HTTPS). This feature allows for described
technology to be a unique solution for heterogeneous
problems that are difficult to modify. It is also
necessary to take into account the important fact that
SOAP is designed before the expansion occurred in the
development of mobile technologies and applications
based on them. The problems that can be encountered
when we develop SOAP systems can be of a different
nature. Changing services based on SOAP often
involves changes in a complex code on the client side.
This is not a big problem when a client is Web
application server, but when the SOAP client is
running on a mobile device, then revising and changing
such application can cause significant problems. One
of the problems is related to complexity. Client code
generation from WSDL and XSD in the case of mobile
devices can be very complex due to the fact that many
companies have to implement the same mobile
application for multiple platforms (iPhone, OS,
Android etc.).
3.
MOBILE APPLICATIONS FOR SOCIAL
NETWORKS
When creating mobile applications for social networks
it is extremely important to enable offline work mode
as well as providing speed and responsiveness with
minimal expenditure of resources, mainly time, to
provide information of interest. With this taken into
account, REST along with the HTTP GET method can
be used in combination with proxy servers. These
intermediary servers can be used to cache GET
responses for the corresponding calls. It is also possible
to cache other requests in a separate database, so if
there are unplanned service interruptions those
intermediary servers store data until the service is back
online. This is particularly important in social networks
where we have many and frequent connections to the
server. On the other hand SOAP requests using the
POST method require creation of complex XML
requests that can greatly hinder the caching server
responses. Efficiency is one of the main advantages of
REST architecture. [5] SOAP always returns complex
XML while REST provides flexibility in which format
will data be returned. JSON format, which is an
integral part of REST, is convenient because it
provides data types that are similar to the types of data
that are sent and accepted in social networks. In the
case of social networks on mobile devices RESTful
services provide the best choice.
As time passes by, social networks gain more and more
importance as users gather around them. Friendships
on these networks are symmetrical, that is, in order to
exchange information with another user on the network
you must get his approval. Over time, large companies
adapted social networks to their needs and then
asymmetric nature of friendship has evolved in sense
that the company may have its own page with different
content. This content is available for all users without
need for the company to respond to their friendship.
Because of the large number of users who are
connecting through some of these systems, over time,
the need arose to separate users in accordance to their
interests. One of the most modern concepts in which
users are divided into groups is known like Groups or
Circles and is used by Google social network.
Therefore, we can conclude that the data and structures
that are being used are becoming more and more
complex. There is an increasing need for the domain
object model on client side to correspond to the server
object model so that these new concepts can be
modeled more easily. Therefore the data format that
server returns are in JSON format, because it is the
most convenient one. It is suitable because it can be
used without a greater need to modify this model to fit
the client’s domain object. Consequently social
networks have evolved over time from SOAP to REST
architecture. In other words, mobile social networks
have evolved from XML to JSON. JSON format
supports the user data types while XML is difficult to
adapt to client domain object. Large heterogeneity of
interests and a large number of users causes the
problem of preserving privacy and security when using
such systems. In SOAP architecture there is a
particular SOAP layer of security which tells exactly
which user is logged on the system, what are its roles
in this system, what data he uses etc. This layer is not
that well supported in the REST architecture. One of
the reasons for this is the increasing amount of
information that is associated with the user and that is
very difficult to control. Information that is
manipulated in the social networks is maps, weather
info, user interest, user’s thoughts, jokes that belong to
the less sensitive information. There is also more
sensitive information such as emotions, information
about family, work, and reminders and so on. All this
diversity of information is just a consequence of the
diversity of groups that gather around such systems.
That is the reason why the issue of security is a major
challenge facing the REST. If new architectures
successfully deal with security issues in the future,
such types of applications and areas covered by the
information will be much higher. Lack of security is
now somewhat tolerated precisely because these
systems are not handling very sensitive information but
that is rapidly changing. In our approach have been
using security tokens which are passed along with the
request in its header to the server and whose validity is
checked at the moment of request addressing. In order
to obtain data from the server token must be validated.
Tokens are valid for only short period of time.
4.
required by the mobile clients. Also when user gets
data from Facebook it is necessary to make a new
request for each contact (larger number of requests)
including the request for authentication. With newer
versions of API functions for accessing Facebook
services these disadvantages are largely eliminated, so
now the RESTful API access is provided in better way
than it was the case earlier. However generally if we
look away from the mobile world there are situations in
which it is still suitable to use SOAP architecture and
this may lead to incorrect architecture choice.
5.
INCORRECT IMPLEMENTATIONS OF
REST METHOD CALL ON ANDROID
CLIENTS
REST SERVICES IN SOCIAL NETWORKS
Today most of the Web services on the Internet are
based on the REST architecture. The most important
systems on the Internet that provide a RESTful
interface to access their services are Flickr and eBay.
Amazon supports combination of SOAP and REST
approaches. These are all great systems which we can
use as a recommendation for REST today. From the
group of systems that use REST, mobile social
networks are among largest because they support tens
of millions of transactions per day. Typical
representative of social networks that provide RESTful
API for retrieving data from the system is Twitter.
Developers can access information about Twitter user
by forwarding requests through the URL or GET
method. Information about user is received as JSON or
XML format. On the other hand we have the popular
Facebook social network where the use of RESTful
APIs for data access has been significantly limited as a
consequence of the Facebook policy. If developers
want to access information from Facebook via REST
API, apart from the user authentication, they must also
obtain API key from Facebook. On top of all,
Facebook restricts which IP addresses are allowed to
create requests. Because of these limitations, Facebook
decided that their system is not suitable for RESTful
API. HTTP POST is used for authentication and as a
result it returns an HTTP cookie that is used for each
later request. Twitter is more convenient for developers
and there are several aspects that support the
development process and also make application more
attractive to the mobile users. The first aspect relates to
a reduced number of HTTP requests. All information
from Twitter can be retrieved with only one request.
Because of the reduced number of requests, there was a
significant reduction of amount of processing
necessary to obtain the information of interest. This has
also cut the amount of data transferred, which is one of
the most important features that were bought from
REST. On the other hand we have Facebook
application that needs a lot more processing for data
retrieval. This is the consequence of the fact that the
application displays in the browser which uses
additional
information.
Considering
modest
capabilities of a mobile device compared to the PC, we
acknowledge that very large processing time is
Many authors suggest approach that involves multithreading. [6] Main, UI, thread would be used for
issuing commands, while another, background thread
would make the service call. There is a special class
called AsyncTast, that is part of the Android API and
that helps us perform background operations and
publish results on the UI thread without having to
manipulate threads and/or handlers. AsyncTask is short
for asynchronous task. "An asynchronous task is
defined by a computation that runs on a background
thread and whose result is published on the UI thread.
An asynchronous task is defined by 3 generic types,
called Params, Progress and Result, and 4 steps, called
onPreExecute, doInBackground, onProgressUpdate
and onPostExecute". [7] This class must be subclassed
in our class in order to be used. It must override at least
one method, doInBackground, where we define what
will be done in a separate thread and most often,
another one, onPostExecute, which will be executed on
the main UI thread and show the results of the
background thread. It appears that all basic principles
are complied with, we have preserved UI
responsiveness by giving long running operations its
own thread and after it finished its job, all the data is
synchronized.
The problem with this approach lies in the very
foundations of the Android operating system. Its
process manager may decide to kill any non-responsive
process or process that doesn't seem to be
active. There are many reasons why our process may
become non-responsive. REST method may take long
time to execute due to large data transfer. Or some
other activity, such as phone call or SMS, may come to
the front and that will cause activity that is running
asynchronous task to pause. There is no way for
onPostExecute method to catch the results of a REST
call if the hosting Activity is not running. Also, if the
worker thread that is running REST method is
terminated than all the data that has already been
transferred is wasted and so is the valuable processor
time and we have to start all over again. Good
approach here is to cache data so in case of activity
restart, user or system initiated, we do not have to
waste CPU time or bandwidth.
6.
PROPOSED DESIGN PATTERN
The general idea on how to overcome these obstacles is
to apply a pattern that would ensure all long running
work is done in a separate thread, but without the risk
of getting forcefully killed by the Android operating
system. It is also crucial to ensure that all the data
received from a REST call can be cached for future
use. We can achieve the first part by using Service
class that is part of the Android API. “A Service is an
application component representing either an
application's desire to perform a longer-running
operation while not interacting with the user or to
supply functionality for other applications to use”.[8]
However, it is important to realize that Service is not a
separate process nor it has its own thread. While this
may not be appropriate for use “out of the box”, it is
possible to create a separate worker thread when
creating the Service object in onCreate() method. The
Android system will attempt to keep the process
hosting a service for as long as the service has been
started or has clients bound to it. Process manager will
award it the highest priority when the system is
running low on memory and there are decisions to be
made about process killing.
This approach may seem a bit complicated because we
need to maintain and synchronize UI and worker thread
by ourselves, but the Android API has another class
that can be of great use to us. This class is called
IntentService and it has been part of the Android API
since API version 3. “IntentService is a base class for
Service that handles asynchronous requests (expressed
as Intents) on demand”. [9] Intents can be perceived as
an abstraction of an operation that we want to be
executed. Intents most common use is in launching
activities. Client creates IntentService by sending
appropriate Intent through startService(Intent) call.
Service is then created and started as needed; handles
every Intent message inside its own worker thread and
stops itself when all the work is done. This pattern is
also known as “work queue processor” because it is
widely adopted as a mean to offload tasks from an
application's main thread. It is also important to say
that IntentService only uses single worker thread and
maintains request queue. Any request may take as long
as necessary, but only one request can be processed at
a time.
After IntentService finishes its work it needs to send
results data to the main UI thread. This can be achieved
through BroadcastReceiver [10] class that is part of the
Android API. Receiving activity registers for broadcast
by Context.registerReceiver() method call or we can
statically publish an implementation through the
<receiver> tag in our AndroidManifest.xml file. There
are two types of broadcasts: normal and ordered.
Normal broadcasts are run asynchronous and receivers
get them in an undefined order, often at the same time.
Ordered broadcasts are delivered to one receiver at a
time. When receiver get broadcast message it can
propagate it to another receiver or it can break the
receiving chain with abortBroadcast() method call.
Broadcast receiver object should not be used for
asynchronous or long running operations because it has
very short lifecycle. In fact, if BroadcastReceiver
object hasn’t finished executing in ten seconds,
Activity Manager will fire Application Not Responding
event and show dialog with question to the user if he
wants to force close the application or wait a bit more.
Process that is executing BroadcastReceiver is
considered to be a foreground process and will be kept
running by the system. Because of that, if we want to
notify user that service had finished its job, we should
either use NotificationManager API or activate dialog
in the hosting process.
When data caching is concerned there are many ways
we can keep our data in persistent memory on Android.
But when it comes to means for actual process of
storing and retrieving data we have only one, obvious,
choice. That choice is ContentProvider class. “Content
providers store and retrieve data and make it accessible
to all applications. They're the only way to share data
across applications; there's no common storage area
that all Android packages can access”. [11] There are
many predefined content providers for common data
types such as audio, video, images, etc. If we want to
make our data publicly accessible we can either put
that data in an existing provider or we can create our
own content provider by sub-classing ContentProvider
class that is part of the Android API.
This concludes definitions of all of the necessary
components that we can use in our design pattern.
Pattern is given in the following figure.
Figure 1: Main classes in the pattern
Activity which is running on our main UI thread
displays data that we have in our Content Provider.
Once we initiate a REST call we pass parameters to
Intent Service. It is important to note here that if we
want to execute a GET method, we should provide a
way for the remote server to return only the data that is
newer than the one we have in our content provider
(“smart update”).
REST Method is an entity which is in charge of
preparing HTTP method and HTTP request body. For
HTTP method calls we use Apache library for Java
from the package org.apache.http.client.HttpClient.
We already noted that for request data we use JSON
serialization. If we need to exchange large amounts of
data with the remote server we can use gzip
compression. [12] Gzip is an open source utility
designed to be used for data compression. It is
supported by man client libraries, browsers and server
platforms. Once the method is prepared, HTTP
transaction is executed and its response is then
processed. If the response is valid, result data is
returned to the IntentService, otherwise exception is
thrown. Since IntentService runs in its own thread, this
REST method call is also made in that thread so
application remains responsive no matter how long it
takes to execute it.
When IntentService receives data from the REST
entity it processes data and if data is valid it sends the
data to the ContentProvider entity for insert or update.
After this is done IntentService sends broadcast
message to the calling Activity that contains either
success notification or error message. Because code
inside Intent Service is executed in a separate thread it
is very suitable for complex operations. Operations that
can be run inside Intent Service are some local
database operations, for example (INSERT,
UPDATE and DELETE). This operations start after
response is accepted from server side and is parsed
from JSON. This is a part of a greater task of
maintaining a local cache memory for better
application performance. On the other hand, Receiver
is only suitable for some short operation because it
accepts response from Intent Service inside main
thread. It is good place for some notifications intended
to end user, for example Alerts about status of
requested operation, but nothing more.
Activity contains registered BroadcastReceiver that
handles Broadcast messages in onReceive method. As
we already stated, BroadcastReceiver has a very short
lifecycle that only last during onReceive method.
Because of this we do not send result data in a
broadcast message, even thou we could, because result
processing could take long time to execute. Instead, all
the work was done before IntentService sent the
broadcast message and now all that is left to do is to
asynchronously refresh data that Activity shows.When
BroadcastRecevier receives message it will notify
Activity that it should query back ContentProvider for
new data or, if the message contains exception, it will
notify user of the error that happened.
7.
CONCLUSION
Mobile devices and social networks have become part
of our everyday life. Android, as the currently
dominant smartphone platform is offering great
number of social network client applications on its
market but the quality of those applications needs to be
taken with a grain of salt. As REST is currently
standard supported by many social networks it is vital
to choose a good approach when designing android
client for social networks. In this paper we have shown
main differences between REST and SOAP, as well as
their main message coding standards. We have
presented what we consider wrong approach for the
HTTP method call and shown one possible
implementation of the RESTful pattern on Android
client. By applying this pattern when developing
Android client applications you can take full advantage
of the API that Android platform provides and make
your application work better. This can be achieved
through more responsive user interface, use of fewer
phone resources and overall lower bandwidth usage.
REFERENCES
[1] Cozza, R. Gartner report“Forecast: Mobile Devices
by Open Operating System, Worldwide, 2008-2015”,
http://www.gartner.com/it/page.jsp?id=1622614,
Retrieved 4. 2. 2012.
[2] Englander, R. “Java and SOAP”, O’Reilly Media,
May 2002
[3] Masse, M. “REST API Design Rulebook”, O’Reilly
Media, October 2011
[4] Alonso, G. Casati, F. Kuno, H. Machiraju, V. “Web
Services, Concepts, Architectures and Applications”,
Springer-Verlag Berlin Heidelberg 2004
[5] Webber, J. Parastatidis, S. Robinson, I. “REST in
Practice”, O’Reilly Media, October 2010
[6] Jordan, L. Greyling, P. “Practical Android
Projects”, Apress 2011
[7] Android.com, “AsyncTask”,
http://developer.android.com/reference/android/os/Asy
ncTask.html, Retrieved 4. 2. 2012.
[8] Android.com, “Service”,
http://developer.android.com/reference/android/app/Ser
vice.html, Retrieved 4. 2. 2012.
[9] Android.com, “IntentService”,
http://developer.android.com/reference/android/app/Int
entService.html, Retrieved 4. 2. 2012.
[10] Android.com, “BroadcastReceiver”,
http://developer.android.com/reference/android/content
/BroadcastReceiver.html, Retrieved 4. 2. 2012.
[11] Android.com, “ContentProvider”,
http://developer.android.com/reference/android/content
/ContentProvider.html, Retrieved 4. 2. 2012.
[12] WebReference.com, “HTTP Compression Speeds
up the Web”,
http://www.webreference.com/internet/software/server
s/http/compression/index.html, Retrieved 4. 2. 2012.