ICEpush
  1. ICEpush
  2. PUSH-283

Cloud Notifications must carry additional parameters for BridgeIt

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: EE-3.3.0.GA_P01
    • Fix Version/s: None
    • Component/s: Push Server
    • Labels:
      None
    • Environment:
      Notification Service / BridgeIt

      Description

      When a web app generates a push request, it supplies optional information for generating a cloud notification, should that be required. Currently that includes 2 strings: subject and detail.

      BridgeIt consumes these cloud notifications, alters the user through some device-specific means, and is responsible for reactivating the application when the user acknowledges the alert. In order for BridgeIt to act as a transparent surrogate to the application it must have some other application-specific data in the notification.

      Android notifications include:
      ticker - hint that is shown when notification status added to status bar.
      icon - displayed in the status bar
      title - subject from above
      message - detail from above

      Additionally, bridgeit needs a URI to activate when the notification his handled by the user. This means that at least the following cloud notification parameters need to be added.

      hint - a short string that describes the notification
      icon - a small image to place in the status bar
      uri - the uri for bridgeit to return to.

      There may be other parameters that make sense for other platforms.

        Activity

        Hide
        Ted Goddard added a comment -

        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.

        Show
        Ted Goddard added a comment - 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.
        Hide
        Steve Maryka added a comment -

        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.

        Show
        Steve Maryka added a comment - 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.
        Hide
        Ted Goddard added a comment -

        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"

        Show
        Ted Goddard added a comment - 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"
        Hide
        Steve Maryka added a comment -

        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.

        Show
        Steve Maryka added a comment - 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.
        Hide
        Ted Goddard added a comment -

        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.

        Show
        Ted Goddard added a comment - 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.
        Hide
        Steve Maryka added a comment -

        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.

        Show
        Steve Maryka added a comment - 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.
        Hide
        Ted Goddard added a comment -

        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.

        Show
        Ted Goddard added a comment - 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.
        Show
        Ted Goddard added a comment - http://server.ice:8888/svn/repo/icepush-ee/trunk/icepush-ee/core-ee/src/main/java/com/icesoft/icepush/GcmNotificationProvider.java

          People

          • Assignee:
            Steve Maryka
            Reporter:
            Steve Maryka
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: