Modern Apps

Richtiges Auswählen von Sprachen zum Entwickeln moderner Apps

Rachel Appel

Rachel AppelModerne Software wird in 2013 nicht mehr nur in einer einzelnen Sprache entwickelt. Die Programmierung ist zu einem polyglotten Modell mit domänenspezifischen Sprachen (Domain Specific Languages, DSLs) für jede Entwicklungsschicht geworden. Ein beliebtes Szenario ist zum Beispiel, SQL und C# für das Back-End und HTML, JavaScript und CSS als Benutzeroberflächensprachen zu verwenden. Als Entwickler möchten Sie Ihre Fähigkeiten gerne erweitern, aber durch die Arbeit mit zu vielen Sprachen können Sie sie in der einzelnen Sprache nicht ausgiebig vertiefen. Sie möchten die Produkte auch schnell auf den Markt bringen, wodurch oft wenig Zeit bleibt, eine neue Sprache und all ihre Eigenarten zu erlernen. Daher ist es am besten, wenn Sie auf den bereits vorhandenen Fähigkeiten aufbauen. Beim Entwickeln von Windows Store- und Windows Phone-Apps können Sie für jedes Projektszenario eine Auswahl aus einer Reihe von Sprachen treffen, und mindestens eine ist gut geeignet, um Ihre Erfahrung zu ergänzen. In diesem Artikel erläutere ich, welche Sprachen in verschiedenen Entwicklungsszenarios genutzt werden können. Außerdem beleuchte ich die abzuwägenden Optionen und gehe darauf ein, welche Auswirkungen Faktoren wie der Datenzugriff oder die Portierung einer App darauf haben, welche Sprache Sie verwenden müssen.

Die Sprachlandschaft moderner Apps

Zum Entwickeln von Windows Store-Apps sind die folgenden Sprachkombinationen verfügbar:

  • HTML, JavaScript und CSS
  • XAML und C# oder XAML und Visual Basic .NET
  • XAML und C++ oder DirectX und C++

Wenn Sie im Microsoft-Bereich entwickeln, sind Ihnen mindestens einige dieser Sprachen vertraut, und Webentwickler haben natürlich gute Kenntnisse in HTML und Co. Vernünftigerweise sind viele derselben Sprachkombinationen in der Windows Phone-Entwicklung verwendbar: XAML mit C#, Visual Basic .NET und C++.

Wie steht es mit HTML, JavaScript und CSS für Windows Phone? Zum Zeitpunkt dieses Artikels können Sie HTML in einer Windows Phone-App nur mithilfe eines WebView-Steuerelements schreiben; eine Technik, die normalerweise in hybriden Apps zur Anwendung kommt (halb Web-App, halb systemeigen).

Wenn Sie eine plattformübergreifende, systemeigene App (keine Website) außerhalb des Microsoft-Ökosystems erstellen, wandelt sich die Sprachlandschaft in die folgenden zwei Optionen:

  • Java für Android
  • Objective-C für iOS (technisch gibt es weitere Optionen, aber ich gehe hier nur auf Objective-C ein)

.NET- und Windows-Entwickler, die plattformübergreifende Apps schreiben möchten, haben glücklicherweise Xamarin zur Unterstützung. Es ist nicht notwendig, Java (obwohl es C# ziemlich ähnlich ist) oder die iOS-Entwicklungssprache Objective-C zu lernen (mehr dazu später).

Nachdem Sie jetzt eine gute Vorstellung davon haben, welche Sprachen verwendbar sind, erläutere ich, wie einfach oder schwer es ist, sich die jeweilige Sprache anzueignen.

Die Sprachlernkurve

Der Weg des geringsten Widerstands ist häufig der beste und mit Sicherheit der schnellste Weg, den Sie einschlagen können. Wenn Sie in neues Gebiet vordringen, ist eine wichtige Überlegung, mit welchen Sprachen Sie und Ihr Team vertraut sind. Der Übergang von einer Sprache in eine andere ist nicht für jeden problemlos zu vollziehen, was insbesondere für Sprachen gilt, die sich vollständig unterschiedlich verhalten. Für Entwickler, die noch keine langjährige Praxis haben, ist es schwieriger, da ihnen in der Regel die Erfahrung mit verschiedenen Sprachparadigmen fehlt. Sie machen daher häufiger Fehler oder sind sich der verbreiteten Fehlerquellen nicht bewusst. Sogar erfahrene Entwickler, die von einer kompilierten Sprache wie C# zu interpretiertem JavaScript wechseln, können auf viele Schwierigkeiten stoßen, da sie die Feinheiten der Sprache nicht realisieren, zum Beispiel das unterschiedliche Verhalten des this-Schlüsselworts, das Auftreten des Anhebens oder die unzähligen anderen JavaScript-Eigentümlichkeiten.

Webentwickler haben das Glück, mit demselben HTML, CSS und JavaScript wie in anderen Clientwebprojekten zu arbeiten. Der Unterschied beim Schreiben für Windows 8 besteht in der Ergänzung durch die Windows-Bibliothek für JavaScript (WinJS). Mit WinJS ist es einfach, systemeigene Apps unter Windows 8 mit Websprachen zu schreiben. Sie verwenden dieselben offenen Standard-APIs wie in der Webentwicklung, arbeiten aber zusätzlich mit Windows-spezifischen Bibliotheken, um auf die systemeigene Funktionalität zuzugreifen.

Entwickler, die an Websprachen gewöhnt sind, werden den Trick bei den HTML-Steuerelementen in Windows Store-Apps bemerken – es handelt sich einfach um Elemente, die mit data-win*-Attributen gekennzeichnet sind. Durch diese Attribute können der WinJS-Kerncode und etwas CSS diese Elemente in schöne Benutzeroberflächenwidgets transformieren, die vielseitige systemeigene Möglichkeiten bieten. Der WinJS-Code, der die Steuerelemente darstellt, enthält CSS-Regeln, die das Erscheinungsbild der modernen Windows 8-Benutzeroberfläche umsetzen. Der WinJS-Kerncode erstellt auch komplexere Steuerelemente wie eine Datumsauswahl und Raster zur Laufzeit, und er kann die Datenbindung von HTML-Elementen an JavaScript-Arrays oder -Objekte hinzufügen.

XAML-Entwickler aus den Windows Presentation Foundation(WPF)- und Silverlight-Lagern schreiben weiterhin denselben deklarativen XAML-Code für das Benutzeroberflächenlayout, neben C#, Visual Basic .NET oder C++ als dessen kompiliertem Begleiter. Erwartungsgemäß gibt es in XAML neue Bibliotheken und Namespaces, die der modernen Windows 8-Benutzererfahrung dienen.

Bei den deklarativen Sprachen – d. h. jeder Sprache mit „ML“ – gibt es hinsichtlich der Menge und Qualität der Benutzeroberflächen-Steuerelemente viele Übereinstimmungen. Wenn Sie ein Steuerelement in XAML vorfinden, ist es im Allgemeinen in HTML oder der WinJS-Bibliothek vorhanden und umgekehrt. Es gibt aber ein oder zwei Unterschiede zwischen den beiden.

XAML-Entwickler werden mit Ausnahme von einigen Namespaces und anderen unbedeutenden Modifizierungen kaum eine Veränderung bemerken. Expression Blend stellt weiterhin ein hervorragendes Tool für die Entwicklung der Benutzeroberflächen in XAML dar, während Visual Studio die beste Wahl für die kompilierte Sprache im Hintergrund ist. Es gibt ein weit verbreitetes Drittanbieter-Ökosystem im Hinblick auf XAML-Benutzeroberflächen-Steuerelemente, zum Beispiel Raster für XAML auf der WPF-Plattform, und viele dieser Steuerelemente funktionieren zwischen Windows Store- und Windows Phone-Apps genauso oder ähnlich.

Wenn Sie Windows Forms-Entwickler sind, ist nun der Zeitpunkt gekommen, XAML zu lernen, da Sie praktisch keine andere Wahl haben. Es gibt keine vergleichbare Benutzeroberflächensprache, die Sie verwenden können, da Windows Forms keine hat; hinter der Entwurfspalette findet sich nur C# oder Visual Basic .NET. Sie können zwar die allgemeinen .NET- und Sprachkenntnisse übertragen, müssen sich aber die DSL der Benutzeroberfläche aneignen: XAML. Sie könnten HTML lernen, müssten dies dann aber sowohl durch CSS als auch durch JavaScript ergänzen und somit drei Sprachen lernen; kein kleines Unterfangen.

Auswirkungen des Datenzugriffs auf die Auswahl der Sprache

Der Zugriff auf Daten funktioniert in den Sprachen verschieden, manchmal höchst unterschiedlich, und der Datenzugriff wird auch davon bestimmt, auf welche Art von Daten Sie zugreifen. Zunächst einmal stehen einige Techniken nur für einen oder einen anderen Satz von Technologien zur Verfügung, wie es bei Web Storage (auch als DOM-Speicherung bekannt, worüber Sie in meinem Blogbeitrag „Verwalten von Daten in Webanwendungen mit HTML5 Web Storage“ unter bit.ly/lml0Ul) weitere Informationen finden können) und IndexedDB der Fall ist, die Sie beide nur mit browserbasierten Sprachen wie JavaScript verwenden dürfen.

