Szablony usługi Notification Hubs

Szablony umożliwiają aplikacji klienckiej określenie dokładnego formatu powiadomień, które mają być odbierane. Korzystając z szablonów, aplikacja może zrealizować kilka różnych korzyści, w tym następujące:

• Niezależne od platformy zaplecze
• Spersonalizowane powiadomienia
• Niezależność wersji klienta
• Łatwa lokalizacja

Ta sekcja zawiera dwa szczegółowe przykłady używania szablonów do wysyłania powiadomień niezależnych od platformy przeznaczonych dla wszystkich urządzeń na różnych platformach oraz personalizowania powiadomień rozgłaszanych na poszczególnych urządzeniach.

Korzystanie z szablonów międzyplatformowych

Standardowym sposobem wysyłania powiadomień push jest wysyłanie, dla każdego powiadomienia, które ma być dostarczone, określonego ładunku danych do usług powiadomień platformy (WNS, APNS). Na przykład, aby wysłać alert do usługi APNS, ładunek ma formę obiektu JSON następującej postaci:

{"aps": {"alert" : "Hello!" }}

Aby wysłać podobny komunikat wyskakujący w aplikacji Sklepu Windows, ładunek XML wygląda następująco:

<toast>
  <visual>
    <binding template=\"ToastText01\">
      <text id=\"1\">Hello!</text>
    </binding>
  </visual>
</toast>

Podobne ładunki można tworzyć dla platform MPNS (Windows Phone) i FCM (Android).

To wymaganie wymusza, aby zaplecze aplikacji tworzyło różne ładunki dla każdej platformy i skutecznie sprawia, że zaplecze jest odpowiedzialne za część warstwy prezentacji aplikacji. Niektóre problemy obejmują lokalizację i układy graficzne (zwłaszcza w przypadku aplikacji ze Sklepu Windows, które obejmują powiadomienia dla różnych typów kafelków).

Funkcja szablonu usługi Notification Hubs umożliwia aplikacji klienckiej tworzenie specjalnych rejestracji, nazywanych rejestracjami szablonowymi, które obejmują szablon oprócz zestawu tagów. Funkcja szablonu usługi Notification Hubs umożliwia aplikacji klienckiej kojarzenie urządzeń z szablonami niezależnie od tego, czy pracujesz z instalacjami (preferowanymi) czy rejestracjami. Biorąc pod uwagę powyższe przykłady ładunku, jedynymi niezależnymi od platformy informacjami jest rzeczywisty komunikat alertu (Hello!). Szablon to zestaw instrukcji dla centrum powiadomień na temat formatowania niezależnego od platformy komunikatu na potrzeby rejestracji tej konkretnej aplikacji klienckiej. W poprzednim przykładzie komunikat niezależny od platformy jest pojedynczą właściwością: message = Hello!.

Na poniższej ilustracji przedstawiono proces:

Szablon rejestracji aplikacji klienckiej systemu iOS jest następujący:

{"aps": {"alert": "$(message)"}}

Odpowiedni szablon dla aplikacji klienckiej ze sklepu Windows to:

<toast>
    <visual>
        <binding template=\"ToastText01\">
            <text id=\"1\">$(message)</text>
        </binding>
    </visual>
</toast>

Zwróć uwagę, że rzeczywisty komunikat jest zastępowany wyrażeniem $(message). To wyrażenie instruuje centrum powiadomień za każdym razem, gdy wysyła komunikat do tej konkretnej rejestracji, aby utworzyć komunikat, który następuje po nim i wstawia wspólną wartość.

Jeśli pracujesz z modelem instalacji, klucz instalacji "templates" przechowuje kod JSON wielu szablonów. Jeśli pracujesz z modelem rejestracji, aplikacja kliencka może utworzyć wiele rejestracji w celu użycia wielu szablonów; na przykład szablon komunikatów alertów i szablon aktualizacji kafelków. Aplikacje klienckie mogą również łączyć rejestracje natywne (rejestracje bez szablonu) i rejestracje szablonów.

Centrum powiadomień wysyła jedno powiadomienie dla każdego szablonu bez rozważenia, czy należą one do tej samej aplikacji klienckiej. To zachowanie może służyć do tłumaczenia powiadomień niezależnych od platformy na więcej powiadomień. Na przykład ten sam komunikat niezależny od platformy do centrum powiadomień można bezproblemowo przetłumaczyć w wyskakujących alertach i aktualizacji kafelka bez konieczności informowania o tym zaplecza. Niektóre platformy (na przykład system iOS) mogą zgrupować wiele powiadomień na tym samym urządzeniu mobilnym, jeśli zostaną wysłane w krótkim czasie.

Używanie szablonów do personalizacji

