共用方式為

原始通知概觀

原始通知是簡短的一般用途推播通知。 這些內容是純粹的教學性質，且不包含任何UI組件。 如同其他推播通知，Windows 推播通知服務 （WNS） 功能會將原始通知從雲端服務傳遞至您的應用程式。

您可以將原始通知用於各種用途，例如在使用者授予應用程式權限後，觸發應用程式以執行背景工作。 藉由使用 WNS 與您的應用程式通訊，您可以避免建立永續性套接字連線、傳送 HTTP GET 訊息和其他服務對應用程式連線的處理額外負荷。

Important

若要瞭解原始通知，最好熟悉 Windows 推播通知服務 （WNS） 概觀中所討論的概念，。

 

如同「快顯」、「磚面」和「徽章」推送通知，原始通知會經由應用程式雲端服務透過指派的通道統一資源定位符 (URI) 推送至 WNS。 WNS 接著會將通知傳遞給與該通道相關聯的裝置和用戶帳戶。 不同於其他推播通知，原始通知沒有指定的格式。 承載的內容完全由應用程式定義。

為了說明可能受益於原始通知的應用程式，讓我們看看一個理論上的文件協作應用程式。 請考慮同時編輯相同檔的兩位使用者。 裝載共用檔的雲端服務可以使用原始通知，在其他用戶進行變更時通知每個使用者。 原始通知不一定會包含文件的變更，而是會通知每個使用者的應用程式複本聯繫中央伺服器，並同步可用的變更。 藉由使用原始通知，應用程式及其雲端服務可以節省在文件開啟時維護持續性連線的額外負荷。

原始通知的運作方式

所有原始通知都是推播通知。 因此，傳送和接收推播通知所需的設定也適用於原始通知：

  • 您必須擁有有效的 WNS 通道，才能傳送原始通知。 如需取得推播通知通道的詳細資訊，請參閱 如何要求、建立和儲存通知通道。
  • 您必須在應用程式清單檔中包含 因特網 功能。 在 Microsoft Visual Studio 指令清單編輯器中，您會在 [功能] 索引標籤底下找到此選項，因特網 （用戶端）。 如需詳細資訊，請參閱 功能。

通知的內文是以應用程式定義的格式。 用戶端會以 Null 終止的字串（HSTRING）接收數據，而此字串只需要由應用程式瞭解。

如果客戶端離線，只有當通知中包含 X-WNS-Cache-Policy 標頭時，WNS 才會快取原始通知。 不過，一旦裝置重新上線，只會快取並傳遞一個原始通知。

在用戶端，原始通知只有三種可能的處理途徑：傳遞至正在運行的應用程式，通過通知傳遞事件；發送至背景工作；或被捨棄。 因此，如果客戶端離線，且 WNS 嘗試傳遞原始通知，該通知將會被丟棄。

建立原始通知

傳送原始通知類似於傳送動態磚、訊息通知或徽章推播通知，但具有以下不同：

  • HTTP Content-Type 標頭必須設定為 “application/octet-stream”。
  • HTTP X-WNS-Type 標頭必須設定為 “wns/raw”。
  • 通知本文可以包含大小小於 5 KB 的任何字串承載，但不得為空字串。

原始通知是用來做為短訊息，以觸發您的應用程式採取動作，例如直接連絡服務以同步處理大量數據，或根據通知內容進行本機狀態修改。 請注意，無法保證傳遞 WNS 推播通知，因此您的應用程式和雲端服務必須考慮原始通知可能無法連線到用戶端的可能性，例如用戶端離線時。

如需傳送推播通知的詳細資訊，請參閱 快速入門：傳送推播通知。

接收原始通知

有兩個途徑可讓您的應用程式接收原始通知：

應用程式可以使用這兩種機制來接收原始通知。 如果應用程式同時實作由原始通知觸發的通知傳遞事件處理程式和背景工作，當應用程式執行時，通知傳遞事件會優先執行。

  • 如果應用程式正在執行，通知傳遞事件會優先於背景工作，而應用程式將有第一個處理通知的機會。
  • 通知傳遞事件處理程式可以藉由將事件的 PushNotificationReceivedEventArgs.Cancel 屬性設定為 true，指定在處理程式結束時，不將原始通知傳遞至其背景工作。 如果 Cancel 屬性設定為 false 或未設定（預設值為 false），則在通知交付事件處理程序完成後，原始通知將觸發背景任務。

通知傳遞事件

您的應用程式可以使用通知傳遞事件（PushNotificationReceived），在應用程式正在使用時接收原始通知。 當雲端服務傳送原始通知時，執行中的應用程式可以藉由處理通道 URI 上的通知傳遞事件來接收它。

