• 發行項

本文章是由機器翻譯。

Microsoft Azure

蔚藍通知航空樞紐港：裝置管理的最佳做法

Sara Silva

下載代碼示例

移動應用程式市場增長更快，更快，並提高任何應用程式的使用者體驗是至關重要的因為它增加了使用者的忠誠度。現代應用程式的最重要的特徵之一是他們能繼續存活，這意味著保持瞭解最新的事件發生在應用程式中，即使它未被使用的使用者。這是可能通過推式通知。

每個移動平臺都有其自身推送通知服務 （PNS） 負責推通知 — — 短消息 — — 到設備。Windows 應用程式允許應用程式接收不同的推送通知類型來代表不同的方式來顯示消息：烤麵包片，瓷磚、 原料和徽章。對於 Android 應用程式，另一方面，只是鍵/值的消息發送到設備和佈局由負責管理推式通知的類定義中的應用。在蘋果的 iOS 應用中，過程是這些方法的組合。

三七總皂苷傳遞通知，雖然每個應用程式需要一個後端 Web 或桌面應用程式定義的消息，並要連接到的推送通知提供程式發送它。

蔚藍的通知中心是微軟 Azure 服務，為從任何後端向任何移動平臺發送推式通知提供容易使用的基礎設施。其實，有兩個主要模式和管理通知集線器設備的兩種模型。在這篇文章中，我將展示如何應使用每種模式 ； 討論優點、 缺點和可能出現的情況，為每個 ； 並描述可以使用不同的模型。我會專注于發送使用通知集線器的跨平臺和自訂的推式通知的最佳做法，還顯示如何通知集線器集成到 Azure 移動服務。

推送通知生命週期

推送通知生命週期包括三個主要步驟：

  1. 應用程式發出請求的推送通知服務控制碼，可以是一個權杖、 通道的 URI 或 registrationId，具體取決於移動平臺。
  2. 應用程式發送了三七總皂苷的控制碼後端來存儲它。
  3. 後端將要求傳送到的期票，然後提供了推式通知。

從概念上說這個過程是很簡單，但在實踐中它並非那麼容易因為執行此流程所需的基礎設施是複雜的。如果為不同的用戶端平臺提供了應用程式，它為每個需要執行 （在現實中，它將代表每個平臺提供的每個介面的一個實現）。此外，每個推式通知的格式有其自身平臺的具體規格，在結束時，這些可以很難維持。這並不是所有：後端需要能夠擴展不支援廣播到多個設備 ； 一些推送通知服務 目標推送通知到不同的利益群體 ； 和監測為交付狀態推式通知。這些問題必須在後端處理，因此，這就需要一個複雜的基礎結構。

使用通知集線器

如上所述，Azure 通知集線器輕鬆將從任何後端的移動推式通知發送到任何移動的平臺，它支援不同的利益群體發送推式通知和提供監控、 遙測和調度的推式通知。在這種方式，通知集線器是協力廠商服務，可説明將跨平臺性和個人化推送通知發送到應用程式和工具的推送通知基礎結構的所有需求。

要在應用程式中集成通知中心需要配置在 Azure 門戶 ； 通知中心和三七總皂苷之間的連接應配置在各自的通知中心的配置分隔符號。沒有這些配置中，不能發送推式通知，則會發生錯誤。（如果你曾經懷疑關於哪些推送通知服務所支援的通知中心，配置分隔符號是最好的地方，檢查。若要使用通知集線器，您需要理解標籤，可以使用範本和不同的方式通知集線器。

一般情況下，一個標記代表一個興趣小組，允許您將發送推式通知到具體的目標。例如，一個體育新聞應用程式可以定義標記每項運動：騎自行車、 足球、 網球等等，使使用者可以選擇他想要接收基於自己的利益。身份驗證是必需的重點是使用者的情況，使用者 id 可以被用作標籤。在實踐中，標籤是不超過一個簡單的字串值 （如"迴圈"、"足球"或"網球"），它也是有用的定位 （為不同的語言，還有模式 （如"en_cycling"或"pt_cycling"，即標籤在英文或葡文，分別）。

