A Unified Push Notifications Service for Mobile ...

A Unified Push Notifications Service for Mobile Devices Suresh Kumar Gudla, Joy Bose, Sowmya Sunkara, Shailendra Verma Web Solutions Samsung R&D Institute India- Bangalore Bangalore, India {suresh.gudla, joy.bose, sunkara.s, verma.shailu}@samsung.com Abstract— Push Notifications are widely used in a variety of platforms like GSM, CDMA for various applications servers to communicate with their clients to give real time updates without any pull strategy. They are also used by different service providers to advertise their services to users. However the notifications from different providers are not integrated at the platform level. In this paper we present a unified push service from multiple platforms on a mobile device. Our service provides a generalized interface to accommodate any kind of new push platform. As the service is a unified background service, additional features can be developed to benefit the users and content providers, as well as provide relevant data to applications. Applications have the option to either process the new push messages directly or to send the messages to the notification center without processing, thus enabling power and performance optimization for mobile devices. The service can be used by all the apps and individual mobile applications need not poll separately for information, thus saving power and memory at the device. The service also supports multiple push platforms at the same time. We provide a few unique use cases where this kind of unified service for push notifications can be useful. Finally, we present the results of a few experiments to study the performance metrics of our push architecture, including the latency of receiving push notifications from different sources on the device, as well as the memory consumed by applications using the unified push platform. Index Terms— Web Push notification; Web browser

I. INTRODUCTION AND PROBLEM STATEMENT There are many legacy push systems for servers to communicate with their clients randomly. Some of these are proprietary while others are dependent on the carrier. This makes it difficult to get an open standard for push without any carrier or vendor interference. Most of the existing push systems do not allow flexibility for application developers and our present app-store ecosystem, where flexibility is a key factor. A simple push system is based on SMS, in which a server can reach its client by sending app directed SMS messages. However an SMS message is paid and has to always go through the carrier. Hence, the SMS based approach does not offer flexibility to application developers and its eco-system, because of their dependency on the carriers. WAP push system is another legacy system where the content is encoded as directed by the Open Mobile Alliance. Copyright©IEEE2015

Two basic types of WAP push message are defined by the WAP Forum. They are Service Indication and Service Load WAP Push messages. A WAP Push message is based on the WDP protocol and can be delivered to clients through any of the WDP supported bearers such as GPRS, SMS etc. To send the messages to the client, a Push Proxy Gateway is also needed which is maintained by the carriers. A WAP Push Client at the device processes these WAP Push Messages and delivers to applications like MMS, FOTA, and Browser residing at the client mobile device. This full eco system again adds dependency on the carriers and brings in scope for proprietary mechanisms. This system is also not suitable to the present app developer’s eco system. There are other HTTP connection based push platform implementations, using either web sockets or pushlets or HTTP streaming. Most of these implementations require the clients to be awake to receive the push messages, which is memory consuming and power consuming. This system is also not suitable to the present app developer’s eco system. The push notifications platform enables users to receive important messages and advertisements from the servers to clients without the need of the client always remaining connected to the server. Existing push notifications platforms are proprietary standards wherein each and every application have their own logic of getting push messages by keeping their applications or web-apps online or off line. These proprietary mechanisms are not interoperable and are limited to certain platforms and applications. Some existing push notifications platforms are further enhanced to address certain aspects or power and memory and instead of each application having its own push module or dedicated channel, the app eco system tries to move to a more generalized push platform. Many smart phone platforms are trying to address this problem in various ways. Web Push Notification [1] is an evolving standard proposed as a WWW editorial draft to address the needs of web-apps. However, this standard is not easily extendable to web browser applications and does not address problems of fragmentation, power, memory and security in real time scenarios The specification when extended to data centric applications like the web browser still faces some challenges as the final user agent (engine) is implemented by some OEM or vendors like Google, Mozilla and Samsung etc.