Windows Azure-Mobile Dienste (weitere Informationen hierzu finden Sie in einem anderen Blogbeitrag, „Mehr Leistung für Windows Store- und Windows Phone-Apps mit Windows Azure-Mobile Dienste“ unter bit.ly/15nhO8d) und die Windows Azure-Plattform bieten mehrere systemeigene APIs für alle verbreiteten Plattformen und REST-APIs, die von Natur aus plattformübergreifend sind. Da REST ein offener Standard ist, können Sie in jeder Sprache über eine einheitliche Schnittstelle von überall und jederzeit auf diese Daten zugreifen. REST-Schnittstellen erleichtern die plattformübergreifende Entwicklung, da der Code – trotz Sprachsyntax und -eigenheiten – eine allgemeine Konsistenz oder ein Muster aufweist. Öffentliche APIs, wie sie beispielsweise von Twitter, Facebook oder Wetterdiensten bereitgestellt werden, geben normalerweise JSON- oder XML-Code (oder beides) zurück, den Sie mit REST oder „XMLHttpRequest“ (XHR) verwenden können.

SQLite ist eine lokale Datenbankoption, die für alle Plattformen und Sprachen zur Verfügung steht. SQLite ist als NuGet-Paket für Windows Store- und Windows Phone-Apps in Visual Studio 2012 verfügbar. Sie können auch über ein Xamarin-Toolset darauf zugreifen und dessen Bibliotheken verwenden, um unter iOS und Android auf SQLite-Datenbanken zuzugreifen. SQLite ist mit XAML-Apps einfacher zu verwenden als mit HTML-Apps.

Was den Dateizugriff und die Datei-E/A-Vorgänge auf der Windows-Plattform angeht, sind Windows Store-XAML- und HTML-Apps auf gleicher Höhe. Die Sprache spielt also keine wesentliche Rolle, wenn für die App Lesen aus dem und Schreiben in das Dateisystem erforderlich ist. Obwohl für normales HTML und JavaScript im Browser viele Einschränkungen für Datei-E/A-Vorgänge und den Zugriff auf Systemressourcen gelten, ermöglicht das Entwicklungsmodell für Windows Store-Apps einen mehr als ausreichenden Zugriff auf das Dateisystem, wobei die Sicherheit gewahrt bleibt.

Vollständige Informationen zu Datenzugriffstechnologien für Windows Store- und Windows Phone-Apps finden Sie in meinem Artikel „Datenzugriffs- und Datenspeicherungsoptionen in Windows Store-Apps“ in der Ausgabe vom März 2013 unter msdn.microsoft.com/magazine/jj991982.

Plattformübergreifende Überlegungen

