共用方式為

原始通知概觀

  • 發行項

原始通知是簡短、一般用途的推播通知。 它們只是指示，不會包含 UI 元件。 如同其他推播知一樣，Windows 推播通知服務 (WNS) 功能會從您的雲端服務將原始通知傳遞至您的應用程式。

您可以將原始通知應用到各種不同用途，包括觸發應用程式以執行背景工作 (如果使用者已授與應用程式執行此動作的權限)。 使用 WNS 與您的應用程式進行通訊，就可以避免因建立持續的通訊端連線、傳送 HTTP GET 訊息，以及其他服務對應用程式連線，而造成處理的額外負荷。

重要

若要了解原始通知，最好的方式是熟悉 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 回應訊息：您的應用程式服務可以使用 WNS 傳回的 X-WNS-NotificationStatus 和 X-WNS-DeviceConnectionStatus 資訊，來判斷何時停止將原始通知傳送至應用程式。 當您的服務以 HTTP POST 的形式將通知傳送至通道時，它可以在回應中接收下列其中一則訊息：

    • X-WNS-NotificationStatus: dropped：這表示用戶端未收到通知。 您可以放心假設，已捨棄回應是因為您的應用程式不再於使用者裝置的前景中所造成。
    • X-WNS-DeviceConnectionStatus: disconnected或 X-WNS-DeviceConnectionStatus: tempconnected：這表示 Windows 用戶端不再與 WNS 連線。 請注意，若要接收 WNS 發出的此訊息，您必須在通知的 HTTP POST 中設定 X-WNS-RequestForStatus 標頭來提出要求。

    您的應用程式雲端服務可以使用這些狀態訊息中的資訊，以透過原始通知停止通訊嘗試。 當應用程式切換回前景時，一旦應用程式恢復與服務連線，服務就可以繼續傳送原始通知。

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

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

原始通知觸發的背景工作

重要

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

 

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

原始通知觸發的背景工作可讓應用程式的雲端服務連絡您的應用程式，即使應用程式未執行也一樣 (雖然可能會觸發它執行)。 應用程式不必保持連線，也會發生此情況。 原始通知是唯一可以觸發背景工作的通知類型。 不過，雖然快顯、磚和徽章推播通知無法觸發背景工作，但原始通知觸發的背景工作可以更新磚，並透過本機 API 呼叫叫用快顯通知。

讓我們用閱讀電子書的應用程式來說明原始通知觸發的背景工作如何運作。 首先，使用者會在線上購買一本書，可能是在另一部裝置上。 應用程式的雲端服務可以將原始通知傳送至使用者的每一部裝置作為回應，且當中包含承載，指出已購買書籍，且應用程式應下載它。 然後應用程式會直接連絡應用程式的雲端服務，以開始在背景下載新書，如此一來，當使用者之後啟動應用程式時，該書籍就已存在並且可供閱讀。

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

  1. 使用 BackgroundExecutionManager.RequestAccessAsync 要求在背景執行工作的權限 (使用者可隨時將此權限撤銷)。
  2. 實作背景工作。 如需詳細資訊，請參閱使用背景工作支援應用程式

接著每次收到應用程式的原始通知時，都會叫用您的背景工作以回應 PushNotificationTrigger。 您的背景工作會解譯原始通知的應用程式特定承載，並加以處理。

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

其他資源

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