In this paper we propose a better solution for push notifications by having a single unified background service to handle all push notifications from different push providers at a client, with the following added advantages:  Well defined interface at client handling multiple push platform providers  An Application can choose any of the available Push Platform Providers  Push platform provider settings and flow can be customized as required by the applications.  The service supports multiple platforms, so has its associated advantages.  The service enables power saving by defining how to handle the less important push messages.  This background service can also give extended user interface elements when requested by individual applications The rest of the paper is organized as follows: in section 2 we look at related work in the area. Section 3 gives details of our proposed approach, and section 4 its advantages. Section 5 looks at a sample use case using our push notifications platform. Section 6 presents the results of some tests to measure the latency of receiving notifications and the power consumed on the device. Section 7 suggests some avenues for future work, and concludes the paper. II. RELATED WORK There are some existing related push notifications systems: The Apple Push notifications, which is a proprietary mechanism for the Safari browser, the Mozilla simple push for Firefox OS web Apps and the W3C Push API for web apps which has recently been adopted by the Chrome browser. In this section we review these existing systems. We will not focus how the individual Push Platforms execute their functionality, rather we are interested in how they are integrated or used by various applications. The Apple Push Notification [2] is a proprietary standard that supports Push messages. Applications opened in the Safari browser have the option to register with the APN server and get Push messages later as sent from their app server. When a new push message comes, the notification will be displayed to the user. The Apple system suffers from some drawbacks which are as follows:  All the push messages are directed to the notification center without any option for validation by the applications.  APN is a proprietary standard and is not easily adaptable to other platforms  ‘Man in the middle’ attacks are possible with this approach.  User login authentication is not possible with this approach. Another system is Mozilla Simple Push [3] that is implemented with W3C editorial draft for web-apps. This framework is tightly coupled with web-apps and is based on lightweight simple push mechanism. Each individual web app

has to register for push notification messages and has to process the lightweight Simple push messages received later, judge and then decide whether to display to the user or not. However it too suffers from some drawbacks which are as follows:  Mozilla Simple Push is not compatible with nonMozilla OS’es like Android.  The web app has to connect to the application server upon arrival of each push message. This adds to extra power consumption and always data connectivity is needed.  Mozilla Simple Push needs an individual web app which adds to memory fragmentation. A new web app has to be installed even if user wants to experiment with a trial service. Chromium engine based Browsers using Chromium Engine M40 officially support the service worker based implementation [4]. The W3C Push API implementation in Chromium Engine [1] is based on service worker but is tightly coupled with Google Cloud Messaging. The Service worker based approach gives the flexibility of not having the Web page to be opened all the time, but it needs to wake up when it is not running. In those cases, the service worker will run in a separate privileged process. Each page installs its service worker on its behalf and expects to do the necessary action further. However this approach has the below disadvantages:  The Chrome implementation is tightly coupled with service workers [4]  The implementation is tightly coupled with Google Cloud Messaging (GCM)  The implementation does not address seamless service continuity in areas or countries where Google services are banned.  The Google Cloud Messaging (GCM) payload has a limitation of 4k size. Applications have to live with it.  The GCM Server stores any message for a maximum of 4 weeks only.  Adapting to any other push platform provider supporting these limitations is not possible as it requires engine changes of the Chrome browser.  Chrome Does not support platforms like BADA, Tizen and other non-Android operating systems  Chrome mandates all the messages to be sent to the service worker, which is a power consuming activity due to waking up of the browser engine The JBOSS PNS platform [5] is another available platform that supports mainly Apple and Google services. However, it is not a generic service that can work with any push provider. Thus we can see that each of the existing push providers suffers from many issues. Thus we need to have a unified service to address multiple push platform providers within a platform. If such a background service can address multiple platforms, it will be an added advantage for the application ecosystem.

side addresses multiple push platform providers. A similar concept, if followed at the server, gives more flexibility and opens many new horizons. This unified service allows the flexibility to applications developers to always use an alternate or fall back push platform provider without the need of developing any kind of country specific policy or when any kind of payload limitation arises. In the following section we consider the architecture of our proposed approach. III. PROPOSED APPROACH In our proposed architecture of a unified service for push platforms, applications have the flexibility to use any particular platform from the available set of platforms. During the device boot up or during application launch, applications can query for available push platforms and register for the platform desired. This is a background service which always runs at the client side. Individual applications need not be alive to listen to the new push messages. The service receives new push messages and sends them to applications via registered call backs or events or intents. Depending on the smart phone platform, the application wakeup can be either handled by the smart phone platform or by the unified service. Fig. 1. Flowchart illustrating general push platform registration procedure using the proposed unified service from an application in any smartphone platform.

Fig. 3. Architecture of the system showing a sample subscription of the user for the push notifications from the content provider

Fig. 2. Flowchart illustrating the general new push message handling by the proposed unified service in any smart phone platform

Since the service exists at the client side of a platform, parts of the code, interfaces and design can be reused and ensure the same kind of benefits to applications. This service at the client

In our proposed system, applications can be opened via an extended web browser which supports additional functionality required for embedded devices apart from the W3C editorial draft. The extended browser should support the below functionality for additional benefits given through the unified push service:  An Associated URI or ID of the application is passed during registration in order to handle the newly received push messages at a later point.  This Associated URI can have either native JavaScript (JS) implementation or the service worker based implementation, which shall receive the new push message.  Using this URI or ID based on the parameters mentioned in the push message, the unified service can send the push message to the application for internal