Objective-C unterscheidet sich syntaktisch und hinsichtlich der Vorgänge von anderen Sprachen, so wie Java und C# sich anders verhalten, da sie verwaltete Sprachen sind. Wenn Sie plattformübergreifende Apps schreiben, sind Sie aber nicht dazu gezwungen, Codebasen wie Objective-C für iOS, Java für Android und C# für Windows-Plattformen zu trennen, da die oben erwähnten Xamarin-Tools es vereinfachen, in C# zu schreiben und Java und Objective-C zu generieren. Xamarin stellt ein Toolset bereit, mit dem Sie im Zuge der plattformübergreifenden Entwicklung für Geräte (d. h. mobile und Tablet-Geräte) systemeigenen Code generieren. Xamarin ist der auch der kleinste gemeinsame Nenner für die plattformübergreifende systemeigene Entwicklung. Im Ergebnis können Entwickler von nahezu jeder Plattform ihre Fähigkeiten mühelos auf die Windows-Plattform oder plattformübergreifend über Xamarin und C# übertragen. Für Entwickler von den iOS- und Android-Plattformen ist es empfehlenswert, sich für C# als Sprache ihrer Wahl zu entscheiden, wenn sie Apps sowohl für die Windows-Plattform als auch für die anderen veröffentlichen möchten. Einige Entwickler in Redmond sprechen sich allerdings dagegen aus. Sie sind der Ansicht, dass es praktischer ist, Bibliotheken in C++ und C zu entwickeln, da auf diese mit iOS (direkt) und Windows-Apps (über Windows-Runtime- oder WinRT-Komponenten) zugegriffen werden kann. Die Befürworter dieses Ansatzes betonen, dass er kostenlos (die meisten Xamarin-Tools kosten Geld) und leistungsfähiger als Drittanbietertools ist. Ich bevorzuge die Erstellung und Freigabe von Xamarin-Komponenten, da die Dauer bis zur Markteinführung wichtiger ist als die geringfügigen Leistungsvorteile. Außerdem verwende ich nicht besonders gern C++.

Auswirkungen der Portierung von Legacycodebasen auf die Sprachauswahl

Nicht alle Apps sind vollständig neu (d. h. neu oder erneut geschrieben). Tatsächlich sind die meisten älteren Ursprungs oder Legacyprogramme. Dies gilt insbesondere, wenn Sie Code für Unternehmen schreiben. Viele Apps sind tatsächlich Teile eines größeren Softwareökosystems, das aus mehreren Apps oder Benutzeroberflächen besteht, die mit Geschäftslogik, Dienstebenen, öffentlichen APIs oder Bibliotheken interagieren.

Besonders die Migration von Web-Apps kann knifflig sein, da Sie häufig den Inhalt einer vorhandenen Website unversehrt beibehalten, denselben Inhalt aber in die Client-App integrieren müssen, wobei er für die Benutzer wie systemeigener Inhalt wirken soll. Der Grund dafür ist, dass häufig durch Geschäftsanforderungen bestimmt wird, dass die ursprüngliche Website oder Architektur unverändert bleiben muss. Als Folge kann das Erscheinungsbild der App von dem des Hostbetriebssystems abweichen, die App somit schwierig verwendbar sein und der natürliche Workflow der Benutzer blockiert werden. Wenn Sie eine vorhandene Website oder App portieren, können Sie sich zum Glück oft stattdessen für eine Integration entscheiden. In diesem Fall kann das Apache Cordova-Framework (vormals PhoneGap) von Nutzen sein. Mit Cordova können Sie hybride Apps (Web-App/systemeigen) erstellen, indem Sie Webinhalte und systemeigene Benutzeroberflächenkomponenten integrieren und plattformübergreifend veröffentlichen. Umgekehrt ist es mithilfe von WinJS nicht schwer, Webinhalte mit einer systemeigenen WinJS-Windows Store-App zu integrieren, wodurch Sie normalerweise eine nahtlosere Benutzererfahrung erreichen. Systemeigene Apps sind enger in das Betriebssystem integriert als Web-Apps für Clients, da die systemeigenen Apps Zugriff auf moderne Hardwareressourcen haben, wie Kamera, Mikrofon, Geräteeinstellungen, Beschleunigungsmesser, Geolocation usw. Zusätzlich dazu haben systemeigene Apps einen separaten Lebenszyklus und umfassen Status, während Web-Apps kompakt sind und keinen Status aufweisen.

