1. PUSH NOTIFICATION FROM AN APPLICATION SERVER.
Abstract – Most of the apps build around the server-client architecture use PULL
technology to get information from the server. The PULL technology works efficiently for
synchronizing mail or other such applications from a desktop computer, but when it comes
to a mobile device like a smartphone or a tablet, the drawbacks of the PULL technology
are flagrant. The proposed system exploits the possibility of PUSH technology from a
server, which has definite advantages over the PULL technology. Also, the app makes an
entry into the devices’ calendar (Calendar Event), which sets a notification at the stated
time.
Keywords – Android, Google Cloud Messaging (GCM), PUSH notifications.
I. INTRODUCTION
Most of the Mail Sync, Social media and messaging apps use PULL technology to
retrieve data from the application servers. These apps either have a worker thread in memory or
restart the app after specific amounts of time and sync data. However, if the device senses a
shortage of memory, the OS might decide to kill apps running in the background. Also, other
factors like hardware failure make these techniques unreliable. Moreover, having an app which
constantly sends and fetches data has a negative impact on the battery.
This article elaborates about how an Android powered device can receive messages from
the servers without being in polling mode. By not being in polling mode, we mean that the
application does not have to remain in memory nor does it periodically sync data from the
servers. PUSH technology has many advantages over the more ubiquitous PULL technology.
The app also handles messages coming from the server. The app is designed to create a
new calendar event with a configurable notification time. Therefore, this app provides a channel
through which 3rd
party companies can send notifications to their registered customers.
II. PULL AND PUSH TECHNOLOGY
There are two methods from which a device can get data from the server - PULL
and PUSH.
a. PULL technology:
This is the more prevalent of the two methods. Most of the user-end applications
use this technology to get data from the server. The PULL model is elaborated further.

2. Fig. 1
The red arrow in Fig. 1 shows the initial direction of communication to retrieve
data from the server. The device first queries the server to find if it has any unsynced
data. If there is any unsynced data it is sent over to the device. Now, in this model each
time the application running on the device has to query the application server, this
implies that the application has to remain in main memory, however, the application
might be expunged from memory when there is shortage of memory or a hardware
failure. In such cases the application will not be able to sync data from the server; the
user will not get any messages from that particular service. Also, the application has to
periodically send query messages to server which results in additional internet data
transfers. An alternative to PULL technology is the PUSH technology.
b. PUSH technology:
In this model the server pushes out messages towards the device. Once the
device receives a message, it can route to the respective application. The further
actions are decided by the application.
Fig. 2
The device unlike PULL does not have to keep querying the server. The
application server, looking at checkpoints knows which data is to be synced. This data is sent to
the device. This results in lower internet data traffic from the device as well as the application
does not have to be in the main memory. However, if the device is in offline (not connected to

3. the internet) mode the messages will rebound and the server will try to send the message after a
back-off period.
III. EXPERMINETAL HARDWARE
The app works on all Android powered devices with Google Play Services. The device
also needs a minimum API level of 4.0.4 (Ice Cream Sandwich). For experiments a SONY
Xperia Z1 with Android Version 4.2.2 (Jelly Beans) was used.
The backend system used a simple web server (WAMP), which handled the incoming
traffic from the app. A web server is also required for sending the notification messages. We also
need a database to map username with respective register IDs. This database will also be used
while sending notification messages to subscribed customers.
IV. MODEL SIMPLIFICATION
The diagram Fig.3 Shows the overview of the entire system. The system basically has
three nodes. First is the application server for the app second is the Google Cloud Messaging
interface and the Third is the device running Android. The figure can be explained in two parts.
First is the custom web application that is running on application servers, which connects and
POSTs messages to the GCM server. The second part is the actual Android application running
on the device that is capable of handling incoming GCM messages. This part is also responsible
for making an entry into the devices calendar.
Fig. 3

4. • APPLICATION SERVER AND GCM SERVER:
• APPLICATION SERVER:
Application servers are 3rd
party servers which carry out two important
activities, first storing the username and their registration ID and second, sending
HTTP POST notification messages to the subscribers.
When the app is first launched on the device it will give out details
regarding the availability of Google Play Store. If Play Store is available on the
device then the app will prompt the user for a username. Once, the username is
given the app will register itself with the GCM server as well as with the
application server.
The application server has to manage a database, mapping of usernames
with their respective registration IDs. This comprises the first activity of the
server.
For the GCM, Registration IDs are the primary key for identifying
customers uniquely. Hence, while sending notification messages these registration
IDs are looked up against their usernames. A common message can be sent up to
1000 devices in one go. All the data sent from the application servers to GCM has
to be in JSON format. In our case, as we will be creating a new event in the
device’s calendar, we need to send data regarding the date, time and mode of
notification and description of the event. We can send up to 4Kbs of data in one
packet.
• GOOGLE CLOUD MESSAGING SERVER:
This server is pre-configured by Google. Once GCM receives a HTTP
POST from the application servers, it is GCM's task to send packets to the
individual devices. GCM also returns a status codes (for each individual requests).
These can be used to find out which messages have reached their destination and
which of them need to be re-transmitted.
The GCM services are free of cost. Two authentication keys are required-
a GCM Project Number and an API key. Both the keys are generated once we
sign in through a Google account. Project number is required by the app whereas
API key is required when we are sending data from the application server to
GCM.
• ANDROID APPLICATION
• ANDROID DEVICE:
The Android application plays an important role in the overall system. By
installing the APK, the client decides to subscribe for a particular service. The

5. client also has to register himself with the service providers before he starts
getting PUSH notifications. The Red direction in Fig.3 shows the one - time
communication between the client and the 3rd
party application server.
Further, even if the app is not in memory anymore, it will still be able to
handle GCM messages intended towards the app.
If the device is online (connected to the internet) it will receive the
message, however, if the device is in offline mode then the message will be
queued in the GCM server. The message will be stored in the GCM for a
maximum 4 weeks.
CALENDAR ENTRY:
The GCM message that is directed towards the app extracts information
out of the JSON message. Information like date and time of the event has to
be created. Once the event is created it will give out a notification at the
configured time.
V. RESULTS AND CONCLUSION
GCM provides an efficient way of communicating with Android devices,
especially for lightweight communication. PUSH notifications can be
implemented using GCM. This also results into better battery life for the device as
well as reduced memory and bandwidth requirements.