Kolejną zaletą korzystania z szablonów jest możliwość używania usługi Notification Hubs do przeprowadzania personalizacji powiadomień na rejestrację. Rozważmy na przykład aplikację pogodową, która wyświetla kafelek z warunkami pogodowymi w określonej lokalizacji. Użytkownik może wybrać stopnie Celsjusza lub Fahrenheita oraz pojedynczą lub pięciodniową prognozę. Przy użyciu szablonów każda zainstalowana aplikacja kliencka może zarejestrować się w wymaganym formacie (1-dniowym w stopniach Celsjusza, 1-dniowym w stopniach Fahrenheita, 5-dniowym w stopniach Celsjusza, 5-dniowym w stopniach Fahrenheita), a backend może wysłać pojedynczy komunikat zawierający wszystkie informacje wymagane do wypełnienia tych szablonów (na przykład pięciodniową prognozę w stopniach Celsjusza i Fahrenheita).

Szablon prognozy jednorazowej z temperaturami Celsjusza jest następujący:

<tile>
  <visual>
    <binding template="TileWideSmallImageAndText04">
      <image id="1" src="$(day1_image)" alt="alt text"/>
      <text id="1">Seattle, WA</text>
      <text id="2">$(day1_tempC)</text>
    </binding>  
  </visual>
</tile>

Komunikat wysłany do centrum powiadomień zawiera wszystkie następujące właściwości:

dzień1_obraz	day2_obraz	day3_image	day4_image	zdjęcie_dzień5
dzień1_tempC	day2_tempC	day3_tempC	dzień4_tempC	day5_tempC
day1_tempF	dzień2_tempF	dzień3_tempF	day4_tempF	day5_tempF

Korzystając z tego wzorca, zaplecze wysyła tylko jeden komunikat bez konieczności przechowywania określonych opcji personalizacji dla użytkowników aplikacji. Na poniższej ilustracji przedstawiono ten scenariusz:

Jak zarejestrować szablony

Aby zarejestrować się przy użyciu szablonów przy użyciu modelu instalacji (preferowanego) lub modelu rejestracji, zobacz Zarządzanie rejestracją.

Język wyrażeń szablonu

Szablony są ograniczone do formatów dokumentów XML lub JSON. Ponadto wyrażenia można umieszczać tylko w określonych miejscach, na przykład w atrybutach węzła lub wartościach XML oraz w wartościach właściwości ciągu dla formatu JSON.

W poniższej tabeli przedstawiono język dozwolony w szablonach:

Wyrażenie	Opis
$(prop)	Odwołanie do właściwości zdarzenia o podanej nazwie. Nazwy właściwości nie są rozróżniane ze względu na wielkość liter. To wyrażenie jest rozpoznawane w wartości tekstowej właściwości lub w pusty ciąg, jeśli właściwość nie jest obecna.
$(prop, n)	Tak jak powyżej, ale tekst jest jawnie przycięty do n znaków, na przykład $(title, 20) przycina zawartość właściwości tytułu do 20 znaków.
. (prop, n)	Jak powyżej, ale tekst jest sufiksowany z trzema kropkami, ponieważ jest obcięty. Całkowity rozmiar przyciętego ciągu i końcówki nie przekracza n znaków. (tytuł, 20) W przypadku właściwości wejściowej "To jest wiersz tytułu" wynik to To jest tytuł...
%(prop)	Podobnie jak $(name), z tą różnicą, że dane wyjściowe są kodowane za pomocą identyfikatora URI.
#(prop)	Używane w szablonach JSON (na przykład w przypadku szablonów systemów iOS i Android). Ta funkcja działa dokładnie tak samo jak wcześniej określona wartość "$(prop)", z wyjątkiem przypadków użycia w szablonach JSON (na przykład szablonów firmy Apple). W takim przypadku, jeśli ta funkcja nie jest otoczona przez "{','}" (na przykład, 'myJsonProperty' : '#(name)'), i daje wynik w postaci liczby w formacie JavaScript, na przykład, regexp: (0|([1-9][0-9]*))(\.[0-9]+)?((e|E)(\+|-)?[0-9]+)?, to wyjściowy JSON jest liczbą. Na przykład '"badge: "#(name)" zmienia się na "badge" : 40 (a nie na "40").
„text” lub "text"	Literał. Literały zawierają dowolny tekst ujęty w cudzysłowach pojedynczych lub podwójnych.
expr1 + expr2	Operator łączenia łączący dwa wyrażenia w jeden ciąg.

Wyrażenia mogą być dowolną z powyższych form.

W przypadku używania łączenia całe wyrażenie musi być otoczone znacznikiem {}. Na przykład {$(prop) + ‘ - ’ + $(prop2)}.

Na przykład następujący szablon nie jest prawidłowym szablonem XML:

<tile>
  <visual>
    <binding $(property)>
      <text id="1">Seattle, WA</text>
    </binding>  
  </visual>
</tile>

Jak wyjaśniono wcześniej, podczas korzystania z łączenia wyrażenia muszą być opakowane w nawiasy klamrowe. Na przykład:

<tile>
  <visual>
    <binding template="ToastText01">
      <text id="1">{'Hi, ' + $(name)}</text>
    </binding>  
  </visual>
</tile>

Następne kroki

Dowiedz się więcej o usłudze Azure Notification Hubs