• Artikel

Februar 2016

Band 31, Nummer 2

Windows 10 – Universelle Windows-Plattform-Apps für Webentwickler

Von Tim Kulp | Februar 2016

Als Webentwickler in einem größeren Unternehmen sind Sie mit HTML, CSS und JavaScript umfassend vertraut. Sie können dynamische Webanwendungen erstellen, die sich an die Bildschirmgröße anpassen und in allen Ihren unterstützten Browsern bzw. auf allen unterstützten Geräten eine vergleichbare Funktionalität bieten. Dieselben Kenntnisse, die Sie für Webanwendungen nutzen, können auch zum Entwickeln von UWP-Apps (Universelle Windows-Plattform) zum Tragen kommen. Unabhängig davon, ob Sie Desktop-, mobile oder Windows 10-Plattform-Apps entwickeln, verschaffen Ihnen die beim Erstellen browserübergreifender Webanwendungen gesammelten Erfahrungen auf der UWP einen Vorsprung.

In diesem Artikel untersuche ich, wie bei der Webentwicklung und Erstellung browserübergreifender Anwendungen gewonnenes Wissen in flexible UWP-Apps einfließen kann, die auf allen Windows-Geräten laufen. Ich beginne zunächst mit der Analyse, wie sich die Grundlagen der Entwicklung dynamischer Schnittstellen von CSS und HTML auf die UWP übertragen lassen. Als Nächstes gehe ich auf das Verwenden von VisualStates und XAML-Ansichten zum Strukturieren Ihrer App basierend auf spezifischen Gerätefunktionen ein. Schließlich nutze ich adaptiven Code zum Abzielen auf Geräte basierend darauf, wie das gute alte JavaScript für das Abzielen auf bestimmte Browser genutzt wurde.

Warum ist XAML für Webentwickler interessant?

In diesem Artikel ziehe ich Parallelen zwischen der Webentwicklung und XAML. Webentwickler verfügen ggf. bereits über umfassende HTML-/CSS-/JavaScript-Kenntnisse, die sie für die Entwicklung von UWP-Apps nutzen möchten. Wenn Sie HTML und JavaScript mögen, können Sie weiter damit arbeiten. Wenn die UWP noch neu für Sie ist und Sie unsicher sind, wo Sie anfangen sollen, bietet sich XAML aufgrund seines stark typisierten Wesens unbedingt für den Einstieg an.

Ein gängiges Beispiel hierfür ist das Vergleichen eines rasterbasierten Layouts in XAML und HTML. In XAML beginnt das Erstellen eines Rasterlayouts mit dem Hinzufügen eines Rastersteuerelements, Festlegen der Spalten und Zeilen sowie dem Zuweisen der einzelnen Steuerelemente im Raster zu einer bestimmte Zelle oder Zeile. In HTML gibt es zahlreiche Möglichkeiten zum Erstellen eines Rasterlayouts, wie z. B.:

  • Verwenden von „float“-Eigenschaften mit festgelegter Höhe und Breite für das Erstellen von Zellen mit „clear“-Eigenschaften zum Starten einer neuen Zeile
  • Anwenden von „display:grid“ auf das Containerelement, wobei jedes untergeordnete Element über eine festgelegte Spalte und Zeile verfügt
  • Verwenden einer Tabelle mit den Elementen „tr“ und „td“

Welche davon Sie umsetzen, hängt von Ihren CSS- bzw. HTML-Kenntnissen ab. Allerdings bieten Ihnen diese Ansätze keine Hilfe mittels Tools wie IntelliSense, was beim Rastersteuerelement in XAML der Fall ist. Die stark typisierten Steuerelemente von XAML vereinfachen das Erstellen einer Benutzeroberfläche mithilfe von IntelliSense, was für Entwickler, für die die UWP neu ist, überaus hilfreich ist.

Stark typisierter Code ist auch von großem Nutzen, wenn es um das Beheben von Problemen geht. In HTML/CSS/JavaScript können Entwickler mithilfe von schwach typisiertem Code die Regeln sehr flexibel an die Anforderungen der App anpassen. Das ist beim Entwickeln von Apps eine gute Sache, kann bei ihrer Unterstützung jedoch zum Alptraum werden. Die Behandlung von Problemen mit schwach typisiertem Code kann schwierig sein, wenn sich Typen ändern oder sich Objekte dynamisch ändern. Als Entwickler in Großunternehmen kann das Entwickeln von Apps Spaß machen, doch ab einem gewissen Punkt muss sich jemand um den Betrieb dieser App kümmern. Die Möglichkeit der einfachen Navigation durch die Funktionalität einer App mithilfe stark typisierter Objekte und IntelliSense hilft dem Supportteam, die App zu verstehen.

Wenn Sie leidenschaftlich gern mit HTML/CSS/JavaScript arbeiten, bietet Ihnen die UWP eine Plattform, auf der Sie Ihren vorhandenen Code zum Herstellen überzeugender Apps nutzen können. HTML/CSS/JavaScript und XAML sind nützliche Tools mit vielen Vor- und Nachteilen. Es gibt zwei Artikel dazu, warum ein Autor lieber mit XAML als mit JavaScript arbeitet (bit.ly/1NxUxqh), während ein anderer JavaScript gegenüber XAML den Vorzug gibt (bit.ly/1RSLZ2G). Ich bevorzuge HTML für Webanwendungen. Doch ich möchte Sie ermutigen, sich mit XAML vertraut zu machen, wenn die UWP für Sie Neuland ist. Sie werden erfahren, wie Sie die Supportkosten für Ihr Team mithilfe von stark typisiertem Code mit umfassender IntelliSense-Integration niedrig halten können und Spaß dabei haben, etwas Neues zu lernen.

Auf vorhandenen Kenntnissen aufbauen

Die UWP weist viele Ähnlichkeiten mit den Grundlagen des Webdesigns auf. Grundlegende Vorstellungen wie die Trennung von Bereichen bei der Webentwicklung zwischen HTML und JavaScript werden in der UWP als XAML und Code-Behind-Datei „XAML.cs“ ausgedrückt. Die ganze Logik fließt in die Code-Behind-Datei, während sich die XAML-Datei um die gesamte Darstellung kümmert (ebenso wie die ganze Logik in JavaScript eingeht und HTML mithilfe von CSS für die Darstellung zuständig ist). Darüber hinaus arbeiten viele moderne Webanwendungen mit Frameworks wie Knockout und AngularJS, um die Datenbindung über das MVVM-Entwurfsmuster (Model-View-ViewModel) zu implementieren. Kenntnisse dieser Frameworks und von MVVM im Allgemeinen sind die Grundlage für das Verständnis der Datenbindung auf der UWP. Wenngleich die Syntax sich bei Webentwicklung und UWP unterscheidet, verfügen Webentwickler hinsichtlich der Grundkonzepte über eine solide Grundlage für die Entwicklung geräte-, browser- und funktionsübergreifender Apps.

Es gibt Unterschiede zwischen der Webentwicklung und UWP, die ich nicht in diesem Artikel behandle, wie z. B. die Zustandsverwaltung und Datenspeicherung. In diesem Artikel liegt der Schwerpunkt auf dem Erstellen der Benutzeroberfläche und dem Sicherstellen, dass die App mit dem Gerät interagieren kann, auf dem sie ausgeführt wird.

Positionierung: Die Eigenschaften „float“ und „clear“ in Bezug auf „RelativePanel“

In HTML wird die Position jedes Elements anhand seiner Position im Dokumentobjektmodell bestimmt. HTML ist hierarchisch (von oben nach unten) aufgebaut, wobei Elemente vom ersten deklarierten Element bis zum letzten gerendert werden. Nach der Einführung von CSS waren für Elemente differenziertere Layouts möglich, und zwar basierend der Einstellung des Anzeigestils (Inline, Block usw.), der Position (relativ oder absolut) und der Eigenschaften „float“ und „clear“ des Elements. Mithilfe von „float“ können Webentwickler ein HTML-Element aus dem hierarchischen Ablauf herausnehmen und links (float: left) oder rechts (float: right) neben dem enthaltenden Element platzieren.

Stellen Sie sich ein einfaches Layout mit Kopfzeile, Hauptinhalt, Randleiste und Fußzeile vor. Durch Verwenden von „float“ wird der Browser angewiesen, die Randleiste am rechten Rand des Containers und den Hauptinhalt am linken Rand des Containers zu rendern. Bei Verwenden von „float“ werden Elemente abhängig vom angegebenen „float“-Wert links oder rechts nebeneinander positioniert. „clear“ dient zum Beenden des „float“-Modus von Elementen und zum Zurückkehren zum standardmäßigen hierarchischen HTML-Ablauf. Abbildung 1 zeigt ein Beispiel von „float“ zum Erstellen eines einfachen Layouts.

Abbildung 1: Verwenden von „float“ zum Erstellen eines einfachen Layouts

div {
  width: 100%;
}
mainContent {
  width: 60%; float: left;
}
  sidebar{
  width: 40%; float: right;
}
clearer {
  clear: both;
}
CSS for design
<header>
</header>
<div>
  <section class="content"></section>
  <section class="sidebar"></section>
  <div class="clearer"></div>
</div>
<footer>
</footer>
HTML for design

Während Webentwickler „float“ und „clear“ zum Erstellen eines Layouts nutzen, bietet die UWP hierfür das Steuerelement namens RelativePanel, das (wie der Name schon sagt) die Definition eines Layouts mithilfe relativer Beziehungen zu anderen Steuerelementen ermöglicht. Ebenso wie „float“ ermöglicht RelativePanel Entwicklern das Festlegen, wie Steuerelemente relativ zu einem Ankersteuerelement positioniert werden. CSS-Klassen dienen zum Bestimmen der Positionierung der Elemente auf der Webseite. Verwenden Sie zum Replizieren desselben Layouts RelativePanel und die an RelativePanel angefügten Eigenschaften innerhalb der Steuerelemente:

<RelativePanel>
  <!-- Header is the anchor object for the relative panel -->
  <TextBlock Text="Header" Name="tbHeader"></TextBlock>
  <TextBlock Text="Content" RelativePanel.Below="tbHeader"
    Name="tbContent"></TextBlock>
  <TextBlock Text="SideBar" RelativePanel.RightOf="tbContent"
    RelativePanel.Below="tbHeader" Name="tbSideBar"></TextBlock>
  <TextBlock Text="Footer" RelativePanel.Below="tbSideBar"
    Name="tbFooter"></TextBlock>
</RelativePanel>

In diesem Codeblock ist die Positionierung jedes Steuerelements relativ zur Position des Ankersteuerelements (in diesem Fall ist der Header „TextBlock“ der Anker). Mithilfe von RelativePanel kann jedes Steuerelement in Bezug auf die anderen Steuerelement an der gewünschten Stelle auf dem Bildschirm platziert werden. An den Stellen, an denen Webentwickler „float: left“ verwenden, nutzen UWP-Entwickler RelativePanel.LeftOf oder Relative­Panel.RightOf (für „float: right“) zum Positionieren von Inhalten. Während dies mit dem Verwenden von „float“ vergleichbar ist, gibt es kein mit „clear“ vergleichbares Konzept, um zum normalen Ablauf zurückzukehren. Stattdessen stellen Sie bloß fest, dass sich etwas unter einem vorherigen Element befindet. Dadurch wird die Behandlung von Layoutproblemen erleichtert, da das Verwalten von „float“- und „clear“-Elementen für Entwickler ohne umfassende CSS-Kenntnisse schwierig sein kann. Das Verwenden von RelativePanel ermöglicht die Deklaration, wo ein Steuerelement in Bezug zu anderen Steuerelementen angezeigt werden soll. Nach Schließen von RelativePanel kehrt die App zum normalen Renderingablauf von XAML zurück (der wie bei HTML hierarchisch ist).

Skalierung: Prozentsätze in Pixel

Das Erstellen einer dynamisch anpassbaren Webanwendung mittels Größenänderung erfordert das Verwenden relativer Größen für Elemente. Stellen Sie sich anhand des Seitenlayouts mit Kopfzeile, Inhalt, Randleiste und Fußzeile vor, dass diese Benutzeroberfläche ursprünglich für einen Desktopbildschirm entwickelt wurde. Webdesigner würden für dieses Layout zunächst die optimale Pixelbreite für diese Seite bestimmen. Bei diesem Beispiel ist die Seitenbreite 1000 Pixel. Bei der Erstellung der einzelnen Elemente im Entwurf werden diese mit dem Container mit 1000 Pixeln im Hinterkopf entsprechend der Pixelbreite entwickelt. In HTML hätte der Inhaltsabschnitt eine Breite von 800 Pixeln, während der Randleistenabschnitt 200 Pixel breit wäre. Gemäß der Formel „Ziel:Kontext = Prozentsatz“ nimmt der Inhaltsabschnitt 80 % des Kontexts (Kontext = Seite mit 1000 Pixel) ein, während die Randleiste 20 % einnimmt.

Bei Verwenden von Prozentsätzen beim Webdesign lässt sich die Größe des Layouts entsprechend der Änderung der Containergröße ändern. Wenn in diesem Fall das aus 1000 Pixel bestehende Seitenobjekt vom Benutzer auf 659 Pixel verkleinert würde, würde sich die Größe von Inhalt und Randleiste in 527 bzw. 131 Pixel ändern. Gleichfalls lässt sich durch Erstellen von Formatvorlagen, in denen „em“ anstelle spezifischer Punkt- oder Pixelgrößen verwendet wird, die Schriftart entsprechend dem Kontext skalieren. Mithilfe dieser Vorgehensweisen kann sichergestellt werden, dass ein Entwurf die proportionale Größe unabhängig von der Fenstergröße behält.

Während das Arbeiten mit Prozentsätzen wie einfache Mathematik aussieht, gibt es andere Faktoren, die sich auf die Skalierung von Elementen auswirken, z. B. die Pixeldichte des Geräts und die Ausrichtung, die für einen Grad an Unvorhersehbarkeit in Ihrem Entwurf sorgen. Die UWP vereinfacht die Skalierung mithilfe des Konzepts des „effektiven Pixels“ für alle Maßeinheiten. Ein effektives Pixel ist nicht dasselbe wie ein einzelnes Pixel. Effektive Pixel arbeiten mit dem UWP-Skalierungsalgorithmus, um zu bestimmen, wie ein effektives Pixel basierend auf der Standardentfernung des Geräts vom Benutzer und der Pixeldichte dargestellt werden soll.

Ein Surface Hub hat beispielsweise eine wesentliche höhere Pixeldichte als ein Tablet oder Smartphone. UWP-Entwickler müssen lediglich in Tools wie Blend einen Build mit effektiven Pixeln erstellen und überlassen dem Skalierungsalgorithmus die erforderlichen komplexen Berechnungen für eine Vergrößerung oder Verkleinerung. Einen Aspekt müssen Sie beachten: Effektive Pixel müssen ein Vielfaches von vier sein. Basierend auf der Funktionsweise des Skalierungsalgorithmus sorgt das Verwenden von Vielfachen von vier bei der Skalierung der Benutzeroberfläche für saubere Ränder.

ViewStates und Medienabfragen

Bei der Webentwicklung stellt CSS die Layoutinformationen für eine Anwendung bereit. Die Entwicklung mit Prozentsätzen ermöglicht einer Anwendung Größenänderungen, doch an einer bestimmten Stelle muss der Entwurf geändert und angepasst werden, um die sich ändernden Anzeigeanforderungen zu erfüllen. Ein Layout, das für ein Mobilgerät wie ein Tablet entwickelt wird, ist nicht identisch mit dem Layout für ein Präsentationsgerät wie Surface Hub mit einer Bildschirmdiagonalen ab 80 Zoll. Eine ältere Analogie für das Webdesign ist der Fall, bei dem ein Benutzer einen bildschirmbasierten Entwurf ausgeben möchte. CSS ermöglicht Designern das Beheben des Dilemmas des auszugebenden Bildschirms mithilfe von CSS-Medienabfragen. Wenn der Benutzer den Entwurf ausgibt, verwendet der Browser die Ausgabe-CSS anstelle der Bildschirm-CSS. Aufgrund der immer größeren Beliebtheit des dynamischen (responsiven) Webdesigns unterstützen Medienabfragen nun detailliertere Informationen. Hier folgt ein Beispiel einer CSS-Medienabfrage:

<link type="text/css" rel="stylesheet" 
  href="styles/719style.css"
  media="screen and (max-device-width: 719px)"/>

Bei dieser Abfrage wird die Datei „719style.css“ angewendet, wenn das Medium, das die Webanwendung anzeigt, ein Bildschirm mit einer Gerätebreite kleiner gleich 719 Pixel ist. Als Beispiel kann diese Medienabfrage verwendet werden, um die „float“-Werte zu löschen und die Inhalts- und Randleistenelemente in gestapelter Form anstatt nebeneinander zu präsentieren. Mithilfe von Medienabfragen können Webentwickler die Anzeige basierend auf der Bildschirmgröße, -auflösung, -ausrichtung und vielen weiteren Optionen anpassen (die vollständige Liste für CSS3 finden Sie unter bit.ly/1riUA2h).

In UWP kann der ViewStateManager ähnlich wie Medienabfragen zum Ändern des Anwendungsentwurfs basierend auf definierten Parametern verwendet werden. Der VisualStateManager enthält mindestens eine VisualStateGroup, ein Containerobjekt mit mehreren ViewStates. Jeder ViewState enthält die Setter (Eigenschaften, die für jedes Steuerelement aktualisiert werden) und Trigger (wodurch die Setter geändert werden). Der ViewStateManager verwaltet die Trigger, um zu bestimmen, wann die Setterwerte eines bestimmten ViewState angewendet werden. Hinsichtlich CSS sind die Trigger wie Medienabfragen, und die Setter sind Formatvorlagenwerte innerhalb der Formatvorlage, auf die in der Medienabfrage verwiesen wird. Siehe das Beispiel in Abbildung 2.

Abbildung 2: Neupositionieren von Steuerelementen basierend auf „VisualState“-Triggern

<VisualStateManager.VisualStateGroups>
  <VisualStateGroup x:Name="ResponseStateGroup">
    <VisualState x:Name="LessThan720">
      <VisualState.Setters>
      <Setter Target="tbSideBar.(RelativePanel.Below)" Value="tbContent"/>
        <Setter Target="tbSideBar.(RelativePanel.RightOf)" Value=""/>
      </VisualState.Setters>
      <VisualState.StateTriggers>
        <AdaptiveTrigger MinWindowWidth="1"/>
      </VisualState.StateTriggers>
    </VisualState>
    <VisualState x:Name="GreaterThan720">
      <VisualState.Setters>
        <Setter Target="tbSideBar.(RelativePanel.Below)" Value="tbHeader"/>
        <Setter Target=" tbSideBar.(RelativePanel.RightOf)" Value="tbContent"/>
      </VisualState.Setters>
      <VisualState.StateTriggers>
        <AdaptiveTrigger MinWindowWidth="720"/>
      </VisualState.StateTriggers>
    </VisualState>
  </VisualStateGroup>
</VisualStateManager.VisualStateGroups>

In diesem Code werden zwei VisualStates eingerichtet. Der ViewState namens LessThan720 wird ausgelöst, wenn die Fensterbreite 1-719 Pixel beträgt. Wenn das Fenster auf mindestens 720 Pixel erweitert wird, wird der ViewState namens GreaterThan720 ausgelöst. Jede dieser „ViewState“-Einstellungen verwendet die „RelativePanel“-Einstellungen des Steuerelements „tbSideBar“. Wenn die Fenstergröße kleiner als 720 ist, dann ist der Bildschirm nicht groß genug, um einen Entwurf zu unterstützen, bei dem sich Inhalte neben der Randleiste befinden. In dieser Situation wird der ViewState „LessThan720“ ausgelöst, der die Randleiste unter dem TextBlock mit dem Hauptinhalt stapelt. Dies entspricht dem Verwenden der Medienabfrage dahingehend, dass ich „float: none“ in einer Datei des Typs „LessThan719.css“ festlegen kann.

Ebenso wie Medienabfragen können ViewStates zum Neupositionieren oder Umgestalten von Steuerelementen basierend auf Triggern verwendet werden. Das Verwalten von ViewStates und ViewStateGroups kann kompliziert werden, sobald eine Oberfläche komplexer wird. Das beste Tool zum Verwalten komplexer ViewState-Änderungen ist Blend für Visual Studio 2015. Mithilfe des Editors von Blend können Sie neue VisualStates erstellen und die Änderungen beim App-Entwurf verfolgen, während Sie sie vornehmen. Blend übernimmt für Sie das Schreiben des gesamten XAML-Codes und stellt sicher, dass Sie die benötigten Daten zum Auslösen der VisualState-Änderung bereitstellen. Die Microsoft Virtual Academy bietet unter bit.ly/1P94e32 ausgezeichnete Videos mit exemplarischen Vorgehensweisen für die ViewState-Verwaltung mit Blend.

Verwenden von Ansichten für den Neuentwurf der Oberfläche

Mitunter hat eine mobile Website eine andere Benutzeroberfläche aufgrund von weniger Anwendungsfällen oder einer Änderung des Fokus, den die mobile Website im Vergleich mit der vollständigen Desktopoberfläche bietet. In diesem Szenario passen Webentwickler zumeist den Inhalt an die mobile Umgebung zum Ermöglichen einer optimierten Erfahrung an oder heben die Funktionsmöglichkeiten des Mobilgeräts hervor. Mithilfe verschiedener Erkennungsmethoden können Webentwickler Benutzer zu einer umgestalteten an ihr Gerät angepassten Oberfläche auf einer Website umleiten, die häufig „m.webapp.com“ heißt.

