INTEXT-19: Push Notification adapters for Android devices

[amolnayak311]

The PR is for adding the initial support for sending push notifications to mobile and hand held devices. This is the first of the many services to be supported from Spring Integration for pushing to mobile devices from java applications.

The umbrella JIRA for this is https://jira.springsource.org/browse/INTEXT-18

and the specific JIRA to support push to Android devices is https://jira.springsource.org/browse/INTEXT-19

[ghillert]

Shouldn't we use Android API to do server push, rather than implementing our own infrastructure? (using gcm-server.jar)

com.google.android.gcm.server.Sender sender = new Sender(senderId);
List<String>registrationIds = new ArrayList<String>();
ids.add("12345");

Message msg = new Message.Builder()
.collapseKey("1")
.timeToLive(3)
.delayWhileIdle(true)
.addData("message","This is a notification 423424234")
.build();

sender.send(msg, ids, 1);

Shouldn't we have an inbound adapters to handle client "subscriptions"?

[amolnayak311]

The Idea is to have a common abstract service implementing the functionality like exponential retry for all implementations and delegate to the underlying service to do the actual push. Ideally we shall be having the common abstract class for all our implementations. The push part for android we have implemented is as per the specification given for GCM and there isn't much code in it. Implementing them using GCM Server should be fine as well I guess ( I had seen this when I had developed the service but intentionally decided not to use it for some reason, I am afraid I quite don't remember why I decided that :D )

For the client subscription, it is the responsibility of the handheld device to provide the application server with the registration id it received from GCM services. Now this can be send using plain TCP/IP , HTTP, use a web service etc, depending on what is the protocol between the application and its server side. To achieve either of these we can use the TCP , HTTP or WS inbound adapters and then use the JDBC or JPA adapters to store the registration id in database. That's why I think any inbound adapters for them won't make much sense and doesn't add much value. You have any other view or idea in mind?

[amolnayak311]

Got rid of the interface and moved the constants to the implementation class. Rebased and pushed the changes

[cdelgadob]

What's the status of this development? It seems to me a very useful functionality, but it's been a while since the last update in JIRA

[amolnayak311]

Hello cdelgadob, its being reviewed and should merged soon. Meanwhile if possible, we would live to have your view on it too. :)

[cdelgadob]

Hi Amol, thanks for your answer, that's good news. I'm happy to help and review it, just tell me where to get it from and I'll come back to you.