Auf den Zweck der App kommt es an

In gewissem Ausmaß wird die Sprache, die Sie verwenden, durch die Art und den Zweck der App bestimmt. Für Spiele- und Grafik-Apps mit hoher Auslastung sind Sprachen wie C++ und DirectX (jetzt Teil vom Windows SDK) geeignet, da Sie eine engere Verbindung mit dem Computer erreichen, an Leistung gewinnen und die Gerätesteuerung verbessern können. DirectX ist eine vollständige Sammlung von basisnahen APIs, auf die Sie über C++ zugreifen können, um beeindruckende Spiele und Apps zu erstellen. Der Nachteil von C++/DirectX ist komplexer Code, durch den Sie leicht Probleme bekommen können. C++ ist auch nicht die einzige Option für Spiele. JavaScript-Apps (genau, JavaScript) sind hoch leistungsfähig, besonders im Hinblick auf Canvasspiele. Der Ausführungscontainer der Windows Store-App überträgt die Skriptverarbeitung an die GPU, sodass JavaScript parallel, aber unabhängig vom Layout ausgeführt werden kann, welches vom Trident-Layoutmodul übernommen wird. Durch diese Angabe der Verlagerung wird JavaScript zu einer wirklich schnellen Sprache, die genauso gut wie systemeigener Code ausgeführt werden kann. Wenn die Leistung ein wesentlicher Faktor für Sie ist, Sie aber kein C++ lernen möchten, können Sie das möglicherweise mit dem HTML-Canvas vermeiden.

Wenn Sie Geschäfts- und Produktivitäts-Apps schreiben, können Sie in der Regel zwischen allen Sprachen auswählen, die für Sie geeignet sind, da solche Aspekte wie die Leistung und die Benutzeroberflächen-Steuerelemente so ähnlich sind. Gewöhnlich handelt es sich bei diesen Apps um gängige Formulare-über-Daten-Apps. Die Auswahl der Sprachen und Technologien für diese Arten von Apps wird normalerweise von der aktuellen Technologiepalette bestimmt.

Was ist mit F#?

Sie fragen sich, was mit F# passiert ist? F# gehört zwar nicht zu den grundlegenden Vorlagen für die Entwicklung von Windows Store- und Windows Phone-Apps, aber Sie können in F# erstellte Komponenten referenzieren und nutzen. F# ist auch eine hervorragende Sprache zur Verarbeitung von Analysen und zum Ausführen von Code im Back-End – und alle Apps benötigen ein Back-End.

Webentwickler verwenden häufig eine Mischung aus CSS zur Gestaltung von HTML und JavaScript, um mit dieser Kombination moderne Benutzeroberflächen zu erstellen. Systemeigenen Entwicklern steht dafür ebenfalls ein Satz von aktuellen Sprachen zur Verfügung. Wenn Sie eine Sprache auswählen, ist es also an Ihnen, alle Faktoren zu berücksichtigen, die sich auf die App auswirken können.

Rachel Appel ist Beraterin, Autorin, Mentorin und frühere Microsoft-Mitarbeiterin mit über zwanzigjähriger Erfahrung in der IT-Branche. Sie nimmt an wichtigen Branchenkonferenzen wie Visual Studio Live!, DevConnections und MIX als Rednerin teil. Ihr Fachbereich ist die Entwicklung von Lösungen, bei denen geschäftliche und technologische Aspekte in Einklang gebracht werden und in denen führende Microsoft- und offene Webtechnologien zum Einsatz kommen. Besuchen Sie Rachel Appel auf ihrer Website unter rachelappel.com.

Unser Dank gilt den folgenden technischen Experten von Microsoft für die Durchsicht dieses Artikels: Eric Schmidt (erschmid@microsoft.com) und John Kennedy (jken@microsoft.com)