UWP bietet dieselbe Funktionalität mithilfe von Ansichten (Views). Je nach App kann das Arbeiten mit verschiedenen Gerätefamilien einen solchen Unterschied bei der Benutzeroberfläche erforderlich machen, für den der ViewStateManager ggf. nicht das richtige Tool ist. Ansichten ermöglichen Entwicklern das Nutzen von vorhandenem Back-End-Code mit einer neuen XAML-Benutzeroberfläche. Sie können die Nutzung von Ansichten mithilfe überlegt strukturierter ViewModels vereinfachen. Zugleich kann ein einzelnes „ViewModel“-Objekt von mehreren Ansichten verwendet werden. Knockout- oder AngularJS-Kenntnisse helfen Webentwicklern beim Erstellen ordnungsgemäßer ViewModels in UWP für angepasste Benutzererfahrungen für eine bestimmte Gerätefamilie.

Sie können eine Ansicht für ein bestimmtes Gerät einrichten, indem Sie im Ordner „Views“ der App einen Ordner erstellen.

Erstellen Sie im Ordner „Views“ einen neuen Ordner namens „Device­Family-Mobile“. Dies weist die Modern Resource Technology an, die Ansicht „MainPage.xaml“ im Ordner „DeviceFamily-Mobile“ zu verwenden, wenn die MainPage auf einem Gerät der Mobilgerätfamilie (z. B. einem Smartphone) angefordert wird. Wenn die Anforderung der MainPage von einer anderen Gerätefamilie stammt, ist die Antwort die standardmäßige MainPage. Diese Funktionalität ermöglicht UWP-Entwicklern das Erstellen einer auf das Ziel abgestimmten Benutzeroberfläche für Anwendungsfälle, die für bestimmte Windows-Gerätefamilien eindeutig sind.

Adaptiver Code

Beim Erstellen von Webanwendungen zeigt sich, dass nicht alle Browser gleich sind. In einem Unternehmen gibt es ggf. einen Standardbrowser, doch wenn für externe Benutzer entwickelt wird, sorgen verschiedene Betriebssysteme, Browsertypen und -versionen für Komplexität. Webentwickler kennen viele Tricks, um mit diesen Unterschieden zurechtzukommen. Bibliotheken wie Modernizr (modernizr.com) haben das Bewältigen dieser Komplexität vereinfacht, allerdings ist das Aktivieren von Features basierend auf Gerät oder Browser für Webentwickler nichts Neues.

Das Erstellen von UWP-Apps kann ähnlich komplex wie browserübergreifende Funktionalität sein. Stellen Sie sich eine Anwendung zum Erstellen von Notizen vor, in der Benutzer ihren Notizen Bilder hinzufügen können. Die App kann z. B. die eingebaute Kamera eines Smartphones nutzen, um ein Foto zu machen, oder Benutzern lediglich das Anzeigen von Bildern erlauben, die sich bereits auf ihren Geräten befinden.

Der erste Schritt bei Verwenden gerätespezifischer Funktionen ist das Sicherstellen, dass die ordnungsgemäßen Erweiterungs-API dem Projekt hinzugefügt wurde. Als Beispiel müssen bei der Notizen-App die Hardwaretasten auf einem Smartphone zugänglich sein. Um diese Tasten verwenden zu können, müssen Sie einen Verweis auf die Windows Mobile-Erweiterungen für die UWP hinzufügen. Dies erfolgt durch Hinzufügen eines Verweises zum Projekt. Anschließend muss erst „Universal Windows“ und dann „Extensions“ ausgewählt werden. Es wird eine Liste mit möglichen Erweiterungen wie „Desktop“, „Mobil“ und „Team“ (für Surface Hub) angezeigt. Wählen Sie die Erweiterungen aus, die dem Projekt hinzugefügt werden sollen, und klicken Sie dann auf „OK“.

Während bei JavaScript die Erkennung der vom Browser unterstützten Funktionen mithilfe einer Reihe von Navigatorüberprüfungen erfolgt, prüft die App auf der UWP mithilfe der „IsTypePresent“-Methode, ob die benötigte API vorhanden ist. Suchen Sie in der Notizen-App die Hardwaretaste zum Verwenden der Kamera mithilfe des folgenden Codes:

