共用方式為


如何要求、建立及儲存通知通道

您可以開啟通道統一資源標識碼(URI),讓應用程式可以接收推播通知。 接著,您可以將通道傳送至伺服器,以用來傳送推播通知,並在不再需要時將其關閉。 通道是代表單一裝置上單一使用者的特定應用程式或次要磁貼的唯一位址。

每次啟動應用程式時,您應該要求新的通道,並在 URI 變更時更新雲端伺服器。 如需詳細資訊,請參閱備註。

這很重要

通知通道會在 30 天后自動到期。

您需要知道的事項

技術

  • Windows 執行環境

先決條件

操作說明

步驟 1:新增命名空間宣告

Windows.UI.Notifications 包含快顯通知 API。

using Windows.UI.Notifications;
using Windows.Data.Xml.Dom;
using Windows.Networking.PushNotifications;

步驟 2:請求通道 URI

此範例會要求通道 URI。 要求會向通知用戶端平臺提出,而通知用戶端平台接著會向WNS要求通道 URI。 要求完成時,傳回的值是包含 URI 的 PushNotificationChannel 物件。

PushNotificationChannel channel = null;

try
{
    channel = await PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync();
}

catch (Exception ex)
{ 
    // Could not create a channel. 
}

步驟 3:將通道 URI 傳送至您的伺服器

通道 URI 會封裝在 HTTP POST 要求中,並傳送至伺服器。

這很重要

您應該以安全的方式將此資訊傳送至您的伺服器。 當應用程式傳輸通道 URI 時,您應該要求應用程式向伺服器進行自我驗證。 加密資訊並使用安全通訊協定,例如 HTTPS。

String serverUrl = "http://www.contoso.com";

// Create the web request.
HttpWebRequest webRequest = (HttpWebRequest)HttpWebRequest.Create(serverUrl);
webRequest.Method = "POST";
webRequest.ContentType = "application/x-www-form-urlencoded";
byte[] channelUriInBytes = System.Text.Encoding.UTF8.GetBytes("ChannelUri=" + channel.Uri);

// Write the channel URI to the request stream.
Stream requestStream = await webRequest.GetRequestStreamAsync();
requestStream.Write(channelUriInBytes, 0, channelUriInBytes.Length);

try
{
    // Get the response from the server.
    WebResponse response = await webRequest.GetResponseAsync();
    StreamReader requestReader = new StreamReader(response.GetResponseStream());
    String webResponse = requestReader.ReadToEnd();
}

catch (Exception ex)
{
    // Could not send channel URI to server.
}

備註

請求頻道

每次叫用應用程式時,您應該使用下列邏輯來要求新的通道:

  1. 請求頻道。
  2. 比較新通道與上一個通道。 如果通道相同,您就不需要採取任何進一步的動作。 請注意,為了能在稍後進行比較,您的應用程式在每次成功將通道傳送至服務時,必須將該通道本地儲存。
  3. 如果通道已變更,請將新的通道傳送至您的 Web 服務。 在下列情況下,包含一律傳送新通道的錯誤處理邏輯:
    • 您的應用程式以前從未將通道傳送至 Web 服務。
    • 應用程式上次嘗試將通道傳送至 Web 服務未成功。

CreatePushNotificationChannelForApplicationAsync 方法的不同呼叫不一定能夠傳回不同的通道。 如果通道自上次呼叫后尚未變更,您的應用程式應該不會將相同的通道重新傳送至您的服務,以節省工作和因特網流量。 應用程式可以同時有多個有效的通道 URI。 由於每個唯一通道在到期前都會維持有效狀態,因此要求新通道並無任何損害,因為它不會影響任何先前通道的到期時間。

每次啟動您的應用程式時,請求一個新的通道,以最大化總是能夠存取有效通道的機會。 如果確保您的磁磚或通知情境中的內容始終為即時是至關重要的,那麼這一點特別重要。 如果您擔心使用者可能不會在每 30 天內執行您的應用程式超過一次,您可以實作背景工作來定期執行請求通道的程式碼。

處理通道要求中的錯誤

如果因特網無法使用, CreatePushNotificationChannelForApplicationAsync 方法的呼叫可能會失敗。 若要處理這個問題,請將重試邏輯新增至步驟 2 中顯示的程式代碼。 我們建議三次嘗試之間間隔 10 秒。 如果這三次嘗試都失敗,您的應用程式應該等到下一次用戶啟動時再試一次。

關閉通道

您的應用程式可以呼叫 PushNotificationChannel.Close 方法,立即停止在所有通道上傳遞通知。 雖然您的應用程式不常會這樣做,但在某些情況下,您可能會想要停止所有通知傳遞至您的應用程式。 例如,如果您的應用程式具有用戶帳戶的概念,且使用者註銷該應用程式,則合理預期磚不再顯示該用戶的個人資訊。 若要成功清除內容的磚並停止傳遞通知,您應該執行下列動作:

  1. 在傳送磚、快顯通知、徽章或原始通知的任何通知通道上呼叫 PushNotificationChannel.Close 方法,以停止所有磚更新。 呼叫 Close 方法可確保無法將該用戶的進一步通知傳遞給用戶端。
  2. 呼叫 TileUpdater.Clear 方法來清除磚的內容,以從磚中移除先前用戶的數據。