如果您的應用程式沒有運行，且不使用 背景工作），則任何傳送至該應用程式的原始通知在被 WNS 收到後會被丟棄。 為了避免浪費雲端服務的資源，您應該考慮在服務上實作邏輯，以追蹤應用程式是否作用中。 這項資訊有兩個來源：應用程式可以明確地告訴服務它已準備好開始接收通知，而 WNS 可以告訴服務何時停止。

  • 應用程式會通知雲端服務：應用程式可以聯繫其服務，讓它知道應用程式正在前台運行。 這種方法的缺點是應用程式最終可能會非常頻繁地連絡您的服務。 不過，它的優點是服務一律知道應用程式何時準備好接收傳入的原始通知。 另一個優點是，當應用程式連絡其服務時，服務會知道將原始通知傳送至該應用程式的特定實例，而不是廣播。

  • 雲端服務會 回應 WNS 回應訊息：您的應用程式服務可以使用 X-WNS-NotificationStatus 和 X-WNS-DeviceConnectionStatus WNS 傳回的資訊，以判斷何時停止將原始通知傳送至應用程式。 當您的服務以 HTTP POST 的形式將通知傳送至通道時，它可以在回應中接收下列其中一則訊息：

    • X-WNS-NotificationStatus：已卸除：這表示用戶端未收到通知。 我們可以合理地假設，被丟棄 回應是因為您的應用程式不再顯示在用戶裝置的前景中所造成的。
    • X-WNS-DeviceConnectionStatus：已中斷聯機 或 X-WNS-DeviceConnectionStatus：暫時連線：這表示 Windows 用戶端已不再與 WNS 連線。 請注意，若要從 WNS 接收此訊息，您必須在通知的 HTTP POST 中設定 X-WNS-RequestForStatus 標頭來要求它。

    您的應用程式雲端服務可以使用這些狀態消息中的資訊，透過原始通知停止通訊嘗試。 當應用程式切換回前景並聯絡服務時，服務可以繼續傳送原始通知。

    請注意，您不應該依賴 X-WNS-NotificationStatus 來判斷通知是否已成功傳遞至用戶端。

    如需詳細資訊，請參閱 推播通知服務要求和響應標頭

原始通知所觸發的背景工作

Important

使用原始通知背景工作之前，應用程式必須透過 BackgroundExecutionManager.RequestAccessAsync授與背景存取權。

 

您的背景任務必須使用 PushNotificationTrigger 註冊，。 如果未註冊，工作將不會在收到原始通知時執行。

原始通知所觸發的背景工作可讓應用程式的雲端服務連絡您的應用程式，即使應用程式未執行（雖然它可能會觸發它執行）。 發生這種情況時，不需要應用程式保持連續連線。 原始通知是唯一可以觸發背景工作的通知類型。 不過，雖然快顯通知、動態磚和徽章推播通知無法觸發背景工作，但原始推播通知所觸發的背景工作可以更新動態磚，並透過本機 API 呼叫啟動快顯通知。

為了說明原始通知所觸發的背景工作如何運作，讓我們考慮一個用來讀取電子書的應用程式。 首先，使用者可能在另一部裝置上在線購買書籍。 作為回應，應用程式的雲端服務可以將包含負載的原始通知傳送給每個使用者的裝置，這個負載指出已購買書籍，且應用程式應該下載該書籍。 然後，應用程式會直接連絡應用程式的雲端服務，開始進行新書的背景下載，以便稍後當使用者啟動應用程式時，該書已就緒可供閱讀。

若要使用原始通知來觸發背景工作，您的應用程式必須：

  1. 使用 BackgroundExecutionManager.RequestAccessAsync，要求在背景中執行工作的許可權（使用者可以隨時撤銷此許可權）。
  2. 實作背景任務。 如需詳細資訊，請參閱 以背景工作支持您的應用程式

接著將在每次收到應用程式的原始通知時，透過 PushNotificationTrigger來叫用您的背景工作。 您的背景任務會解讀原始通知的應用程式專屬承載，並對其進行處理。

針對每個應用程式，一次只能執行一個背景工作。 如果有應用程式已在執行背景工作，又有新的背景工作被觸發，則必須先完成已執行的背景工作，才能執行新的任務。

Other resources

您可以下載適用於 Windows 8.1 的 原始通知範例，以及適用於 Windows 8.1 的 推播和定期通知範例，並在 Windows 10 應用程式中重複使用其原始程式碼，以深入瞭解。

 

  • Last updated on