string apiName = "Windows.Phone.UI.Input.HardwareButtons";
if (Windows.Foundation.Metadata.ApiInformation.IsTypePresent(apiName))
{
  Windows.Phone.UI.Input.HardwareButtons.CameraPressed +=
    HardwareButtons_CameraPressed;
}

Dieser kurze Code ermöglicht der App das Abzielen auf bestimmte Gerätefunktionen, die über die Erweiterungs-APIs hinzugefügt wurden. Durch Umschließen der Deklaration des „CameraPressed“-Ereignishandlers mit der „IsTypePresent“-Methode, stellen Sie sicher, dass Sie nicht versuchen, den Ereignishandler zu registrieren, wenn die API nicht vorhanden ist. Es gibt Tools, die sicherstellen können, dass die API-Überprüfungen erfolgen, damit die App nicht abstürzt, sobald die API nicht vorhanden ist. „PlatformSpecific“ ist ein exzellentes NuGet-Paket zum Vereinfachen des Identifizierens und Umschließens von Verweisen auf eine Erweiterungs-API, die nicht zuerst von der „ApiInformation.IsTypePresent“-Methode überprüft wird. Weitere Informationen zu diesem NuGet-Paket finden Sie auf der GitHub-Website von PlatformSpecific unter http://bit.ly/1GvhkF0.

Wie bei der Webentwicklung muss mitunter eine bestimmte Version des Browsers auf einen Client oder Unternehmensstandard abgestimmt werden. In diesen Fällen müssen sich Webentwickler auf eine bestimmte Browserkonfiguration konzentrieren, die ggf. nicht dem entspricht, was der Rest des Internets verwendet.

Vergleichbar müssen UWP-Entwickler ggf. auf bestimmte Verträge einer Erweiterungs-API abzielen, um vorhandenen Code beibehalten zu können. Dies ist sehr nützlich bei Unternehmensanwendungen, bei denen das IT-Betriebsteam eine schnelle und eine langsame Variante für die Bereitstellung von Updates auf den Computern der Mitarbeiter einrichten kann. Bei der schnellen Variante erhält eine kleine Gruppe ein neues Feature einer bestimmten Erweiterungs-API, das sofort in die App implementiert werden muss. In diesem Fall benötigt die große zweite Gruppe mit der langsamen Variante weiterhin ihre Funktionalität. Mithilfe von „IsApiContractPresent“ kann die UWP vor der Ausführung des Codes prüfen, ob die Erweiterungs-API und die erwartete spezifische Version verfügbar sind:

if(Windows.Foundation.Metadata.ApiInformation.IsApiContractPresent(apiName, 3))
{
  newKillerFunction();
}

In diesem Codesegment führt die App die Funktion „newKillerFunction“ nur aus, wenn die bereitgestellte „apiName“-Version mindestens 3 ist. Ist die Version kleiner als 3, wird „newKillerFunction“ nicht ausgeführt. Wenn eine höhere Version vorhanden ist (z. B. Version 4), wird „newKillerFunction“ ausgeführt.

Zusammenfassung

Bei der UWP-Entwicklung kommen viele der Fähigkeiten und Kenntnisse zum Tragen, die Webentwickler zum Erstellen dynamischer, browserübergreifender Webanwendungen nutzen. Das Entwerfen von Layouts sowie das Reagieren auf Unterschiede bei Anzeigen (statisch und dynamisch) und Systemfunktionen ist für Webentwickler nichts Neues, die mit einer großen Vielzahl unterschiedlicher Webbrowser umgehen können müssen. Das Anwenden dieser Kenntnisse auf die UWP-Entwicklung ist hilfreich beim Erstellen umfassender Benutzeroberflächen, die sich Bildschirmgrößen, Geräten und Funktionen anpassen müssen.

Tim Kulpist ein erfahrener IT-Architekt aus Baltimore, USA. Er entwickelt Web-, mobile und UWP-Anwendungen, ist Autor, Maler, Vater und wäre gern ein verrückter Professor. Folgen Sie ihm auf Twitter: @seccode oder LinkedIn: linkedin.com/in/timkulp.

Unser Dank gilt dem folgenden technischen Experten bei Microsoft für die Durchsicht dieses Artikels: Kevin Hill