Wie funktionieren Universal Apps?

Inhaltsverzeichnis

"One Windows" ist das erklärte Ziel von Microsoft. Ein wichtiger Meilenstein dazu sind die Universal Windows Apps. Allerdings bringt dieser Zwischenschritt zur neuen Philosophie nicht nur Vorteile. Ein kurzer Überblick, wie das Anlegen einer Universal Windows App funktioniert und welche Vor- und Nachteile Entwickler erwarten.

Microsoft realisiert die Vereinheitlichung aller Windows-Plattformen kontinuierlich. Am deutlichsten ist diese Entwicklung bisher bei Windows Phone zu sehen: Seit der Version 8.1 ist Windows Runtime (WinRT) auch für Microsofts mobiles Betriebssystem verfügbar. Die Schnittmenge der gleichen APIs zwischen Windows 8.1 und Windows Phone 8.1 ist zudem recht hoch, Tendenz steigend. Doch nicht nur technisch will Microsoft diese Plattformen zusammenwachsen lassen, sondern auch gedanklich. Im Zuge der fortschreitenden Zusammenlegung von Windows- und Windows Phone Store hat Microsoft die Universal Windows Apps eingeführt.

Lediglich den Formfaktor bestimmen

Die Idee dahinter ist, dass Anwender sich nicht mehr darum kümmern müssen, welche Plattform sie gerade nutzen. Sie bestimmen lediglich den gerade benötigten Formfaktor (Smartphone, Tablet, Desktop-PC, Fernseher etc.). Eine Universal App teilt sich die gleiche App-Identität im Windows- und im Windows Phone Store. Ein User kauft die App also nur einmal und nutzt sie dann auf verschiedenen Plattformen. Das gilt optional auch für In-App-Käufe – die Entscheidung liegt hier beim Herausgeber der App. In diesem Zuge hat Microsoft die Preisstrukturen im Windows Store angepasst. Zudem ist es möglich, Daten-Roaming zwischen den verschiedenen Geräten zu verwenden.

Endanwender erkennen Universal Apps in jeweiligen Stores anhand eines Icons. Reservieren Entwickler einen neuen App-Namen im Store, ist er automatisch auch für die andere Plattform vorgemerkt. Wer möchte, dass seine Kunden die App für das jeweilige System einzeln kaufen, muss zwangsläufig unterschiedliche Namen verwenden. Es gibt keine weitere Einstellung, um eine Universal App zu aktivieren oder zu deaktivieren.

Keine plattformübergreifende Applikation

Seit Visual Studio 2013 Update 2 lassen sich Universal Apps entwickeln. Das IDE-Update enthält unter dem Punkt Universal Apps diverse plattformübergreifende Templates, darunter auch eine Projektvorlage mit dem Namen Universal Windows App. Anders als es der Name vermuten lässt, funktioniert diese Vorlage jedoch nicht als autonome Applikation auf beiden Plattformen. Für jedes neue Projekt legt Visual Studio zusätzlich ein Windows-8.1-Store-, ein Windows-Phone-8.1- und ein sogenanntes Shared-Projekt an. Letzteres wird automatisch von den anderen beiden Projekten referenziert. Dadurch lässt sich pro Plattform eine Binärdatei durch Conditional Compiling generieren – eine wichtige Voraussetzung, ohne die Universal Apps nicht möglich wären. Während unter Windows WinRT als Basis vorhanden ist, nutzt Windows Phone (WP) die Variante Windows Phone Runtime (WinPRT). Dieser Unterschied bedingt bereits zwei Binaries.

Gesamt gesehen ist es allerdings vollkommen unerheblich, ob Entwickler eine Universal-App-Projektvorlage nutzen oder nicht. Sie müssen die damit entwickelten Anwendungen nicht als Universal App veröffentlichen. Auf der anderen Seite sind sie auch als Universal App herauszugeben, wenn sie ohne eine entsprechende Projektvorlage entwickelt wurden. Das hängt einzig und allein vom App-Namen ab. Abbildung 3 zeigt das Auswahlergebnis einer Hub App.

Typische Kandidaten für die Shared-Bibliotheken sind allgemeine Assets, Helper-Klassen, Konverter, Datenmodelle, View Models und Ressourcen. Alles,was Entwickler hier ablegen, stellt die Bibliothek beiden Apps zur Verfügung. Das hat den Vorteil, dass der verwendete Code nur einmal existiert. Auf diese Weise legen Entwickler Ressourcen fest, die auf beiden Plattformen zugänglich sind. Das Shared-Projekt ist für sich allein gesehen wertlos. Es ist nicht einzeln zu kompilieren wie eine Portable Class Library (PCL).

Wenn ein Shared-Projekt in einem App-Projekt referenziert wird, werden alle Dateien im Shared-Projekt so behandelt, als wären sie direkt im App-Projekt eingebunden. Im Prinzip verhält es sich so, als ob man jede einzelne Datei mit der Option "Add As Link" hinzugefügt hätte. Sie existiert physikalisch nur einmal, lässt sich aber in mehreren Projekten referenzieren.

Wie man in Abbildung 3 sieht, liegt auch die app.xaml im Shared-Projekt. Bei der Initiierung der App gibt es für die Windows- und WP-Version unterschiedliche Dinge zu berücksichtigen. Möchte man in einer Klasse in einem Shared-Projekt je nach Plattform unterschiedliche Logik verwenden, bieten sich Conditionals an. Je nach Plattform sind in den Projekteigenschaften die folgenden Conditional Symbols definiert: WINDOWS_PHONE_APP oder WINDOWS_APP.