範本並不是一個新的概念，但通知集線器創建一種抽象，允許您定義特定于平臺的範本或泛型範本，這意味著您可以指定每個推式通知時註冊裝置定義的鍵/值對。註冊然後將提供本機通知 （烤麵包、 有效載荷或消息），其中包含運算式 （例如，$(message)) 具有值的後端或應用程式將定義當發送推式通知。

圖 1 （用於 Windows、 iOS 和 Android） 顯示的通用範本示例使用運算式。

圖 1 通用範本

var toast = new XElement("toast", 
  new XElement("visual",
  new XElement("binding",
  new XAttribute("template", "ToastText01"),
  new XElement("text",
  new XAttribute("id", "1"),                                
  "$(message)")))).ToString(SaveOptions.DisableFormatting);
var alert = new JObject(
  new JProperty("aps", new JObject(new JProperty("alert", "$(message)"))),
  new JProperty("inAppMessage", notificationText))
  .ToString(Newtonsoft.Json.Formatting.None);
var payload = new JObject(
  new JProperty("data", new JObject(new JProperty("message", "$(message)"))))
  .ToString(Newtonsoft.Json.Formatting.None);

後端或應用程式將填充值，當它發送的鍵值 （圖 2 的過程進行了說明）：

{"message", "Message here!"}

將獨立于平臺的消息發送
圖 2 將獨立于平臺的消息發送

註冊設備

在移動開發使用通知集線器，用於管理設備和發送推式通知，可以使用兩種不同模型的兩種模式。一般情況下，模式可以描述如下：

案例 1： 設備直接連接到通知集線器

  • 用戶端應用程式直接連接到通知集線器來註冊該設備。
  • 後端或 Web 或桌面應用程式連接到通知集線器發送推式通知。
  • 三七總皂苷將提供移動推式通知。

案例 2：後端管理通知中心的設備

  • 用戶端應用程式連接到後端。
  • 後端連接與通知集線器來註冊的設備。
  • 後端定義了推式通知，將發出通知集線器。
  • 三七總皂苷將分發移動推式通知。

這兩種模式允許您使用註冊模型或安裝模型 ； 這些模型描述設備到通知集線器發送所需的資訊的方式。安裝模型介紹了最近並用於新的應用程式或者甚至用於當前應用程式的建議。這種新模式並不使註冊模式過時。下面是每個模型的一般描述：

註冊模式：在此模型中，應用程式發送註冊請求到通知集線器，提供的三七總皂苷處理常式和標記，和集線器返回註冊 id。 為每個註冊，您可以選擇本機的範本或泛型範本，將定義的消息。

安裝模式：在此模型中，應用程式將安裝要求傳送到通知集線器，提供程式所需的所有資訊：InstallationId （例如，是 GUID）、 標籤、 三七總皂苷處理常式、 範本和輔助範本 （用於 Windows 應用程式）。

雖然這兩種模型是當前可供使用，安裝模型介紹了某些技術的原因，其中包括：

  • 安裝模型是易於實施和維護。
  • 安裝模式允許部分更新修改、 添加或刪除標籤、 三七總皂苷處理常式、 範本和等等，而不發送安裝物件 ； 與此相反的是，註冊模式需要整個登錄物件。
  • 註冊模式介紹了在相同的設備後端重複註冊的可能性。
  • 註冊模式在維護登記清單中創建複雜。
  • 無論您使用哪個圖案，流將相同。

安裝模型可以用於任何.NET 或JAVA回來結束通知集線器.NET 與JAVASdk。對於用戶端應用程式，可以使用這一模型，使用 REST API，直到將支援安裝模型的新 NuGet 套裝程式被釋放。你會發現當前的 NuGet 套裝程式支援註冊模型，WindowsAzure.Messaging.Managed，可在 bit.ly/1ArIiIK。

