Push-Notification
- 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.