Windows 10
Einführung in das Entwickeln von Windows-Apps für Windows 10-Geräte
Das gab es bislang noch nicht: ein einzelnes Windows-Betriebssystem, das auf allen Arten von Windows-Geräten ausgeführt werden kann. Es verfügt über eine einzelne Geräteplattform zum Ermöglichen wirklich universeller Hardwaretreiber und eine einzelne Anwendungsplattform zum Realisieren tatsächlich universeller Windows-Apps. Nach Jahren der Entwicklung ist dies eine bemerkenswerte technische Leistung.
Auf Betriebssystemebene drückt sich dies in einer einzelnen, verwaltbaren und agilen Codebasis aus. Entwicklern wird eine einheitliche, zuverlässige API-Oberfläche auf allen Windows-Geräten geboten, ob auf IoT-Geräten (Internet of Things, Internet der Dinge), wie z. B. Raspberry Pi, oder Smartphones, Xbox, Tablets, Surface Hubs, Laptops, PCs und mehr (wie z. B. Microsoft HoloLens). Wie Abbildung 1 zeigt, handelt es sich um das Versprechen "Code einmal schreiben, aber überall ausführen", das in Windows 10 mit der universellen Anwendungsplattform (UAP) Wirklichkeit wird.
.png "Die universelle App-Plattform ermöglicht Anwendungen auf allen Windows-Gerätefamilien")
Abbildung 1: Die universelle App-Plattform ermöglicht Anwendungen auf allen Windows-Gerätefamilien
Der Weg zu Windows 10
Bis zur Konvergenz von Windows hat es eine Weile gedauert. Noch im Jahr 2011 hatte Microsoft drei Plattformen mit drei Betriebssystemen. Das PC- und Serverbetriebssystem war Windows, das auf der Codebasis von Windows NT aufsetzte. Das Telefonbetriebssystem war Windows Phone, eine Ableitung von Windows CE mit einer Windows NT ähnlichen Oberfläche, aber einer anderen Codebasis. Die Betriebssystem der Xbox 360 war zwar Windows NT, aber eine 10 Jahre alte Verzweigung, die so völlig abweichend war, dass es sich auch um eine eigene Codebasis handelte.
Zu diesem Zeitpunkt arbeitete Microsoft daran, einen gemeinsamen Internet Explorer auf jede Plattform zu bringen. Es gab kein Windows Core, keine Windows-Plattform und keine UAP. Die Implementierung von Internet Explorer unter diesen drei Betriebssystemen war erfolgreich, erforderte aber beträchtliche entwicklungstechnische Verrenkungen.
Bei Windows Phone 8 ersetzte der Windows NT-Betriebssystemkernel Windows CE auf Telefonen. Diese Konvergenz schob den Wechsel in Richtung einer einzigen Codebasis an. Windows, Windows Phone und Xbox 360 nutzten alle den gleichen Kernel, wobei alle weiterhin eigene Codebasen hatten. 2013 kam die Xbox One mit einem mit Windows 8 gemeinsam genutzten Betriebssystemkern auf den Markt. Microsoft war so nah an ein einzigen Codebasis wie nie zuvor, betreute aber immer noch drei unterschiedliche Betriebssysteme.
Windows 10 war die Chance, diese Troika und die dazugehörigen Entwicklungsanstrengungen zusammenfließen zu lassen. Gleichzeitig verlangten jedoch neue Anwendungen von IT-Technologie zusätzlich weitere Windows-Ziele: IoT, Microsoft HoloLens, Surface Hub und künftige Mitglieder der Windows-Gerätefamilie. Windows 10 musste das eine Betriebssystem nicht nur für Windows, Phone und Xbox, sondern auch für alle künftigen Plattformen werden.
Microsoft hat es geschafft. Windows 10 ist das kompakte Ein-Kern-Betriebssystem geworden, das auf allen Geräten der Produktfamilie ausführbar ist. Das war nicht so einfach wie "Datei | Speichern unter". Intelligente Menschen haben hart daran gearbeitet, diese Entwicklungsgroßtat in einem unglaublichen Zeitrahmen zu verwirklichen. Windows 10 ist die zentrale Codebasis, die notwendig ist, um die UAP zu ermöglichen. Jedes Microsoft-Produkt ab diesem Punkt wird für den zentralen Kern geschrieben, der Windows 10 ausmacht.
Einheitlichkeit, nicht Einförmigkeit Die Vereinheitlichung der Codebasen zu einem Kernbetriebssystem bedeutet nicht, dass alle Geräte dieselbe Benutzeroberfläche haben. Windows Phone hat eine raffinierte, sehr geschätzte, einhändig bedienbare Oberfläche, die sich deutlich vom Großbildschirmerlebnis der Xbox unterscheidet. Dies gilt auch für Surface Hub, Microsoft HoloLens und Raspberry Pi, die einen Großteil ihres Nutzens mittels ihrer besonderen Oberflächen bieten. Das Betriebssystem mit seinen Bibliotheken, seiner Runtime und Frameworks ist dennoch identisch. Auch die Geräte- und die Anwendungsplattform sind identisch. Die Benutzeroberflächen- und Shellfunktionen sind jedoch unterschiedlich und an das Nutzungsmodell des jeweiligen Geräts angepasst. Diese sind nicht identisch.
Theoretisch könnte jemand dieses Kernbetriebssystem starten und sogar Apps ausführen, was aber niemand je tun wird, da es nur einen Baustein ist. Zur Unterstützung der einzelnen Gerätegrößen werden dem Kernbetriebssystem gerätespezifische Komponenten hinzugefügt, wie z. B. das Startmenü, spezifische HID-Unterstützung sowie Elemente und Teile, die zum Ermöglichen gerätespezifischer Features wie Desktopanwendungen erforderlich sind. Diese zusätzlichen Komponenten setzen auf dem grundlegenden Betriebssystem auf und dienen zum Bilden der verschiedenen Betriebssystem-SKUs, die Sie als Microsoft-Produkte kennen, wie z. B. Windows, Server, Xbox und HoloLens.
Eine Anwendungsplattform Hier ist ein unterhaltsames Spiel, das Sie mit Ihren Freunden spielen können. Erzählen Sie ihnen, dass Sie die neuesten Microsoft-Anwendungsinnovationen übernehmen wollen, aber nicht auf Windows 10 abzielen. Wie bitte? Windows-Apps der nächsten Generation zielen nicht auf das Betriebssystem, sondern auf die App-Plattform ab. Unter Windows ist die UAP ein einheitliches Anwendungsmodell mit einer API-Oberfläche, die auf jedem Windows-Gerät garantiert wird.
Die UAP ist keine Laufzeit. Eine Windows-App, selbst eine in einer verwalteten Sprache (wie Visual Basic oder C#) geschriebene, wird wie jede andere Anwendung maschinennah kompiliert. Sie wird nicht innerhalb einer Laufzeit ausgeführt und benötigt keine Laufzeit. UAP ist eine allgemeine API-Oberfläche auf Geräten, sodass das Abzielen der Entwicklung auf die UAP das Abzielen auf eine bestimmte Gruppe und Version von APIs ist.
Wichtig ist der Hinweis, dass Sie Windows-Apps und -Spiele mit den Tools und Technologien entwickeln, die Sie bereits kennen. In verwalteten Sprachen geschriebene Windows-Apps nutzen weiterhin Microsoft .NET Framework, das seinerseits nur eine Sammlung von Schnittstellen, Basisklassen und Hilfsmethoden ist. Die Teilmenge des vollständigen .NET Framework, die in verwalteten Anwendungen für die UAP verwendet wird, heißt .NET Core. Ergänzend dazu befindet sich der Großteil der APIs, die Sie in Apps für die UAP verwenden, in der Windows-Runtime, die sich auf alle Sprachen und nicht nur die verwalteten Sprachen erstreckt.
Es ist nicht nur XAML In diesem Artikel wird eine XAML-Anwendung vorgestellt, doch DirectX- und JavaScript-Apps (Windows-Web-Apps) werden auch wie schon unter Windows 8 von der UAP unterstützt. Vor diesem Hintergrund ist es faszinierend, einen Blick auf das neue XAML-Szenario zu werfen. XAML ist wichtig für viele Microsoft-Plattformen – Windows Presentation Foundation (WPF), Silverlight im Browser und unter Windows Phone und jetzt auf der Benutzeroberflächenplattform von Windows (die anfangs den Codenamen "Jupiter" hatte).
Microsoft Office 2016 ist nun eine Familie von UAP-Anwendungen. Welche Benutzeroberflächentechnologie wird verwendet? XAML. Dank dieser Beziehung bietet die XAML-Plattform zahlreiche Features und Steuerelemente, die von Microsoft-Entwicklern und Entwicklern wie Ihnen in Windows-Anwendungen verwendet werden können.
Die Windows-Desktopshell stellt viele neue Features bereit, z. B. das Startmenü und das Wartungscenter. Welche Benutzeroberflächentechnologie wird verwendet? XAML. Dank dieser Beziehung ist die XAML-Plattform überaus leistungsfähig und bietet superschnelle Rendermöglichkeiten, die Sie nutzen können.
Wenn es um XAML geht, hat Microsoft alles zu bieten. Viele wichtige Betriebssystem-Apps wie "Fotos" und MSN-Apps wie "Gesundheit & Fitness" setzen auf der XAML-UI-Plattform auf, um die gleichen umfassenden Features zu bieten, die jeder Entwickler in seinen Windows-Anwendungen nutzen kann. Was Sie in Microsoft-Anwendungen sehen, können Sie auch. Nicht nur die API-Oberfläche ist für alle Benutzer gleich, sondern auch die XAML-UI-Plattform.
Nutzen für Softwareentwickler Es reicht nicht aus, eine App schreiben, die auf jedem Gerät ausgeführt werden kann. Um Benutzern einen echten Nutzen zu bieten, muss Ihre Windows-App auf verschiedenen Geräten zünden. Dank der Erweiterbarkeit der UAP können Sie gerätespezifischen Code in eine einzelne Binärdatei einschließen, die auf jedem Gerät ausgeführt werden kann.
Sie erhalten mit der UAP mehr als eine einzige Binärdatei, denn Sie bekommen auch einen Store für alles – für Smartphone-, Tablet-, Desktop- und sogar Xbox-Anwendungen. Die Umgebung wird vereinfacht, die Monetarisierung wird vereinfacht, und auch die Metriken zur Überwachung von Erfolg im Marketplace werden vereinfacht.
Dieser eine Store und die Plattform ermöglichen Ihnen, Ressourcen entsprechend bereitzustellen. Dies bedeutet, dass für die Xbox-Umgebung gedachte Objekte nicht per Push auf Smartphones übertragen werden. Und die Möglichkeit in Windows 8 zum Packen von Ressourcen für bestimmte Lösungen und Größen bleibt in der UAP erhalten.
Wie immer behalten Sie die Kontrolle. Nur weil die UAP alle Windows-Geräte unterstützt, bedeutet dies nicht, dass Sie das auch müssen. Sie bestimmen, welche Gerätefamilie Ihre Windows-App unterstützen soll. Ob Ihre Windows-App nur für Smartphones, die Xbox oder HoloLens ausgelegt ist, liegt ganz bei Ihnen. Der Windows Store stellt sicher, dass Ihre App an die Gerätefamilien übermittelt wird, die Sie auswählen.
Der Nutzen für Sie ist nicht nur eine breitere Benutzerbasis, sondern auch ein einfachere allgemeine Erfahrung. Es gibt einen Satz von Tools, einschließlich Visual Studio und Blend für Visual Studio, die Sie bereits kennen und schätzen. Es gibt eine Reihe vertrauter Sprachen, einschließlich JavaScript, .NET Framework (Visual Basic oder C#) und C++/CX. Letztlich erstellen Sie und Ihr Team Windows-Apps mit Tools, die Sie bereits kennen.
Zahlreiche zu berücksichtigende Aspekte
Mit großer Macht kommt auch große Verantwortung. Die UAP ermöglicht die Ausführung von Windows-Apps auf allen Arten von Windows-Geräten. Das ist zwar toll, aber auch mit Vorsicht zu genießen, denn nicht jedes Gerät bietet die gleiche Benutzererfahrung. Das bedeutet, dass obgleich Sie viele der RWD-Techniken (Responsive Web Design) einsetzen können, die Sie in Ihren Webanwendungen nutzen, Sie gründlich durchdenken müssen, wie der Workflow Ihrer Windows-App auf den verschiedenen Gerätetypen umgesetzt wird, die für verschiedene Zwecke gedacht sind. Die UAP kann nur die Unterstützung auf verschiedenen Geräten ermöglichen. Es ist Aufgabe des Entwicklers und Designers, eine Benutzererfahrung zu entwickeln, die auf allen Geräten überzeugend ist.
Microsoft bietet zahlreiche Tools, die das Entwickeln reaktionsfähiger und adaptiver Windows-Apps unterstützen. In Visual Studio können Seitenverhältnis, Skalierung und Größe während der Entwurfszeit simuliert werden. Visual Studio kann auch bestimmte Zielgeräte simulieren (und mitunter emulieren), selbst wenn Sie die Hardware nicht besitzen. Auf diese Weise können Sie Windows-Apps testen und Ihre Lösungen nebenher optimieren.
Die XAML-Toolbox bietet mehrere neue Steuerelemente und Verbesserungen, die Ihnen helfen, reaktionsfähige und adaptive Oberflächen zu erstellen, die auf jedem Gerät und bei jeder Bildschirmgröße hervorragend aussehen. "RelativePanel" ist beispielsweise für XAML-Entwickler neu. Das Steuerelement erbt von "Panel" wie jedes andere Layoutsteuerelement, wie z. B. "Grid" und "StackPanel", ermöglicht aber Designern und Entwicklern das Positionieren untergeordneter Elemente relativ zu anderen untergeordneten Elementen. Die resultierende visuelle XAML-Struktur lässt sich einfacher rendern und als Reaktion auf Änderungen am Layout wesentlich einfacher ändern. Visuelle Zustände sind eine weitere Verbesserung für XAML-Entwickler, die eine Reaktion auf Änderungen am Layout erleichtern.
Dies ist wichtig: Das Erstellen einer Windows-Anwendung für mehrere Geräte steht nicht für das Schreiben von Code mit dem kleinsten gemeinsamen Nenner. Die Benutzeroberfläche ist vielfältig und umfangreich, was auch für das Featureangebot gilt. Die Laufzeitüberprüfung (mit dem Namespace "Windows.Foundation.Metadata.ApiInformation") ermöglicht Ihnen das Einschließen gerätespezifischer Funktionen, die dafür sorgen, dass Ihre Apps auf jedem Gerät die bestmögliche Benutzererfahrung bieten. Neue Features und zusammengeführte Steuerelemente sind die Bausteine, die Sie brauchen, um groß zu denken.
Anatomie einer Windows-App
Lassen Sie uns nun einen Blick auf die grundlegenden Techniken für das Entwickeln einer Windows-Anwendung werfen, die auf allen Gerätefamilien ausgeführt werden kann. Wir gehen davon aus, dass Sie mit der Entwicklung von Windows 8.1 Windows Runtime (WinRT) XAML-Apps vertraut sind. Windows-Apps sind die Weiterentwicklung dieser Anwendungen. In der Microsoft Virtual Academy finden Sie unter aka.ms/w8learn zahlreiche Lernressourcen. Dieser Artikel konzentriert sich auf die neuen Features der UAP für die Ausführung von Windows-Apps auf allen Gerätefamilien.
In Visual Studio 2015 enthält der Knoten "Templates/Visual C#/Windows Universal" im Dialogfeld "Neues Projekt" mehrere Projektvorlagen: "Leere App", "Klassenbibliothek" und "Komponente für Windows-Runtime". Zum Erstellen einer Windows-Anwendung verwenden Sie die Vorlage "Leere App". Die Vorlagen "Klassenbibliothek" und "Komponente für Windows-Runtime" können Sie zum Kapseln der Benutzeroberfläche und Logik für die Wiederverwendung in anderen Projekten nutzen. Eine Klassenbibliothek unterstützt Nicht-UAP-Apps, ist jedoch auf verwaltete Sprachen beschränkt. Komponenten für Windows-Runtime können von mehreren Sprachen gemeinsam genutzt werden (einschließlich JavaScript und C++/CX), weisen aber Regeln auf, die ihre öffentliche API-Oberfläche einschränken.
Wählen Sie für dieses Beispiel "Leere App" (siehe Abbildung 2).
.jpg "Für Windows-Apps wird jetzt standardmäßig die Vorlage \"Leere App\" verwendet")
Abbildung 2: Für Windows-Apps wird jetzt standardmäßig die Vorlage "Leere App" verwendet
Wo sind all die anderen Vorlagen? Nehmen wir die Vorlage "Hub-App" im Funktionsumfang von Windows 8, die von viele Entwicklern verwendet und kopiert wurde. Diese Flut gleichartiger Apps hat für visuelle Konsistenz im Windows Store gesorgt, aber nicht zur Vielfalt des Ökosystems beitragen. Jetzt steht die Vorlage "Leere App" im Mittelpunkt, die fördert, dass Entwickler visuell konsistente und doch unterschiedliche Oberflächen auf der Plattform erstellen. Viele Vorlagen aus der Community sind bereits im Visual Studio-Katalog vorhanden, einschließlich der Vorlage "Template10", die von den Autoren dieses Artikels geschrieben wurde.
Hello World! Sie haben Ihre erste Windows-App erstellt. Obwohl die Benutzeroberfläche leer ist, kann sie bereits auf jedem Windows-Gerät ausgeführt werden. Der Projektmappen-Explorer von Visual Studio enthüllt, wie einfach eine einfache Windows-App aufgebaut ist, die aus einem einzelnen Projekt mit der Datei "App.xaml" und einer einzelnen Datei "MainPage.xaml" für die anfängliche Benutzeroberfläche besteht.
Ihre Lösung umfasst andere vertraute Unterstützungsdateien. Die Datei "Package.appxmanifest" deklariert die Funktionen, die die App vom Computer des Benutzers anfordert, z. B. den Standort des Benutzers und den Zugriff auf Kamera und Dateisystem. Das XML-Schema wurde erweitert, ist aber ungefähr mit der "Appxmanifest"-Datei für universelle Windows 8.1-Apps identisch.
Wo sind die beiden Kopfteile? Universelle Windows 8-Apps erforderten sowohl ein "Phone"- als auch ein "Windows"-Kopfteilprojekt. Die UAP erfordert nicht mehr mehrere Kopfteile. Stattdessen passen Sie Ihre Oberflächen entsprechend der Ausführungsumgebung Ihrer Windows-Anwendung an. Wenn es jedoch dem Workflow Ihres Entwicklungsteams entspricht, können Sie nach Wunsch dennoch eine Lösung mit mehreren Kopfzeilen entwickeln. Beide Ansätze werden gleichermaßen unterstützt.
Einschließen von Inhalten Wenn Sie "MainPage.Xaml" öffnen, sehen Sie die verbesserte Visual Studio-XAML-Entwurfszeitumgebung. Der Designer ist umfangreicher und schneller, die Fähigkeit zur Simulation von Seitenverhältnis und Skalierung wurde verbessert, und das Toolset selbst wurde erweitert. Lassen Sie uns nun ein wenig XAML hinzufügen (siehe Abbildung 3). (Wir bedanken uns bei unserem Kollegen David Crawford für dieses Beispiel).
Abbildung 3. "RelativePanel" ermöglicht das einfache Gestalten des Layouts der Benutzeroberfläche
<Grid Background="{StaticResource EggshellBrush}">
<RelativePanel x:Name="PromoArea">
<Image x:Name="BannerImage" HorizontalAlignment="Right"
Height="280" Stretch="UniformToFill"
Source="Assets/clouds.png"
RelativePanel.AlignRightWithPanel="True"/>
<Grid x:Name="BannerText" Margin="24"
Background="{StaticResource BlueBrush}">
<StackPanel Margin="12" HorizontalAlignment="Stretch">
<TextBlock x:Name="Headline" Text="Come fly with us"
Margin="0,-32,0,0" FontSize="48"
Foreground="{StaticResource EggshellBrush}"
FontFamily="{StaticResource LustScriptFont}" />
<TextBlock x:Name="Subtitle" FontSize="21.333"
Foreground="{StaticResource EggshellBrush}"
FontFamily="{StaticResource DomusTitlingFont}">
<Run Text="Fly return to London"/>
<LineBreak/>
<Run Text="For only $800"/>
</TextBlock>
</StackPanel>
</Grid>
</RelativePanel>
</Grid>
Der Code in Abbildung 3 erstellt die Kopfzeile einer einfachen Anwendung für eine fiktive Fluggesellschaft. Verwendet wird hier insbesondere das neue XAML-Feature "RelativePanel", mit dem Sie die Oberfläche auf einfache Weise neu anordnen können. "RelativePanel" positioniert die Bannergrafik rechts auf der Seite und enthält das Raster mit den aktuellen Sonderangeboten der Fluggesellschaft.
Hinzufügen einiger Ressourcen Die XAML verweist auf drei Dateien, die wir dem Ordner "Assets" hinzugefügt haben: die Bilddatei, "Clouds.png", und zwei benutzerdefinierte Schriftarten, "DomusTitlingFont.ttf" und "LustScriptFont.ttf". Die Schriftarten und benutzerdefinierten Pinselressourcen werden in der Datei "App.xaml" deklariert:
<Application.Resources>
<SolidColorBrush x:Key="BlueBrush" Color="#FF1C90D1"/>
<SolidColorBrush x:Key="EggshellBrush" Color="#FFFAFFF7"/>
<FontFamily x:Key="LustScriptFont">
Assets/Fonts/LustScriptDisplay.otf#Lust Script Display
</FontFamily>
<FontFamily x:Key="DomusTitlingFont">
Assets/Fonts/DomusTitling.otf#Domus Titling
</FontFamily>
</Application.Resources>
Diese Dateien sind im Codedownload enthalten, der diesen Artikel begleitet.
Beachten Sie, dass das Bitmapbild eine bestimmte Skalierung hat. Wenn Sie Geräte mit höherer Auflösung unterstützen möchten, können Sie Ihre Ressourcen skalieren und sie mit dem entsprechenden Skalierungsfaktor benennen, damit jeder Benutzer die beste visuelle Erfahrung erhält, ohne Ressourcen für andere Skalierungsfaktoren herunterladen zu müssen.
Ausführung auf Geräten Zurück in "MainPage.xaml" nimmt die Benutzeroberfläche Form an. Um die Anwendung auszuführen, können Sie das Ziel in der Visual Studio-Dropdownliste für das Zielgerät auswählen. Die enthaltenen Optionen sind "Windows Simulator" (zum Testen des Touchverhaltens), "Lokaler Computer", "Remotecomputer" (zum Testen von ARM) und "Gerät" (reale Telefonhardware). Die Phone-Emulatoren sind in derselben Liste enthalten. Sie können für die Ausführung erst "Lokaler Computer" und danach einen der Phone-Emulatoren auswählen, um zu prüfen, wie Ihre Windows-App ohne besondere Kompilierungen auf verschiedenen Geräten läuft.
Vielleicht haben Sie bemerkt, dass die Ausführung einer Windows-App auf dem lokalen Computer, also auf dem Desktop Ihres PC, im Fenstermodus und nicht im Vollbildmodus von Windows 8 erfolgt. Der Grund ist, dass Sie Ihre Anwendung auf der Desktop-SKU von Windows 10 ausführen. Die mobile SKU von Windows 10 startet Windows-Apps weiterhin im Vollbildmodus, um die Touchnavigation einfacher zu machen. Die Desktop-SKU von Windows 10 startet Windows-Apps jedoch auch im Vollbildmodus, wenn Sie auf einem Tablet oder 2-in-1-Gerät auf der Oberfläche "Continuum" die Touchumgebung wählen.
Adaptive Oberflächen Obwohl die Windows-App auf beiden Geräten ausgeführt wird, ist bei genauer Betrachtung die Benutzeroberfläche auf dem kleineren Bildschirm des Telefons nicht besonders beeindruckend. Der Text der Kopfzeile ist zu groß für den kleinen Bildschirm und abgeschnitten. Dies ist der Anfang einer längeren Testphase zum Verbessern die Benutzererfahrung auf verschiedenen möglichen Geräten für diese Windows-App.
Wir ändern das Layout der Kopfzeile, sobald der schmalere Bildschirm des Telefons erkannt wird. Wichtig ist jedoch der Hinweis, dass nicht das Telefon, sondern die Breite des Bildschirms erkannt wird. Dies ermöglicht eine schmalere Umgebung auf dem Desktop und dem Telefon.
Beachten Sie, dass es keine API zum Erkennen eines Telefons gibt. Sollte Ihr Entwurf jedoch den für Telefone und kleinere Tablets spezifischen einhändigen Betrieb erfordern, können Sie in einem benutzerdefinierten Trigger vom Typ "Visueller Zustand" die Diagonale des physischen Geräts testen (was in diesem Artikel nicht behandelt wird).
Visuelle Zustände sind nichts Neues in XAML. Der Visual State-Manager ermöglicht Entwicklern und Designern das Definieren verschiedener visueller Zustände (d. h. unterschiedlicher Bildschirmlayouts), zwischen denen zur Laufzeit gewechselt werden kann. Adaptive Trigger für den visuellen Zustand sind neu für die UAP. Sie lösen den programmgesteuerten Ansatz zum Wechseln visueller Zustände ab. Sie deklarieren stattdessen, wann ein visueller Zustand in XAML angezeigt werden soll, und die zugrunde liegende Plattform erledigt den Rest.
Ändern Sie nun die XAML in "MainPage.XAML" (siehe Abbildung 4).
Abbildung 4: XAML unterstützt jetzt das Deklarieren von Regeln für die Anpassung einer Oberfläche
<Grid Background="{StaticResource EggshellBrush}">
<VisualStateManager.VisualStateGroups>
<VisualStateGroup x:Name="WindowStates">
<VisualState x:Name="NarrowState">
<VisualState.StateTriggers>
<AdaptiveTrigger MinWindowWidth="1"/>
</VisualState.StateTriggers>
<VisualState.Setters>
<Setter Target="BannerImage.Height" Value="120"/>
<Setter Target="BannerText.(RelativePanel.Below)"
Value="BannerImage"/>
<Setter Target="BannerText.Width" Value="660"/>
<Setter Target="BannerText.Margin" Value="0,0,0,24"/>
<Setter Target="Headline.FontSize" Value="28"/>
<Setter Target="Subtitle.FontSize" Value="12"/>
</VisualState.Setters>
</VisualState>
<VisualState x:Name="MediumState">
<VisualState.StateTriggers>
<AdaptiveTrigger MinWindowWidth="660"/>
</VisualState.StateTriggers>
<VisualState.Setters>
<Setter Target="BannerImage.Height" Value="180" />
<Setter Target="BannerText.(RelativePanel.AlignTopWith)"
Value="BannerImage"/>
<Setter Target="Headline.FontSize" Value="28"/>
<Setter Target="Subtitle.FontSize" Value="14"/>
</VisualState.Setters>
</VisualState>
<VisualState x:Name="WideState">
<VisualState.StateTriggers>
<AdaptiveTrigger MinWindowWidth="1000"/>
</VisualState.StateTriggers>
<VisualState.Setters>
<Setter Target="BannerText.(RelativePanel.AlignTopWith)"
Value="BannerImage"/>
</VisualState.Setters>
</VisualState>
</VisualStateGroup>
</VisualStateManager.VisualStateGroups>
<RelativePanel...
Wie Abbildung 4 zeigt, sind drei visuelle Zustände deklariert: NarrowState, WideState und MediumState. Jeder dieser visuellen Zustände entspricht verschiedenen Bereichen der Bildschirmbreite. Sie können entsprechend den zu unterstützenden Zielgerätfamilien beliebig viele oder wenige visuelle Zustände erstellen. Die Namen der einzelnen visuellen Zustände haben keine Bedeutung.
Der XAML-Code veranschaulicht außerdem Visual State Setter, die neu für die UAP sind und mit denen Sie einen separaten Eigenschaftswert ohne den Aufwand einer Storyboard-Animation festlegen können. Hier verwenden wir Setter zum Ändern der relativen Position der untergeordneten Elemente in "RelativePanel" durch Festlegen der angefügten Eigenschaft "RelativePanel" für die untergeordneten Elemente. Zudem ändern wir auch die Höhe der Bannergrafik ("BannerImage") und den Schriftgrad ("FontSize") von Textelementen. Nach Festlegen der visuellen Zustände passt sich die Oberfläche sehr gut an einen schmaleren Bildschirm an. Probieren Sie es aus!
Abbildung 5 zeigt, wie sich die Benutzeroberfläche an Änderungen der Bildschirmbreite anpasst. In Ihrer Windows-App können Sie Trigger für den visuellen Zustand nutzen, um Elemente optimal für Ihre Benutzer anzupassen.
.jpg "Anpassung an Änderungen der Bildschirmbreite")
Abbildung 5: Anpassung an Änderungen der Bildschirmbreite
In der vollständigen Version dieses Beispiels, das im diesen Artikel begleitenden Codedownload enthalten ist, wird die Benutzeroberfläche weiter entwickelt. Außerdem werden weitere Beispiele zur Verwendung von "RelativePanel" und Trigger für den visuellen Zustand geboten, um eine adaptive Benutzeroberfläche zu implementieren.
Adaptiver Code Die Benutzeroberfläche passt sich an verschiedene Bildschirme an, aber Geräteunterschiede sind nicht allein auf die Bildschirmgröße begrenzt. Smartphones haben beispielsweise Hardwaretasten wie "Zurück" und "Kamera", die ggf. auf einer anderen Plattform, wie z. B. einem PC, nicht vorhanden sind. In der Standardeinstellung bietet die UAP den Großteil der API-Oberfläche, den Windows-Apps benötigen. Gerätespezifische Funktionalität wird jedoch mithilfe von Erweiterungs-SDKs freigeschaltet, die Sie Ihren Projekten wie externe Assemblys hinzufügen (siehe Abbildung 6). Die SDKs ermöglichen eine umfassendere Palette an gerätespezifischen Funktionen, ohne Ihrer App die Möglichkeit zur Ausführung auf anderen Gerätetypen zu nehmen.
.jpg "Das Hinzufügen einer Erweiterung ist so einfach wie das Hinzufügen eines Projektverweises")
Abbildung 6: Das Hinzufügen einer Erweiterung ist so einfach wie das Hinzufügen eines Projektverweises
Die beiden am häufigsten verwendeten Plattformerweiterungs-SDKs sind die Erweiterungen "Desktop" und "Mobile", die für ihre jeweilige Windows-SKU besondere Funktionalität ermöglichen. Die Erweiterung "Mobile" aktiviert beispielsweise die APIs, die zum Verwenden der Hardwaretaste "Kamera" erforderlich sind.
Die Windows Mobile SKU kann auf Smartphones und kleinen Tablets ausgeführt werden. Nicht alle Tablets (und selbst nicht alle Telefone) haben jedoch eine Hardwaretaste "Kamera". Erweiterungs-SDKs ermöglichen die Unterstützung von Tasten, fügen dem Gerät aber keine Tasten hinzu. Daher müssen Sie zur Laufzeit Gerätefunktionen testen, bevor Sie die Funktionen im Erweiterungs-SDK aufrufen.
Ebenso wie Plattformerweiterungs-SDKs wie "Mobile" und "Desktop" die Funktionen von Geräten für Windows-Apps freischalten, fügen benutzerdefinierte Erweiterungs-SDKs Unterstützung für zusätzliche Komponenten hinzu, wie z. B. Kinect für Windows oder Hardware von Drittanbietern. Auch diese hindern Ihre App nicht an der Ausführung auf anderen Arten von Geräten.
Wie erfolgt das Überprüfen auf Gerätefunktionen? Sie nutzen die Methoden in der "Windows.Foundation.Metadata.ApiInformation"-Klasse, die einen einfachen booleschen Wert zurückgeben, wenn ein Typ oder eine Methode vom aktuellen Gerät unterstützt wird. Sie können Ihre Windows-App für das Verwenden der Taste "Kamera" mit Code wie dem folgendem aktivieren:
if (Windows.Foundation.Metadata.ApiInformation.IsTypePresent(
"Windows.Phone.UI.Input.HardwareButtons"))
{
Windows.Phone.UI.Input.HardwareButtons.CameraPressed +=
HardwareButtons_CameraPressed;
}
Beachten Sie hier, wie der Code "Windows.Phone.UI.Input.HardwareButtons" nur ausgeführt werden darf, wenn das Erweiterungs-SDK auf dem Gerät aktiviert ist. Im Gegensatz zu konditionellen Abschnitten für die Kompilierung führt das Überprüfen auf Funktionen nicht zu mehreren Binärdateien. Dadurch können Sie die Benutzererfahrung wie gewünscht entsprechend den Möglichkeiten des aktuellen Geräts anpassen. Dies ist ein überzeugender Ansatz zum Ermöglichen einer einzelnen Binärdatei, der Variabilität unbegrenzt zulässt, sodass Ihre Windows-Apps auf verschiedenen Gerätefamilien optimal genutzt werden können.
Zusammenfassung
Wenn Sie mit der Entwicklung universeller App unter Windows 8 vertraut sind, dann sollte das Entwickeln von Windows-Anwendungen für die UAP für Sie ein Kinderspiel sein. Windows-Apps werden nicht mit Windows 10, sondern mit der UAP als Ziel entwickelt, die von der Windows SKU entkoppelt ist. Die UAP erhöht Versionen mit einer von Windows getrennten Kadenz. Dies bedeutet, dass Windows-Apps nicht jedes Mal neu zugewiesen werden müssen, wenn das Windows-Betriebssystem umgestellt wird. Windows-Apps zielen auf eine oder mehrere UAP Versionen ab und testen auf diese Funktionen wie sie auch auf Gerätefunktionen testen. Dieser flexible Ansatz bietet Ihnen eine gute, saubere Möglichkeit, künftige Funktionen zu nutzen.
Das Entwickeln einer Windows-App bedeutet, dass Ihre App auf jedem Windows-Gerät ausgeführt werden kann. Bei diesem Vorteil gibt es allerdings einen praktischen Vorbehalt: Die UAP kann Ihre Anwendung ausführen, aber nur Entwickler und Designer können die Benutzeroberfläche und den Code so anpassen, dass die bestmögliche Benutzererfahrung geboten wird. Nach Wunsch können Sie separate gerätespezifische Binärdateien erstellen. Doch sollten Sie eine Windows-App erstellen, die mehrere Gerätetypen unterstützt, sind alle Tools und die gesamte Infrastruktur einsatzbereit, um Ihren zum Erfolg zu verhelfen.
Jerry Nixon ist eine Entwickler-Koryphäe von Microsoft aus Colorado. Nixon ist Dozent und Referent für die Windows-, Telefon- und Desktop-Entwicklung. Seine Laufbahn begann mit Microsoft SQL Server 6.5 und der Entwicklung datenorientierter Lösungen, als "Datenbankentwickler" noch ein neuartiger Begriff war. Er wurde für seine Arbeit im Bereich Sicherheit mit dem zivilen Naval Commendation-Orden ausgezeichnet und arbeitete zuvor für das Start-up, aus dem Microsoft CRM werden sollte. Seit 15 Jahren entwickelt Nixon mobile Lösungen auf Microsoft-Basis. Heute ist er Referent für XAML und mobile Lösungen bei Veranstaltungen, in Communitys und an Universitäten. Den Großteil seiner Zeit verbringt er damit, seinen drei Töchtern Hintergrundgeschichten zu Star Trek-Charakteren und Handlungen der einzelnen Episoden näher zu bringen.
Andy Wigley ist eine Entwickler-Koryphäe von Microsoft aus Großbritannien. Er kam 2012 zu Microsoft. Zuvor hat als er Berater gearbeitet und war prominentes Mitglied der Entwicklercommunity für mobile Anwendungen. Er war stolz darauf, 10 aufeinander folgende Jahren zu einem Microsoft Most Valuable Professional (MVP) ernannt zu werden. Wigley ist bekannt für die beliebten Windows Phone JumpStart-Videos auf channel9.msdn.com und freut sich, mit Jerry Nixon an einer Folgereihe zur Entwicklung von Windows-Apps zu arbeiten.