I've committed the changes for the AmazonSNSNotificationProvider class (including libraries and build changes) and documented it here:

http://wiki.icesoft.com/display/notify/Amazon+SNS

Not moving on to looking at a pure SMS Gateway provider (likely Twilio).

Steve mentioned that the SMS message should be able to launch the browser, such as by containing a URL. Launching the browser is implicit with the other notification types, so it is possible that this URL should be included in the SMS message by default.

Are you saying we have a single "static" URL that should be included in all SMS message by default? Or that cloud notification messages will contain a URL? Trying to determine where the work should be done:

• During construction of the actual message? This is generally outside the responsibility of the NotificationProvider as it is just passing on the message it received.
• Appended to the message by the NotificationProvider. This would imply that the URL is either known or can be retrieved/assembled somehow.

The URL in the SMS message will need to launch the on-device browser to the page appropriate for the notification. We will need to look at the mechanism to capture this state. Options:

• provide URL during push request (does not entirely make sense since a given push request does not necessarily apply to a particular page)
• captured during listen.icepush (store the referrer for the listen.icepush or provide a parameter for this)

If the URL is included in the SMS it must be short, so in keeping with NAAS (Notification as a service) we may need our own URL shortening service).

I've checked in the Twilio provider code and libraries as well as updated the two Wiki pages with information:

http://wiki.icesoft.com/display/ICEmobileEE/Cloud+Push+web.xml+Configuration
http://wiki.icesoft.com/display/notify/Twilio+SMS

As a short-term "primitive" feature, Twilio will look for a context parameter that can be set as a return link. This link will be included in the message so that clicking on it can return you to some part of the application. This is obviously not the final way we want to do it but it makes it easy to play around with.

So we've gone with a REST-style approach to using Twilio rather than use the client. I've also copied over our existing Base64 utility for doing the encoding. This eliminates the 3rd party libraries we need to depend on/include as well as making it JDK 1.5 compatible so that the builds won't complain.

I've checked in the chat-sms sample application. I also created a separate JIRA (PUSH-233) for the server-side API we would like to replace the logic we have in there now.

Resolving as completed. May still need verification as per PUSH-233.