現在，讓我們看看兩種模式。

案例 1： 設備直接連接到通知集線器

我要去討論設備直接連接到通知中心，這是由開發人員最常用的模式會發生什麼。為了描述這，我將使用註冊模式。

註冊和登出通知集線器的設備：設備請求 PNS 的控制碼從三七總皂苷，然後它將連接到通知的集線器，以註冊，使用三七總皂苷的控制碼。通知中心 PNS 連接中使用此值。

在實踐中，例如與普遍的應用，在應用程式啟動請求的通道從 Windows 推送通知服務 （wns 系列） 用下面的代碼：

// Get the channel from the application
var pushNotificationChannel =
  await PushNotificationChannelManager.
  CreatePushNotificationChannelForApplicationAsync();

安卓系統，谷歌雲消息傳遞提供 registrationId，並為 iOS，蘋果推送通知服務提供一個權杖。

應使用在 Azure 門戶和連接字串 （更具體地說，DefaultListenSharedAccessSignature 鍵） 中定義的樞紐名稱創建一個通知樞紐物件：

// Create the notification hub object
var hub = new NotificationHub(HubName, ConnectionString);

請注意，NotificationHub 類提供的 Windows­Azure.Messaging.Managed NuGet 套裝程式 （bit.ly/1ArIiIK)。

現在應用程式可以註冊通知中心：

// Register the device in Notification Hubs
var result =
  await hub.RegisterNativeAsync(pushNotificationChannel.Uri, Tags);

當你在通知中心註冊的設備時，你不必提供清單的標籤，但如果應用程式需要定義利益團體，這些標記應存儲在該設備在註冊更新中使用它們。

請注意，結果。收到的 RegistrationId 是在通知中心註冊的 id 和不應混淆與 registrationId 在 Android 應用程式 （從谷歌雲消息 id） 中使用。

發送推式通知：後端 （或應用程式） 連接到通知的集線器，以發送推式通知，可以發送到特定的標記 （或不） 使用特定或通用的範本。

在這種情況下，誰會連接到通知集線器、 後端或 Web 或桌面應用程式發送的通知並不重要。在實踐中，應創建一個 NotificationHubClient 物件，將需要定義在 Azure 門戶和連接字串 （更具體地說，DefaultFullSharedAccessSignature 鍵） 的樞紐名稱：

// Create the Notification Hub client object
var hub = NotificationHubClient.CreateClientFromConnectionString(
  HubName, ConnectionString);

接下來，本機推式通知必須定義，例如，如圖所示，在圖 3。

圖 3 定義本機推送通知

// Define template for Windows
var toast =
  new XElement("toast",
  new XElement("visual",
  new XElement("binding",
  new XAttribute("template", "ToastText01"),
  new XElement("text",
  new XAttribute("id", "1"),
  notificationText)))).ToString(SaveOptions.DisableFormatting);
// Define template for iOS
var alert = new JObject(
  new JProperty("aps", new JObject(new JProperty("alert", notificationText))),
  new JProperty("inAppMessage", notificationText))
  .ToString(Newtonsoft.Json.Formatting.None);