processing or authenticating the message. The unified service can also send the message directly to the notification panel as registered by the application. The service can also decide to store the message in a permanent repository as registered by the application.  When a new push message comes, it carries basic data like the title, icon URL, body, expiration data, authentication data to identify the device and the target browser application. Additionally it can also contain the message type and its corresponding data for any of the display related functionalities as per the model. The following operations are needed when a new push message is received:  If the message is non-secure, then it should have a simple Reference URI which can be launched upon user selection. This approach is primarily needed when accommodating applications in the retail market.  If the message is secure then it should have App-Data to provoke the notification handler service to get the data authenticated by JavaScript handlers as suggested by the Associated URI. This approach is primarily needed for content providers like travel sites etc.  If strict authentication is needed, as in the case of mail apps, the Unified service based on the Associated URI can prompt the user to enter credentials to authenticate. This approach is mainly needed for content providers like banking sites etc. A typical push platform registration flow diagram for an application is illustrated in Fig. 1. This unified service runs as a background service in the mobile device operating system (Android for example) and always exists at the client side. Individual applications need not be alive to listen to the new push messages sent from the server. The service will receive new push messages and send them to applications via registered call backs or events or intents in case of Android platform. Depending on the smartphone platform, the application wakeup will be handled by either the smart phone platform or by the unified service. A typical new push message flow is shown in Fig. 2 and Fig. 4.

Fig. 4. Architecture of the system illustrating the delivery of push messages to the main device and connected devices such as the Gear smart watch

IV. ADVANTAGES The proposed unified push notification system is for embedded devices or platforms that do not support web-apps. This is a hybrid approach on top of the W3C editorial draft which ensures the following advantages in terms of power and security to the end user with the help of an extended browser application:  There is no need to have multiple web-apps for each service.  There is no need to have platform support for registering of push messages and receiving of push Messages  When a push message which is of type general arrives on the mobile device, there is no need to launch the browser application to get it processed. This way additional power will not be consumed.  When a push message that needs previous login credentials arrives on a mobile device, it can be passed as part of the message. In such a case, the browser app can authenticate itself or with the help of the Associated URI registered earlier. This operation can be done by keeping the browser in the background. This way it ensures power saving.  When a push message which contains no data and is of the secure type arrives at the mobile device, the browser application will send to the Associated URI which has the mechanism to get authenticated by the user. Thus this system ensures extended security before displaying a notification to the user. If the user refuses to authenticate, the message can be ignored.  The proposed system has a lightweight background service to handle initial processing of push messages and thus enable the browser to decide further how to handle the received message. This service can even decide to notify to connected devices such as smartwatches and tablets.  The proposed system also addresses the case of having multiple instances of the same application and multiple instances of the browser application as supported in the latest Android systems.  The dynamic update of the resources in the device (such as icon of the domain during subscription) is possible with this system.  Based on the user context and other features, the message type and frequency of the push messages can be changed by the content provider.  With respect to power, an additional advantage in this system is that every message need not be processed by the application (as in the Mozilla feature), rather it can be passed directly to the notification manager. Only selected secure messages (which need additional security validation) need to be passed to the application.  With respect to security, this system gives additional security since we allow the application (pass URL) to validate the new message with the user credentials.

V. SAMPLE USE CASE APPLICATION In this section we present details of a sample application using our system to generate push notifications. We developed a Unified Push Service Client at the mobile device. We wrote a sample application which makes use of web view to open the web pages. This sample application binds the service and implements the AIDL interfaces provided by the Unified Push Service. We also created sample demo pages to test all the Push Service APIs and are able to receive push messages using the same. The Unified Push Service gives any AIDL interface to give overall functionality to the applications to use. Applications can call the exposed public APIs to achieve the desired functionality of using multiple push platforms. Following are the interfaces exposed by Push Service to 3rd party Applications:  getAllAvailablePlatforms() gives the details of all the available Push platforms for the applications.  registerForPlatform() allows any application to register for the platform specified in the input parameters.  unregisterForPlatform() allows any application to unregister for the platform specified in the input parameters.  getSettingsForPlatform() gives back the existing settings of the push platform for the applications specified in the input parameters.  setSettingsForPlatform() sets the settings of the push platform for the application specified in the input parameters.  setPushMessageCallback() allows an application to set its message callback to be called when a new push message is received. If callback is not specified by an application, the message will be pushed to the default quick panel for user notice.  SetPushMessageStore() allows an application to specify push messages to be stored in the unified service for later use.  GetPushMessageByID() gives the application the requested message by the given ID. If no message exists for the given ID, a null will be returned.  DeletePushMessageByID() deletes the message from the database of the unified service as given by the ID. If no messages exists with the given ID, this returns null.  newPushRecieve() an internal API of the unified service which listens to messages of push platforms. This API is not exposed to other applications.  getAppDetails() an internal API of the unified service which is used to get details of the application when a new push message is received. This API is not exposed to other applications.  setDisplayMessage() gives the choice of displaying the new push messages to applications instead of waking the app when a new push message comes.

Fig. 5. Comparison of memory consumed by applications using the Baidu Push Platform in Kb, with and without the unified push service

VI. LATENCY AND MEMORY TESTS OF THE UNIFIED PUSH PLATFORM

In this section we describe some experiments to measure the memory consumed by various applications and the latency of the message delivery. A. Memory test For the memory tests, we created 5 sample Android applications with an activity containing a register button and message receiver and each application loading its own Baidu push platform library. The application size of each Android application was 265 KB, so the total memory size for 5 such applications was 1325 KB. In our approach where a unified push service exists, the memory consumed by an android application is 198 KB and the memory consumed by the unified service is 148 KB. So the total memory consumed when 5 such applications using this unified services is 1138 KB which is nearly 15% savings for an environment with 5 sample Android application using the Baidu Push Platform. The percentage of memory savings will increase further when no of such applications increase. Fig. 5 presents the results of the memory test on the utility of our unified push platform in reducing the total memory size as the number of applications increases. B. Latency test For the latency test, we measure the time difference between the time a push message is sent from an application server and the time the same message is received at the unified push service client. It should be kept in mind that the latency depends on a number of variables, including the load on the server, which is out of our control. Hence, the test results in this case should be taken as indicative. For our latency tests, time difference (between the packet sending at server and receiving statistics time at server) is measured by using the message statistics API at the application server. We compare the latency across different push servers including GCM and the Samsung Push Platform (SPP). Readings were taken using a Samsung test server and a Note 3 device within a LAN. The packet size was 344 bytes. Using the GCM push platform we obtained a latency of 5 seconds and using SPP we obtained a latency of 4 seconds. The main advantage of having our unified push platform is the following: the system can store the last known latency of

sending a push packet using each of the available push servers such as GCM and Baidu. When a new packet has to be pushed, the system makes an intelligent decision using the last known latency and other parameters such as the geographical location of the server and its proximity to the destination if known, and uses this to decide which push server to use. If any application uses the standard push platform to reduce latency, they do not need to implement all other push platforms, instead they can integrate with the unified push service where we can switch the platform based on our requirements and the need of the application. In this way the message latency and size limits cease to be an issue, and high priority messages can be routed through the fastest available platform. C. Power test Considering a survey of users using various apps like Gmail, apps publishing adds a user might get nearly 20 push based messages. If all 20 are sent directly to Notification center then there is no security addressed. If all 20 are directly allowed to be handled by Browser then there will be a huge power surge. So if there is a hybrid approach, it will give more security and power saving and avoid fragmentation by using multiple apps. The table 1 gives power measurements on a Samsung Note 3 device while receiving push notification using our unified service. For our experiments, we used the option to send new push messages to the notification panel provided by the unified service rather than waking up the browser. This way we can save a good amount of power. When the user clicks the message in the notification panel, the original application like the web browser can be woken up to process further the user response and any other processing required by the content provider as directed in the message data.

TABLE I.

POWER MEASUREMENTS ON A DEVICE USING THE PUSH NOTIFICATIONS PLATFORM

Device in idle screen 36 mA

Browser handling an URL 360 mA

Browser in the background while the screen is off

Lightweight service handling push messages

260 mA

260 mA

VII. CONCLUSION AND FUTURE WORK In this paper we have presented the design of a unified service for handling multiple push notifications. In future we seek to implement more and varied use cases on our push notifications platform like handling of enhanced UI layouts, handling of integrated services of other application via push messages, handling of data recommendations and handling of content for connected devices. REFERENCES [1] Push API, W3C Editor’s draft 19 Jan 2015. [Online]. Available: https://w3c.github.io/push-api/ [2] Apple developer documentation. Local and Push notifications. [Online]. 2014. Available: developer.apple.com/notifications/ [3] Mozilla Wiki. WebAPI / Simple Push. 2014 [Online]. Available: wiki.mozilla.org/WebAPI/SimplePush [4] Chromium Service worker developer community. [Online]. 2014. Available: http://www.chromium.org/blink/serviceworker RedHat [5] JBOSS Unified Push Server Manual. [Online]. Available: docs.jboss.org/unifiedpush/unifiedpush.pdf