Wie funktionieren Universal Apps?

Know-how  –  5 Kommentare

"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.

Universal Windows Apps teilen sich die gleiche App-Identität im Windows- und im Windows Phone Store (Abb. 1)

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.

Um das Entwickeln einer Universal App zu vereinfachen, bietet Visual Studio 2013 ab dem Update 2 diverse Projektvorlagen (Abb. 2).

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.

Alle Elemente, die in beiden Projekten verwendet werden, finden sich im Shared-Projekt (Abb. 3)


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.

Fazit

Für existierende Apps einfach ein neues Projekt hinzufügen

Wer bereits eine App für eine der Plattformen in petto hat, fügt einfach ein neues Projekt für die jeweils andere Plattform hinzu. Dazu muss man in der Projektmappe mit der rechten Maustaste auf das entsprechende Projekt klicken und im Kontextmenü den Punkt Add Windows 8.1 oder Add Windows Phone 8.1 auswählen. Daraufhin erscheinen in der Projektmappe ein Windows- oder WP- sowie ein Shared-Projekt. Zu teilende Dateien müssen Entwickler von Hand in das Shared-Projekt verschieben.

Der Umbau einer Windows- oder WP-Anwendung zu einer Universal App funktioniert auch im Praxistest: Die Entwickler der H&D International Group haben beispielsweise den eigenen Mobile Incident Manager (MIM) auf WP 8.1 portiert. MIM unterstützt "Supporter" im Vor-Ort-Einsatz bei der Ticket-Bearbeitung auf mobilen Endgeräten. Bei der Portierung der reinen Windows-8.1-Anwendung zu einer Universal App konnten die Entwickler 90 Prozent der Codes übernehmen, sodass nur kleine Justierungen notwendig waren. Windows Store Apps sind für den universellen Windows-Einsatz also nicht mehr komplett neu zu entwickeln, eine einfache Anpassung reicht in den meisten Fällen aus. Das macht es für Unternehmen möglich, nicht nur attraktive Apps einzusetzen, sondern begünstigt auch die langfristige Nutzung dieser mobilen Applikationen. Denn Entwickler müssen weniger Zeit in die Logik stecken und können mehr Zeit investieren, die UI wirklich für die Gerätegröße zu optimieren.

Wer eine existierende App für eine der Plattformen hat, fügt ganz einfach ein neues Projekt für die jeweils andere Plattform hinzu (Abb. 4).

Fazit

Universal Apps sind aus Kundensicht eine feine Sache: Man muss eine App nur noch einmal bezahlen und kann sie auf verschiedenen Plattformen benutzen – wobei sich hier derzeit nur von Windows Phone und Windows sprechen lässt. Mit Windows Phone 8.1 hat Microsoft seine Ankündigung des Zusammenwachsens der Plattformen eingelöst. Aus Entwicklersicht ist mit den neuen Funktionen eine Steigerung der Produktivität verbunden. Für den Unternehmenseinsatz lassen sich ebenfalls Vorteile ausmachen: Die parallele Entwicklung von Desktop-, Tablet- und Smartphone-Apps für die Windows-Plattform spart nicht nur Entwicklungskosten, sondern verkürzt auch die Entwicklungszeiten drastisch. Die Portierbarkeit von Windows-Anwendungen ist gewährleistet, sodass wichtige Geschäftsprozesse in der Regel einheitlich und mit vertretbarem Aufwand abzubilden sind.

Nicht so schön umgesetzt ist allerdings ein wesentliches Detail: Wer seine App pro Plattform bezahlt bekommen möchte, ist gezwungen, ihr unterschiedliche Namen zu geben. Ein Entscheidungsmechanismus wäre hier schön gewesen. Außerdem hat es Microsoft mit dem Begriff "Universal App" anfangs nicht so richtig geschafft zu verdeutlichen, dass es sich bei ihr um ein Windows-Store- und kein Visual-Studio-Feature handelt. Viele Entwickler gehen fälschlicherweise davon aus, dass sie eine Universal App bauen, weil sie das entsprechende Template verwenden.

Die neuen Shared-Projekte vereinfachen das Entwickeln für verschiedene Plattformen erheblich. Ihre Stärke kommt aber erst richtig zur Geltung, wenn man Cross-Platform-Apps auch für iOS und Android mit Xamarin entwickelt: Einfach gesprochen übersetzt Xamarin C#-Code in native Apps. Auf diese Weise verwenden Entwickler Code über Plattformgrenzen hinweg. Die Unterstützung von Drittanbieter-Tools für Shared-Projekte lässt momentan noch ein bisschen zu wünschen übrig. Die Optimierung ist hier allerdings sicherlich nur eine Frage der Zeit.

Microsoft sollte seine "One Windows"-Philosophie weiter vertiefen: Derzeit wird für Windows und Windows Phone jeweils eine separate App beziehungsweise ein App-Package erstellt. Mit dem Release von Windows 10 wäre es schön, wenn es nur noch ein gemeinsames App-Package gäbe und die entsprechende Plattformlogik (Views, Styles ...) als App-Bundle nachgeladen würden. Die bisherigen Ankündigungen lassen das auch vermuten. Wahrscheinlich werden Entwickler zukünftig nur noch Universal Apps für Windows entwickeln. (ane)

Karim El Jed
ist Senior-Entwickler der H&D AppFactory.