Windows Phone 8.1 Development: So viele Möglichkeiten–Welche ist die Richtige für mich?

  • Article

Ihr wisst bereits, dass wir seit der Ankündigung von Windows 8.1 einige neue Templates für Windows Phone App Entwicklung dazubekommen haben. Sobald ich das Update 2 von Visual Studio 2013 installiert habe, habe ich die neuen Project Templates für Phone Apps dabei. Der Gedanke ist einfach: Wir unterstützen eine Menge von Szenarien, und ihr habt die Wahl, euch das Passende für euren Fall auszusuchen. Für jemanden, der noch nie für Windows Phone entwickelt hat, kann diese Wahl mitunter ein bißchen verwirrend sein, vor allem da es keine allgemeine Empfehlung gibt. Deswegen haben wir für euch diese kleine Entscheidungshilfe zusammengestellt, damit ihr euch leichter tut, für euren Fall das passende Modell zu finden.

Im Prinzip müssen wir uns drei Fragen stellen:

  • Welche Windows Phone Version soll unterstützt werden?
  • In welcher Programmiersprache möchte ich entwickeln?
  • Was möchte ich in meiner App unterstützen?

Windows Phone Version

Bevor wir überhaupt an die Programmiersprache denken, müssen wir natürlich entscheiden, ob wir eine Windows Phone 8.0 oder Windows Phone 8.1 App entwickeln wollen. Alle Windows Phone 7.x/8.0 Apps laufen auch auf Windows Phone 8.1. Eine Windows Phone 8.1 ist nicht abwärtskompatibel. Das heißt, dass sie nur auf Windows Phone 8.1 laufen wird. Will ich aber ein Feature in meine App einbauen, das es erst seit Windows Phone 8.1 gibt, dann werde ich eine Windows Phone 8.1 App schreiben. Es spricht natürlich nichts dagegen, zwei Versionen (zb WP 8.0 und WP 8.1) im Store zu haben. Dann wird die passende Version dem Benutzer automatisch angeboten.

Programmiersprachen

Zuerst müssen wir uns einmal anschauen, in welchen Programmiersprachen ich eine Windows Phone App überhaupt entwickeln kann. Mit Windows Phone 8.1 gibt es folgende Optionen:

image

Für Spieleentwickler ist vor allem die erste Variante interessant. Wenn ich mit DirectX oder Direct3D arbeiten will, kann ich die DirectX Templates mit C++ wählen. Es gibt hier dann wiederum mehrere Vorlagen. Auch hier steht mir dann zur Wahl, ob ich eine App für WP 8.0 oder WP 8.1 targeten möchte. Weiters kann ich noch auswählen, ob mein UI auf WinRT XAML basierend oder Silverlight XAML basierend sein soll. Das werden wir im Folgenden noch klären.

Wenn ich Webentwickler bin, dann wähle ich die HTML Variante. Jetzt haben wir ja eine viel bessere Story, was Entwicklung mit Webtechnologien betrifft. Bisher, also auf Phone 8.0, habe ich mich innerhalb eines WebBrowser Control bewegt. Seit 8.1 haben wir nun endlich die Möglichkeit auch WinJS auf Windows Phone zu verwenden und damit den Phone Apps zu schreiben, die sich auch native zur Plattform anfühlen. WinJS ist die Windows Library für JavaScript, die es vor dieser Release nur für Windows Store Apps gab. Mit dieser Library kann ich Dinge wie Controls, Animationen, etc in meine App einbauen, die auch dieselbe Performance haben, wie Apps, die in .Net entwickelt wurden.

Und somit kommen wir auch gleich zur nächsten Variante. Wenn ich meine Apps in .Net schreiben will, stehen mir zwei Optionen offen: das UI mit WinRT XAML, das es seit 8.1 auf Windows Phone gibt oder ich verwende das XAML Silverlight, wie ich es schon von Windows Phone 7.x kenne. Wenn ich eine Silverlight App wähle, verwende ich die APIs, die es für Silverlight gibt. Alle 8.0 APIs funktionieren hier noch und für die neuen 8.1 Features sind noch einige APIs dazugekommen. Für die auf der Windows Runtime basierenden Apps gibt es das Universal App Template mit dem ich sehr viel gemeinsamen Code für Windows Store Apps und Windows Phone 8.1 Apps schreiben kann. Wenn ich hier rein von der Programmiersprache her eine Wahl treffen muss, dann habe ich mit bestehenden Phone Development Skills in Silverlight Apps die kleinere Lernkurve. Wenn ich eher von der Windows Store Development Ecke komme, dann ist das Programmiermodell mit WinRT XAML das bessere für mich. Aber bevor ihr euch jetzt festlegt, müsst ihr auch noch auf euren spezifischen Fall ein Auge werfen und sehen, ob der Anwendungsfall Requirements hat, die nur mit einem bestimmten Modell abgedeckt werden können.

Anwendungsfall

Bei all den oben genannten Möglichkeiten, ist es schwer eine generelle Empfehlung abzugeben. Je nach Fall kann mal das eine Modell optimal sein und ein anderes Mal ein anderes. Ich will daher nur einige grundlegenden Punkte anbringen, die ihr bei eurer Entscheidung bedenken und selbst abwiegen müsst, wo ihr die Prioritäten für euer Projekt seht.

  • Wenn ich eine bestehende Windows Phone 8.0 App habe, kann ich sie auf Silverlight 8.1 upgraden und habe dann auch Zugang zu den neuen 8.1 Features. Der Schritt von WP Silverlight 8.0 App auf WinRT 8.1 App ist aber nicht so trivial, da ich hier neue Namespaces und APIs verwende und im Code einige Anpassungen durchführen muss.
  • Wenn ich eine bestehende Windows Store App habe, kann ich eine Universal App kreieren und eine Phone App hinzufügen und großteils den Codes der Store App für die Phone App wiederverwenden, indem ich den Code in das Shared Project hineingebe.
  • Wenn ich eine neue Windows Phone App schreiben will, muss ich abwiegen, ob ich abwärtskompatibel (dh Phone 8.0 und Phone 8.1 App) sein will oder ob ich gemeinsam eine Windows Phone und Windows Store App entwickeln will. Für den ersteren Fall (abwärtskompatibel) habe ich größeren Code Reuse mit dem Silverlight Template. Für gemeinsame Entwicklung von Store Apps und Phone Apps empfiehlt sich, die Windows Runtime Templates (Universal Apps) zu verwenden. Natürlich sind diese Fälle nicht ausschließend. Es ist möglich, dass ich eine Phone 8.0, Phone 8.1 und Windows Store App gleichzeitig baue. Nur gibt es dafür dein vorgefertigtes Template und ich muss mir dann selbst überlegen, wie ich für die Projekte so viel wie möglich gemeinsam verwende (ein Pattern wie MVVM ist hier sehr hilfreich, um Daten von der Logik und der Ansicht zu trennen).
  • Letztendlich gibt es noch einige Silverlight APIs, die noch nicht auf WinRT umgesetzt wurden. Das heißt, wenn ich eine App bauen will, die genau eine dieser APIs benötigt, dann wähle ich eine Silverlight App:
    • CameraCaptureTask
    • Camera Lenses
    • Lockscreen Background Image Provider
    • Runs under Lock
    • Background Audio Agent
    • Alarms/Reminders
    • SocialRT (nur auf Silverlight 8.1)
    • VoIP
    • Continuous background location tracking
    • Wallet agents