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.
如果用戶的手機通過open Mobile Accesss Gateway連接，可以從合適的http請求頭(request header)裏取得用戶的用戶id 和ppg地址，我們可以把這些信息保存於數據庫以便以後的進行push請求。
2. Only push content to users who are expecting to receive it.
3. Refer to service indications as "alerts" in your user interface and user documentation.
3. 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:
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 don't specify the expiration for a service indication, you shouldn't 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 select each alert before it is deleted or overwritten by the device. To ensure the user doesn't 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 Model
This 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:
Users can navigate to the Inbox page at any time to view the alerts they have received most recently. When the user chooses the alert in the Inbox, the browser loads the URL associated with the service indication.
The Inbox page may contain up to nine individual alert entries. When a new service indication arrives with the same ID as an existing alert entry (matching URL or si-id), the new alert will overwrite the previous alert entry. If the Inbox is full and a new service indication arrives with a unique ID (doesn't match any existing alert entries), the new alert will overwrite the alert occupying the ninth entry.
如果用戶的手機通過open Mobile Accesss Gateway連接，可以從合適的http請求頭(request header)裏取得用戶的用戶id 和ppg地址，我們可以把這些信息保存於數據庫以便以後的進行push請求。
2. Only push content to users who are expecting to receive it.
3. Refer to service indications as "alerts" in your user interface and user documentation.
3. 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 don't specify the expiration for a service indication, you shouldn't 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 select each alert before it is deleted or overwritten by the device. To ensure the user doesn't 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 Model
This 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:
- Beep, buzz, or flash a light, indicating that an alert has arrived (not all indicators are available on all devices).
- Display a popup message, which informs users that an alert has arrived and allows them to view it or skip it. The popup message is usually of the form: "Alert from <alert title string>. View it now?".
- Display an alert icon.
Users can navigate to the Inbox page at any time to view the alerts they have received most recently. When the user chooses the alert in the Inbox, the browser loads the URL associated with the service indication.
The Inbox page may contain up to nine individual alert entries. When a new service indication arrives with the same ID as an existing alert entry (matching URL or si-id), the new alert will overwrite the previous alert entry. If the Inbox is full and a new service indication arrives with a unique ID (doesn't match any existing alert entries), the new alert will overwrite the alert occupying the ninth entry.
