API for communicating through GCM

At beginning, I started with an API for communicating through GCM with mobile devices running Android. I developed a way of building the messages, sending them and handling the result.

To build the messages, I developed a data type: GCMmessage, where you can customize some parameters for the servers providing the GCM service.

To send the messages you need to establish some server configurations through the data type GCMAppConfig (as the correct Api key provided by Google). Passing this configuration, a GCMmessage and a number of retries as arguments to the function sendGCM, the notifications will be sent to the GCM Servers.

The result is shown in a new data type: GCMresult, which provides some useful information, as selecting the devices that have changed their regIds, or have been unregistered, and so on. The programmer can take his own desitions on how to handle this result in his server.

To show a simple usage of this API for GCM (Network.PushNotify.Gcm), I developed a simple test example of a Yesod server, where devices can register to receive GCM messages and users can send messages through the web service. This is composed of:

+ a Yesod app for registering the devices and sending push notifications.

+ an Android app for registering on GCM and receiving the notifications.

It is available on: https://github.com/MarcosPividori/GSoC-Communicating-with-mobile-devices/tree/master/push-notify/test

The picture at the bottom shows the main structure of the Google Cloud Message service. We have 3 main points:

+ The server, which I developed as a Yesod app.

+ The devices, running Android.

+ The GCM Servers which provide the service.

About the Yesod App:

In this example, I show how to handle with the registration of devices. Also, I provide a web service, so users can send notifications to the devices registered. When the server receives a post request to send a notification to a device, uses the GCM apis for sending the notifications and handling the result in order to correctly actualize the DB. This means removing the devices that have been unregistered, changing the regId of the devices that have changed, and resending the notifications that weren't sent because of an internal error in the GCM Servers.

To try the example:
+ On an Android device, you follow these steps: http://gsoc.marcospividori.com.ar/apps
+ If the registration succeded, when you go to: http://gsoc.marcospividori.com.ar/ , you will see your username. And you can start sending notifications through the website.

(from:http://www.androidhive.info/2012/10/android-push-notifications-using-google-cloud-messaging-gcm-php-and-mysql/)

General Overview of Push Notifications Services

Nowadays, every company is developing Push Notification services, and these are very similar.

When I say they are very similar, I refer to the fact that they all are asynchronous, best-effort services that offers third-party developers a channel to send data to apps from a cloud service in a power-efficient manner. The most popular are:

    - Google Cloud Messaging (Android)

    - Apple Push Notification Service (iPhone / iPad)

    - Microsoft Push Notification Service (Windows Phone)

    - BlackBerry Push Service (BlackBerry)

    - Windows Push Notification Services (Windows 8)

    - etc.

Pushing data to smartphones provides users with instant access to desired updates as they happen, such as news and weather, sports scores, stock prices and other time-sensitive content. The push services provide an efficient way to quickly push timely information updates to many smartphones at once, in a centrally managed and controlled manner.

Generally, you can also be very selective in who you send information to, including individual customers or many customers (multicast).

This services minimizes the impact on the smartphones battery life. Instead of actively checking for new data, the applications can remain closed.

This processes offer an alternative to other less efficient methods, such as polling, where a device regularly polls an application server to see if new content is available.

The main differences between the services, refer to details as: the maxim payload length, the quality of service, queueing the messages or not, and the time limit for this, the way the messages are handled in the devices, etc.

GCM:

(from:http://www.androidhive.info/2012/10/android-push-notifications-using-google-cloud-messaging-gcm-php-and-mysql/)

APNS:

(from: http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html#//apple_ref/doc/uid/TP40008194-CH100-SW9)

MPNS:

(from: http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff402558(v=vs.105).aspx)

BLACKBERRY PUSH SERVICE:

(from:https://developer.blackberry.com/devzone/develop/platform_services/push_howit.html)

General Information

Abstract

The aim of this project is to develop a server-side library in Haskell for sending push notifications to devices running different OS, such as Android, iOS, Windows Phone, BlackBerry, and so on.

The fact is that every company is developing Push Notification services, and these are very similar. Then, I want to find the fundamental concepts to construct a library which enable to configure the options for the different services and send messages easily.

When I say they are very similar, I refer to the fact that they all are asynchronous, best-effort services that offers third-party developers a channel to send data to apps from a cloud service in a power-efficient manner. The most popular are:

- Google Cloud Messaging (Android)

- Apple Push Notification Service (iPhone / iPad)

- Microsoft Push Notification Service (Windows Phone)

- BlackBerry Push Service (BlackBerry)

- Windows Push Notification Services (Windows 8)

- etc.

Once we have this libraries, I will investigate the possibility of mainting a "back and forth" communication between a server and mobile devices and I will develop a library to handle this.

Motivation and expected benefits

I think this idea would be very useful because it will allow all Haskell developers to open to a new world of mobile devices and to build useful programs/services that interact with them.

Pushing data to smartphones provides users with instant access to desired updates as they happen, such as news and weather, sports scores, stock prices and other time-sensitive content. The push services provide an efficient way to quickly push timely information updates to many smartphones at once, in a centrally managed and controlled manner.

Generally, you can also be very selective in who you send information to, including individual customers or many customers (multicast).

This services minimizes the impact on the smartphones battery life. Instead of actively checking for new data, the applications can remain closed. Once the data is delivered, the application can be launched in the background to process it as needed.

This processes offer an alternative to other less efficient methods, such as polling, where a device regularly polls an application server to see if new content is available.

The main differences between the services, refer to details as: the maxim payload length, the quality of service, queueing the messages or not, and the time limit for this, the way the messages are handled in the devices, etc.

As all the libraries to access to these services are developed in Java, Python and so on, I thought that it would be a good idea to offer an option to Haskell programmers. Taking advantage of the similarity of these services, I could develop a very adaptable library which fits the necessities for each one and at the same time offer an abstraction to the user.

Technical Considerations

In the developing of the APIs for the communication through Push Notifications, I will aim to develop a good abstraction and find the properties in common between the differents services in order to develope an customizable tool but at the same time with a common structure.

I want to let the user build messages and send these in a simple way following each protocol. Also, I will abstract the process of registering the devices in the server and let the user manage the different registrations behind a similar abstraccion.

To develop a “back and forth” comunication between a server and mobile devices, I will investigate the different possibilities of maintaining a state of the connection. It could be through the use of cookies stored by the clients or maintaining some extra information in the server which would enable it to identify the different connections and provide the appropiate services.