// Define template for Android
var payload = new JObject(
  new JProperty("data", new JObject(new JProperty("message", notificationText)))
  .ToString(Newtonsoft.Json.Formatting.None);

然後可以發送推式通知：

var googleResult =
  await hub.SendGcmNativeNotificationAsync(payload, tags);
var windowsResult =
  await hub.SendWindowsNativeNotificationAsync(toast, tags;
var appleResult =
  await hub.SendAppleNativeNotificationAsync(alert, tags);

發送移動推式通知時，可以提供標記清單中的，但這是可選的 （這取決於應用程式的要求）。

分發推式通知：要完成這一進程，三七總皂苷交付設備的通知。該服務將嘗試推送通知的時間，為每個服務各不相同的有限期間。

此方案的優點之一是它不需要一個後端，但是有是一個缺點，當使用者使用多個設備：標記不在設備之間共用，使用者需要重新定義為每個標籤。移動應用程式取決於該通知中心，和它需要每一次更新中的應用，可以是一個問題，如果使用者不更新到最新版本 (移動應用程式的共同問題） 的標記。

對於這種情況的可能方案可以包括：

  • 移動應用程式並不需要一個後的端，如通過這種能力與桌面應用程式或後端辦公室 （管理 Web 網站） 何時發送推式通知。例如，請考慮基於飼料有一個設置頁面，在那裡使用者可以訂閱他們的利益，例如開發人員的事件，IT Pro 事件等等的線上技術事件消息的應用程式。一旦選擇了利益，則使用者將收到這些利益的推式通知。而不是要求一個後端觸發推式通知，一個桌面應用程式或後端辦公室可以跟直接通知樞紐每當創建新的事件來觸發推式通知已經訂閱了特別感興趣的所有設備。
  • 移動應用程式使用一個後端，但推式通知，由於某些原因，未集成的服務，由一個桌面應用程式或後端辦公室發送。一個例子可能是一個用戶端，有一種服務，提供的資訊來顯示在應用程式中，但不允許到服務 （這可以使用不同的應用程式） 的更改。但是，為了支援推送通知，用戶端可以發送通知使用的後臺辦公室或甚至一個桌面應用程式。

案例 2： 後端管理通知中心的設備

為了描述這一模式，將先使用基於安裝的新方法­公式模型，介紹了最近由通知中心隊。

應用程式連接到後端：在這種情況下，應用程式連接到後端來創建或更新安裝物件，它將存儲在本地。

該設備從 PNS 請求 PNS 控制碼並從通知集線器上，存儲在設備上獲取上一次安裝。然後，將設備連接到後端，若要創建或更新安裝，從中通知集線器的設備。（將創建一個新的安裝物件第一次，但它應該重用每次的後端連接具有相同的設備的通知中心）。

例如，在普遍應用中，應用程式將開始通過從 wns 系列，用以下內容請求該通道的 URI：

// Get the channel from the application
var pushNotificationChannel =
  await PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync();

到後端，若要創建或更新安裝請求之前，必須定義安裝物件：

// Retrieve installation from local storage and
// create new one if it does not exist
var installation = SettingsHelper.Installation;
if (installation == null)
{
  installation = new Installation
  {
    InstallationId = Guid.NewGuid().ToString(),
    Platform = NotificationPlatform.Wns,
    PushChannel = pushNotificationChannel.ToString(),
    Tags = new List<string> {“news", "sports"}
  };
}

從 JSON 文檔中提供創建用戶端應用程式中使用的安裝類。

在這一點上，您可以請求處登記，而這樣的代碼：

// Create a client to send the HTTP registration request
var client = new HttpClient();
var request = new HttpRequestMessage(HttpMethod.Post, new Uri(_registerUri))
{
  Content = new StringContent(JsonConvert.SerializeObject(installation),
    Encoding.UTF8, "application/json")
};
var response = await client.SendAsync(request);

後端創建或更新安裝過程中通知集線器的設備：當後端收到請求註冊使用安裝模型的設備時，它用通知的集線器，以創建或更新安裝連接。例如，在ASP.NETWeb API，你可以創建 NotificationHubController 來定義服務來管理通知集線器的設備。執行需要一個通知中心用戶端物件，可以定義在建構函式中，如下：

public class NotificationHubController : ApiController
{
  private readonly NotificationHubClient _notificationHubClient;
  private const string HubName = "<define the notification hub name>";
  private const string ConnectionString = "<define the connection string>"
  public NotificationHubController()
  {
    _notificationHubClient =
      NotificationHubClient.CreateClientFromConnectionString(
      ConnectionString, HubName);
  }

現在您可以編寫方法，將創建或更新安裝，將作為輸入接收安裝物件，如下所示：

[HttpPost]
[Route("api/NH/CreateOrUpdate")]
public async Task CreateOrUpdateAsync(Installation installation)
{
  // Before creating or updating the installation is possible, 
  // you must change the tags to have secure tags
  await _notificationHubClient.
    CreateOrUpdateInstallationAsync(installation);
}

請注意標籤可以定義並存儲在後端 （在這兩種模型）。移動應用程式不需要將它們存儲或甚至瞭解他們。例如，考慮一個銀行應用程式定義標記為每個帳戶的用戶端。當操作完成開戶後時，到該帳戶的設備發送推式通知。在這種情況下，這些標記必須是安全，只有後端就會知道他們。

在安裝模式下，安裝將存儲在該通知中心，意味著它可以檢索基於 InstallationId。

後端定義了推式通知，將發送通知中心：後端負責將推式通知發送到通知集線器，並可以提供標籤，並定義範本為每個平臺 （當一個通用的範本並不定義）。

1，在那裡後, 端或應用程式連接到通知的集線器，以發送推式通知，所以我不會提供任何額外的代碼，這種情況下的情況下，執行是的情況相似。

順便說一句，在安裝模式下，有可能將推式通知發送到一個特定的安裝。這是只為註冊安裝模型的基礎的新功能。下面是代碼做到這一點：

_notificationHubClient.SendWindowsNativeNotificationAsync(
  payload, "$InstallationId:{" + installationId + "}");

推送通知服務將分發推式通知：要完成這一進程，三七總皂苷將交付推式通知設備，在有限的期間。

這種情況下的優勢之一是標記可以是靜態還是動態的這意味著他們可以隨時更改，不改變或影響移動的應用程式 ； 標籤是安全的因為每個使用者只可以註冊為一個標籤，如果他通過身份驗證 ； 標籤可以分擔不同的設備，為同一使用者 ； 移動應用程式是完全獨立的通知中心。這種情況下的缺點是過程實際上也是比第一次的情況下，複雜得多，如果使用註冊模式。

這包括可能的方案：

  • 一個移動的應用程式連接到後端和標記必須是安全的。這種情況下很好的例子是一個應用程式有關的銀行帳戶，支援推送通知來保持使用者及時瞭解他們的帳戶中的交易記錄。
  • 一個移動的應用程式連接到後端和標記必須是動態的。考慮一個應用程式提供了不同的音樂事件，使用標記來定義不同的事件的資訊，使用者可以為每個事件訂閱要更新的所有相關資訊。每個標記的生命週期短，每次創建新的事件，也為該事件創建一個新標記。標籤，因此，是動態的可以由後端，保持獨立的移動應用程式的過程。

在這兩種情況下，標籤應存儲在後端，但這並不意味著移動用戶端不知道他們。

更新登記

與註冊模型，您想要更新任何有關的登記，每的次如標記正在使用，您必須恢復註冊 ； 這被必需完成更新。但在安裝模式中，您可以更新只是具體的細節。這意味著，如果應用程式需要更新一個標籤、 範本或其他詳細資訊，它是可能做了部分更新。這裡是更新標記的代碼：

// Define the partial update
PartialUpdateOperation replaceTagsOperation =
  new PartialUpdateOperation();
replaceTagsOperation.Operation = UpdateOperationType.Replace;
replaceTagsOperation.Path = "/tags/tennis";
replaceTagsOperation.Value = "cycling";
partialUpdates.Add(replaceTagsOperation);
// Send the partial update
_notificationHubClient.PatchInstallation(
  installationId, partialUpdates);

在蔚藍的移動服務中使用通知集線器

蔚藍的移動服務允許您與可擴充性和安全性的後端 （使用 Microsoft.NET 框架或 Node.js） 主持在 Azure 中開發應用程式。重點放在移動應用程式，Azure 移動服務提供了一個移動應用程式的需要，例如 CRUD 操作、 社會網路的身份驗證、 離線支援，推式通知和主要功能。

推式通知 Azure 移動服務中提供的通知中心，同時創建了 Azure 手機資訊服務，每次通知集線器是創建並與 Azure 移動服務相關聯。

使用 Azure 移動服務的移動應用程式可以快速簡便的方式，實現推式通知，因為 Azure 移動服務 SDK 提供了 Api，可用於：

  • 用戶端應用程式註冊使用的後端設備。
  • 一個後端來管理設備的通知中心 ； 若要修改來自設備的請求，這意味著後端可以添加、 修改或刪除標籤從移動應用程式，所提出的要求或甚至取消了註冊 ； 發送推式通知 （使用特定範本，而且如果需要標籤，則為他們）。

在.NET 後端執行將類似于：

await Services.Push.SendAsync(
  GetWindowsPushMessageForToastText01(
  "My push notification message", tags));

推式通知基於一條消息，並可以實現中所示，GetWindowsPushMessageForToastText01 方法定義的範本圖 4。

圖 4 定義基於範本的 ToastText01 WindowsPushMessage

public static IPushMessage GetWindowsPushMessageForToastText01(string message)
{
  var payload = new XElement("toast",
    new XElement("visual",
    new XElement("binding",
    new XAttribute("template", "ToastText01"),
    new XElement("text",
    new XAttribute("id", "1"), message))))
    .ToString(SaveOptions.DisableFormatting);
    return new WindowsPushMessage
    {
      XmlPayload = payload
    };
}

在用戶端應用，例如在通用的應用程式，您必須從 wns 系列請求通道：

// Get the channel
var channel =
  await PushNotificationChannelManager.
  CreatePushNotificationChannelForApplicationAsync();

然後應該創建移動服務用戶端，並且它將允許與後端交互：

// Create the MobileServiceClient using the
// AzureEndpoint and admin key
var mobileServiceClient =
  new Microsoft.WindowsAzure.MobileServices.MobileServiceClient(
  AzureEndPoint, AzureMobileServiceApplicationKey);

AzureEndPoint 應該是像 HTTPs://mymobileservice.azure-mobile.net/ 和 AzureMobileService­ApplicationKey 是一個字串，它表示在 Azure 門戶中定義的應用程式鍵。

你可以使用 RegisterNativeAsync 方法註冊的設備，如下：

// Register the device
await MobileServiceClient.Client.GetPush().RegisterNativeAsync(
  channel.Uri, tags);

但是，如果你要註冊的設備使用一個通用的範本，使用 RegisterTemplateAsync 方法。

在 Azure 移動服務 （.NET 後端），擴展、 修改或取消註冊 Azure 通知中心，應實現 INotificationHandler 介面。通過這樣做，你可以舉個例子，有安全標籤。

總結

通知中心提供了一個抽象向任何移動的平臺，從任何後端發送推式通知和新的模式使您可以定義一個獨特的安裝包含通知中心所需的基本資訊。安裝可以重用，避免重複登記和複雜性，為新的應用程式或甚至在當前應用程式，建議安裝模型。有兩個主要模式註冊到通知的集線器，應根據應用程式的要求來選擇設備。

這種模式允許您發送消息側重于某些特殊利益群體使用標記，和它也是可能的定義通用或特定的範本，規模和監視應用程式的需要服務。最後，很容易使用 Sdk 在幾種語言提供移動應用程式和後端。

通知中心集成在預設情況下，這是對開發人員來說有利，因為它支援推送通知功能實現快速和容易的方式。

Sara Silva 是一種數學專業畢業生和 Microsoft MVP。如今，她工作作為移動名在葡萄牙，主要重點放在 Windows 應用程式，Xamarin 和微軟 Azure 的開發人員。她的博客 saramgsilva.com 和後面可以在 Twitter 上 twitter.com/saramgsilva。

感謝以下的微軟技術專家對本文的審閱：Piyush Joshi、 聖保羅莫爾加多和Chris雷斯納