1.If the user's mobile device is connected via Openwave Mobile Access Gateway (MAG), capture the user's subscriber ID and PPG address from the corresponding HTTP request headers. Save the subscriber ID and PPG addresses in your user database for subsequent push requests.
If the user's phone is connected to the Open Mobile AccessS Gateway connection, you can obtain the user's user ID and PPG address from the appropriate HTTP request header. We can save this information in the database for a PUSH request.
2.
Only Push Content to Users Who Are Expecting to Receive It. 3.
Refer to service indeformations as "alerts" in Your User Interface and User Documentation.
Personalize your pushed content for the user. Make sure the URL for each push submission links to a document containing personalized content. For example, an email application should link each "new email" alert to the user's personal email inbox. 4.
Allow users to set push preferences. When it makes sense, allow users to specify their personal preferences for receiving pushed content. For example, a news service might allow users to request periodic alerts on an hourly, daily, or weekly basis, or to temporarily Disable All Alerts Until The User Explicitly Re-Enables The Feature. 5.
Preface alert title strings with the name of your application. Most devices use a single inbox to present alerts pushed from all applications. In order for users to distinguish your alerts, include the name of you application at the front of the alert title. For example :
Mobile Email: 6 New Messages ABC Travel: Your flight is delayed Instant Message:. Karen says "! Hi" 6 Keep alert title strings short Most devices only display one line for each alert title string and truncate the string if it is longer than one line. Keeping the alert title short allows it to be fully visible without forcing the user to move the cursor and wait for the line to scroll.7 Ensure all alerts remain active for at least 24 hours. Allow the user to have adequate time to view each alert. Most network operators will configure the default expiration for at least 24 hours, so if you do not specify the expiration for a service indication, you should not have to worry.8 Link all alerts to the same URL, for any given user. In response to the URL, display the current alert status or a history of unacknowledged alert details. Most devices limit the maximum number of alerts that can be displayed and / or stored. Users who receive a high volume of alerts may not get The Chance to View and SEL ect each alert before it is deleted or overwritten by the device. To ensure the user does not miss any critical alert details, link each service indication to the same URL on the application server. The URL should return a page that describes the user's current alert status or a history list of unacknowledged alert details. for example, an email application should link each email alert to the user's email inbox. The email inbox allows the user to view all recently received email messages, even if the user missed the alert for A Specific email message.
Openwave Mobile Browser Alert UI ModelThis section describes the Openwave Mobile Browser alert UI model in detail, so developers can provide the best user experience when pushing service indications to devices running Openwave Mobile Browser. When Openwave Mobile Browser receives a service indication, it presents it to The user as an alert. Mobile Browser Will Invoke Any of The Following Alert Indicators, Depending on The Priority Specified:
