One fundamental problem with including the URL in the push request is the fact that a push group can function for multiple different pages in the application. In this case, the application would indicate that the "current" URL should be loaded, however this may be difficult to determine client or server-side. One possibility is to use a cooperative history mechanism where a page containing BridgeIt (or ICEpush) will store the location (local storage) of the most recent page active in that application and corresponding to the push event.

Could this not be more under application control? When I push in an application-specific context, would the developer not know where a cloud notification is destine for? In most cases it is probably back to the URL where it originates from, but could easily be some other page related to that specific notification. In this way it acts as a specific means of navigation within the application.

APNS places limitations on notification payloads: "The maximum size allowed for a notification payload is 256 bytes; Apple Push Notification Service refuses any notification that exceeds this limit"

256 bytes is certainly limiting if we are looking to pass URLs and icons around. One possible solution would be for bridgeit native code to fetch a payload as a result of the notification.

We probably need to treat cloud notification in BridgeIt differently than we did in the container world. BridgeIt's role in the case of a cloud notification is to alert the user and reactivate the application in the appropriate context.

The original design intent was to have transparency between Ajax Push and Cloud Push, and having navigation occur only in the case of Cloud Push is at odds with this.

On the other hand, purely as a mobile messaging feature, it is legitimate to send the user a notification that directs them to a web page. A new ICEpush "message" API could be defined for this (it is more similar to an email or an SMS than an ajax notification). When used with ICEfaces, a component could serve to display the message in the browser.

If we can not rely on the payload of the cloud notification, then we need to use the client-side registration mechanism to provide the necessary information to reactivate the application.

The PushConfiguration attributes now optionally contains a "url" attribute specifying the URL that the client should redirect to. Support for this should be added to the GCM connector and the android client.

http://server.ice:8888/svn/repo/icepush-ee/trunk/icepush-ee/core-ee/src/main/java/com/icesoft/icepush/GcmNotificationProvider.java