© StonePictures/Shutterstock.com
Teil 2: Adaptive Cards bereichern die Darstellung

In der Timeline verankert


Microsoft spielt mit dem Timeline API ein klassisches Ökosystem-Game: Es handelt sich, wie in vielen anderen Fällen auch, um ein System, das Redmond den Zugriff auf Plattformen abseits von Windows ermöglichen soll.

Für dieses System führt das Unternehmen eine Vielzahl interessanter Erweiterungen ein, die wir uns in den folgenden Schritten näher ansehen wollen. Zur Auffrischung und für Quereinsteiger sei das API nochmals anhand von Abbildung 1 illustriert.

hanna_timeline_teil2_1.tif_fmt1.jpgAbb. 1: Das Timeline-API stellt „Karten“ dar (Quelle: Microsoft)

Applikationen erzeugen im Rahmen ihrer Ausführung als User Activities bezeichnete Zeitstempelelemente, die in der Timeline des Benutzers aufscheinen. Nach dem Anklicken des Symbols links der Taskleiste kann der Benutzer so zu schon durchgeführten Aktivitäten zurückkehren, was ihm das Wechseln zwischen Aufgaben erleichtert.

Microsoft beschränkt das Timeline API übrigens absichtlich nicht auf Windows-Clients: Android- und iOS-Entwickler können Timeline-Funktionalität über den in Teil 3 dieser Artikelserie besprochenen Graph Service ebenfalls in ihre Programme integrieren.

Von der reichen Darstellung

Die am Ende des vorherigen Teils erzeugte Applikation konnte eine Karte in die Timeline einfügen und ließ sich auch aus der Timeline heraus reaktivieren. Wer Abbildung 1 genauer betrachtet, sieht allerdings, dass wir aus grafischer Sicht die Möglichkeiten des APIs nur leidlich ausnutzen: Das Festlegen einer Hintergrundfarbe und das Einschreiben zusätzlicher textueller Informationen führt nicht zu optisch attraktiven Tiles.

Wer – wie der Autor – mit Windows Mobile aufgewachsen ist, reibt sich nun die Hände und freut sich über ein GDI Handle, in dem er mehr oder weniger nach Belieben fuhrwerken darf. Microsoft lernte mit Windows 10 allerdings aus den Fehlern des in Abbildung 2 gezeigten Homescreens. Er war, ob schlecht programmierter Plug-ins und der damals geringen Rechenleistung, nicht sonderlich performant.

hanna_timeline_teil2_2.tif_fmt1.jpgAbb. 2: Wehe dem, der hier ein ineffizient programmiertes Plug-in installiert

Das im letzten Artikel nur angerissene Adaptive-Card-Framework weicht dieser Situation aus: Anstatt dem Entwickler die alleinige Verantwortung über das Leben der Karte zu geben, treten nun zwei Stakeholder auf. Erstens der Autor der Karte, der für die Erzeugung der anzuzeigenden Daten verantwortlich ist. Er schreibt – Microsoft setzt dies übrigens rigoros um – in einem streng deskriptiven JSON API eine Präsentation dessen, was er dem Benutzer gerne anzeigen würde.

Dieser String wandert sodann an die Kartenverwaltungs-Engine. Für die eigentliche Darstellung ist der Experience Owner verantwortlich, der in seinem Programm die Informationen von Microsofts Server bezieht und diese darstellt. Er soll dabei auf die „narrativen“ Möglichkeiten seiner Benutzerschnittstelle setzen.

Microsoft spezifiziert vier Designparadigmen [1]: Erstens sind die Kartenlayouts nicht pixelperfekt – der Host der Kartenanzeige hat explizit das Recht, das Aussehen der Informationen an seine lokale Situation anzupassen. So könnte beispielsweise ein Midnight-Loft-Anzeigeprogramm das Aussehen der Karten verändern, um sie nächtlicher aussehen zu lassen. Microsoft setzt dies um – am Ende des Artikels finden Sie eine Gruppe von Beispielrenderings, die aus ein- und demselben JSON-String entstanden.

Daraus folgt die zweite Regel, nach der der Autor die Inhalte besitzt, während die Hostapplikation der alleinige Herrscher über das Look and Feel ist. Zudem sollen Adaptive Cards einfach aber ausdrucksstark sein – in der Dokumentation nennt Microsoft Markdown als Beispiel. Zu guter Letzt ist das API minimal – Microsoft möchte ein MVP anbieten, das im Laufe der Jahre vielleicht um die eine oder andere Funktion erweitert wird.

Alles im Browser

Visual Studio und Co. spielen bei der Arbeit mit Adaptive Cards nur eine sehr untergeordnete Rolle. Im Windows-API findet sich zwar eine Klasse namens AdaptiveCardBuilder, die sich bei Reflexion aber funktionsarm präsentiert:

public static class AdaptiveCardBuilder { public static IAdaptiveCard CreateAdaptiveCardFromJson(string value); }

Die Methode CreateAdaptiveCardFromJson nimmt einen JSON-String entgegen und verwandelt ihn in eine Repräsentation der Karte. Die eigentliche Erzeugung der Inhalte erfolgt stattdessen mit einem Visualizer [2], der sich im laufenden Betrieb wie in Abbildung 3 präsentiert. Bei GitHub [3] findet sich zwar auch eine .NET-basierte Abstraktionsumgebung, die in der Praxis aber eher wenig Verwendung findet.

hanna_timeline_teil2_3.tif_fmt1.jpgAbb. 3: Die Entwicklung von Adaptive Cards erfolgt im Browser

Auf der linken Seite des Bildschirms findet sich dabei eine Textbox mit Syntaxhervorhebung, in der Sie JSON-Strings ablegen dürfen. Auf der rechten Seite erscheint eine gerenderte Ansicht des Resultats – unser Beispiel (Abb. 3) stammt aus Microsofts Beispielsammlung [4].

Wichtig ist der oben rechts eingeblendete Applikationswähler. Mit ihm können Sie entscheiden, welche Rendering-Engine für die Erzeugung der angezeigten Karte verantwortlich ist. Microsoft wählt hier zum Zeitpunkt der Drucklegung entweder Skype oder Outlook aus – wenn Sie Karten für die Timeline erzeugen möchten, müssen Sie die Option Windows Timeline auswählen.

Auf der Unterseite findet sich der Knopf Speak this Card, mit dem Sie ...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang