Ausgeführt wird nur im Sandkasten

Die Ausführung von Metro-Apps auf Basis der WinRT findet ähnlich wie bei Silverlight-Anwendungen und bei Windows-Phone-Apps in einer Sandbox (App Execution Environment) statt, die nur eingeschränkten Zugriff auf die Systemressourcen gewährt. Jede Metro-App hat dabei einen abgeschotteten Speicherbereich, Dateisystem-Zugriffe finden nur auf diesen Speicher statt oder auf festgelegte Ordner wie z.B. “Bilder”, wenn der Nutzer dem zustimmt. Der Zugriff auf Geräte-Ressourcen wie die Ortungsfunkionen oder die Kamera und auf Funktionalität wie das Abrufen von Daten aus dem Internet muss in einem App-Manifest deklariert werden. Benutzer müssen dann bei Installation der Metro-App aus dem Windows Store (Marketplace) den Zugriff für die App freigeben, ansonsten wird die Installation abgebrochen.

Während es sich bei vielen Aufrufen in WinRT um direkte Betriebssystem-Calls handelt, schaltet sich ein Broker ein, sobald auf Ressourcen zugegriffen werden soll, die im App-Manifest deklariert sind bzw. wenn eine Benutzer-Freigabe erforderlich ist. Solche “Brokered API calls” und die Ausführungsumgebung von Metro-Apps allgemein werden in folgendem Schaubild dargestellt.

Moment mal – wo bleibt .NET?

Sieht man sich noch einmal das Architektur-Diagramm der Windows-8-Plattform aus dem letzten Blogbeitrag an, so entdeckt man .NET nur als kleines Kästchen auf Seite der klassischen Desktop-Applikationen. Ist WinRT somit als Quasi-Ersatz für .NET zu sehen? Nein! Hier gilt es die Konzepte und Nutzung zu verstehen und klar zu unterscheiden.

.NET ist ein Managed Code Framework als separate Schicht, die auf dem Betriebssystem aufsetzt. In einer .NET-Sprache geschriebener Code läuft als Bytecode (CIL) in der .NET Runtime (CLR). WinRT setzt darunter an. Es ist eine native Bibliothek, die direkt in das Betriebssystem integriert ist. WinRT und .NET lassen sich somit gar nicht direkt miteinander vergleichen.

Was das Schaubild nicht zeigt: auch bei Metro-Apps verliert .NET nichts an Bedeutung. In C# geschriebene Apps werden weiterhin in der .NET Runtime ausgeführt, C#-Code kann weiterhin auf die Funktionalität des .NET Frameworks zugreifen, Entwicklern stehen damit weiterhin viele der gewohnten Klassen und Konzepte zur Verfügung. Es gibt allerdings eine große Einschränkung: nicht alle Funktionalität von .NET kann in Metro-Apps tatsächlich genutzt werden. Die Base Class Library (BCL) lässt sich in vollem Umfang nutzen, doch alle .NET-Komponenten, die das Sicherheits- und Ausführungskonzept von Metro-Apps unterwandern könnten, sind außen vor. Dazu gehören direkte Dateisystem-Zugriffe ebenso wie ADO.NET, ASP.NET, WPF etc..

Es ist also zu erkennen, dass .NET nichts an seiner Bedeutung einbüßt. Im Gegenteil wurde WinRT stark von .NET beeinflusst (Metadatensystem, Prinzipien wie Events, Generics etc., XAML in der Plattform) und Entwickler können zukünftig ihr vorhandenes .NET-Wissen verwenden, um sowohl klassische Desktop-Applikationen als auch neuartige Metro-Apps zu erstellen.

Und was ist mit Silverlight?

Totgeglaubte leben länger, möchte man mit einem Blick auf Silverlight sagen. Auch Silverlight wird unter Windows 8 fortbestehen, wenn auch nur für den klassischen Desktop. Dort laufen Silverlight-Anwendungen im Browser oder out-of-Browser wie bisher ohne Einschränkungen. Anders sieht es in der Metro-UI aus. Hier spielt Silverlight keine Rolle mehr, es können keine Metro-Apps mit Silverlight entwickelt werden und auch in der Metro-Version des Internet Explorers ist keine Ausführung von Silverlight-Anwendungen möglich, da der Metro-IE keine Plugins unterstützt.

Insgesamt bedeutet das, dass Silverlight bei der Programmierung von Metro-Apps als explizites Produkt keine Rolle mehr spielen wird. Die Technologie und die Konzepte von Silverlight leben in der Entwicklung von Metro-Apps allerdings weiter. Ähnlich wie bei Silverlight steht C#-Entwicklern ein abgespecktes .NET Framework zur Verfügung, die UI-Gestaltung/-Programmierung erfolgt in XAML, es ist ein hohes Maß an Asynchronität vorhanden und Applikationen laufen mit eingeschränkten Rechten in einer Sandbox. Das alles lässt einen Entwickler von C#-Metro-Apps denken, er programmiere in Silverlight und die Umgewöhnung fällt durch den hohen Wissensübertrag nicht schwer.

Silverlight wird somit sowohl als RIA-Technologie für Intranet-Anwendungen als auch als Plattform für Windows Phone weiterbestehen. Microsoft tut sich aktuell allerdings mit klaren Aussagen zur Zukunft von Silverlight schwer. Fakt ist: Silverlight 5 wird noch in 2011 veröffentlicht. Doch wie es danach weitergeht und ob ein Silverlight 6 kommen wird… dazu trifft Microsoft keine Aussagen. Laut informierten Quellen von Mary-Jo Foley soll es sich bei Silverlight 5 um das letzte große Silverlight-Release handeln. Man darf gespannt sein…

Weiterhin ist im Windows-Phone-Bereich zu erwarten, dass Microsoft das WinRT-Programmiermodell mittelfristig für Windows Phone adaptieren wird (= 1-2 Jahre, vielleicht schon in Windows Phone 8… s. auch hier). Ein Vorteil von iOS ist es, dass Anwendungen darauf sowohl für iPad als auch iPhone entwickelt werden können. Es ist nur folgerichtig, dass Microsoft die doch sehr ähnlichen Programmier- und Ausführungsmodelle von Windows und Windows Phone über kurz oder lang vereint. Windows-Phone-Apps werden dann zwar immernoch mit Silverlight entwickelt werden können (MS kann es sich hier nicht mit bestehenden App-Entwicklern verscherzen), seine Bedeutung dürfte zugunsten von WinRT aber stetig sinken.

Die Blüte von HTML5/JS

HTML5 ist das Buzzword in der heutigen Welt der Webentwicklung. Mit seinen Fähigkeiten und den damit einhergehenden JavaScript-APIs rücken in HTML5 entwickelte Web-Anwendungen in puncto Funktionalität und Reaktionsverhalten deutlich zu klassischen Desktop-Applikationen und zu RIA-Anwendungen auf. Einen nicht unwesentlichen Beitrag dazu leisten moderne JavaScript-Bibliotheken wie jQuery, die Webanwendungen dynamischer machen und Entwicklern das Leben mit JavaScript erleichtern.

Bei JavaScript handelt es sich auch um eine von WinRT unterstützte Sprache, womit sich Metro-Apps unter Windows 8 mit HTML und JavaScript entwickeln lassen. Ausgeführt werden solche Apps wie jede andere Metro-App auch, das Rendering erfolgt dabei mit der Engine des Internet Explorer 10. Die WinRT-APIs werden über die JS-Bibliothek “WinJS” abstrahiert, die Entwicklern eine weitreichende Funktionalität für die Erstellung von Metro-Apps liefert.

In HTML/JS entwickelte Metro-Apps werden gemeinhin als “WinWebApps” bezeichnet. Es ist zu beachten, dass diese WinWebApps hochgradig von der windows-spezifischen WinJS-Bibliothek abhängen. Eine Plattformunabhängigkeit und somit eine Nutzung der WinWebApps als normale Web-Anwendungen im Browser ist damit per se erst einmal nicht gegeben. Zwar lassen sich auch “normale” Web-Anwendungen zu einer Metro-App wandeln, doch verlieren sie dann die Windows-8-typische Funktionalität in Form von WinJS.

Doch auch ohne Plattformunabhängigkeit macht das HTML/JS-Modell von Windows 8 Sinn. Microsoft holt damit die Massen an Web-Entwicklern mit ins Boot, die bisher bei der Entwicklung von Windows-Anwendungen außen vor blieben. Ebenso lassen sich in solchen WinWebApps praktisch alle bekannten JavaScript-Bibliotheken wie jQuery mit ihrer Funktionalität (Controls, Animationen, …) weiter verwenden.

Fazit und Ausblick

Die Ausführungsumgebung von Metro-Apps ähnelt der von Windows Phone, viele Konzepte sind von dieser Plattform und dem dortigen Programmiermodell mit Silverlight als Basis entlehnt. Silverlight lebt damit in Metro weiter, wenn auch nicht als explizit benannte Technologie. Und auch die Bedeutung von .NET sinkt mit Metro keineswegs. Die verfrühte Befürchtung einiger Entwickler, dass mit Windows 8 jetzt nur noch in HTML5/JavaScript entwickelt wird, war naiv und unbegründet. Nichtsdestotrotz steht mit HTML5/JavaScript ein Programmiermodell für Windows 8 zur Verfügung, das nicht zuletzt aufgrund der vielen verfügbaren JavaScript-Bibliotheken eine hohe Anziehungskraft ausübt.

In folgenden Beiträgen werde ich über meine Erfahrungen bei der Entwicklung der “SDX News”-Metro-App berichten, zum einen mit XAML/C#, zum anderen mit HTML5/JavaScript.