Kapitel 1. WinRT und.net

Transkript

1 1 Einführung Kapitel 1 in Windows 8, WinRT und.net 1 Sehen Sie dieses Kapitel als lockere Aufwärmrunde an, bevor es richtig losgeht! Neben den Merkmalen einer Windows Store App lernen Sie die Grundlagen zum Entwickeln für Windows 8 kennen. Die bei Windows Store Apps verwendete Windows Runtime und das».net für Windows Store Apps«werden näher betrachtet. Mit Windows 8 hat Microsoft neben dem klassischen Desktop die Modern UI-Oberfläche eingeführt, die in Windows 8 den neuen Startbildschirm darstellt. In dieser auf Berührungseingaben (Touch) ausgerichteten Oberfläche lassen sich keine Desktop- Anwendungen, sondern nur die speziell dafür entwickelten Windows Store Apps ausführen. Eine Windows Store App besitzt spezifische Merkmale, die Sie in Abschnitt 1.1,»Die Merkmale einer Windows Store App«, näher kennenlernen. Neben Windows Store Apps lassen sich unter Windows 8 nach wie vor klassische Desktop-Anwendungen entwickeln, z.b. basierend auf der Windows Presentation Foundation (WPF). Welche Möglichkeiten Sie zum Entwickeln von Windows Store Apps und Desktop-Anwendungen haben, erfahren Sie in Abschnitt 1.2,»Entwickeln für Windows 8«. Dabei kommen Sie auch erstmals mit der Windows Runtime (WinRT) in Kontakt. Die WinRT ist die mit Windows 8 eingeführte, objektorientierte Windows-Programmierschnittstelle (Windows-API). Sie ist die Grundlage für Windows Store Apps. Die WinRT selbst basiert auf einem erweiterten Component Object Model (COM) und.net-metadaten. Wie es zu dieser Kombination mit COM und.net- Metadaten kam, erfahren Sie ebenfalls in Abschnitt 1.2 mit einem kurzen Rückblick auf die Geschichte der Windows-Entwicklung. Mit dem Wissen im Gepäck, was die Herausforderungen mit klassischem COM und.net sind, lernen Sie in Abschnitt 1.3,»Die Windows Runtime (WinRT)«, die Architektur und die unterstützten Sprachen der WinRT kennen. Lesen Sie, wie die WinRT Metadaten im.net-format verwendet, wie die WinRT in verschiedene Sprachen wie JavaScript oder C# projiziert wird und wie die WinRT bestimmte Aufrufe über einen Broker kontrolliert. Ein Überblick über die wichtigsten Namespaces und die Stärken des UI-Teils der WinRT runden diesen Abschnitt ab. 39

2 1 Einführung in Windows 8, WinRT und.net Wenn Sie Windows Store Apps mit XAML und C# entwickeln, kommt eine Untermenge des.net Frameworks 4.5 namens.net für Windows Store Apps zum Einsatz. Beim Entwickeln verwenden Sie Klassen aus der WinRT und aus diesem kleinen.net Framework. Was Sie im.net für Windows Store Apps alles finden, was dagegen in die WinRT integriert wurde und was komplett fehlt, erfahren Sie in Abschnitt 1.4,».NET für Windows Store Apps«. Im letzten Teil dieses Kapitels erhalten Sie einen kleinen Vorgeschmack auf die Konzepte der WinRT. Dazu gehören XAML, Layout, Dependency Properties, Styles und Templates etc. Falls Sie bereits mit der WPF oder Silverlight Erfahrung haben, wird Ihnen vieles bekannt vorkommen. Und jetzt geht s los. Schnallen Sie sich an, und haben Sie Spaß. 1.1 Die Merkmale einer Windows Store App Windows Store Apps werden über den von Microsoft zur Verfügung gestellten Marktplatz namens Windows Store vertrieben. Sie besitzen einige Merkmale, die sie von klassischen Desktop-Anwendungen unterscheiden. Diese Merkmale wie Live Tiles, die App Bar oder das Snapping betrachten wir in diesem Abschnitt. Hinweis Windows Store Apps lassen sich auch auf Endgeräte verteilen, ohne dass sie in den Windows Store geladen werden. Diese als Side-Loading bezeichnete Funktionalität ist insbesondere für Unternehmen interessant. Lesen Sie mehr zu diesem Thema und wie Sie Ihre App in den Windows Store bekommen in Kapitel 22,»Verpacken und veröffentlichen« Die Live Tiles Auf dem auf Touch-Eingaben ausgerichteten, kachelbasierten Modern UI von Windows 8 werden die Kacheln der Anwendungen angezeigt. Diese Kacheln auf Englisch tiles zeigen dem Benutzer Liveinformationen der dahinterliegenden Anwendung an. Daher werden sie als Live Tiles bezeichnet. Abbildung 1.1 zeigt das Modern UI, die in Windows 8 den Startbildschirm darstellt. Die Live Tile des Mail-Programms (links oben) zeigt an, dass eine neue empfangen wurde. Direkt darunter zeigt die Live Tile des Kalenders den nächsten Termin an. Ein Klick auf eine Live Tile öffnet das jeweilige Programm. In Abbildung 1.1 sehen Sie als unterste Kachel in der dritten Spalte die Live Tile der FriendStorage-Anwendung. Dies ist die durchgängig in diesem Buch verwendete Bei- 40

3 1.1 Die Merkmale einer Windows Store App spielanwendung, anhand der wir im Folgenden die weiteren Merkmale einer Windows Store App betrachten. 1 Abbildung 1.1 Die kachelbasierte Oberfläche unter Windows Kein Fensterrahmen Eine Windows Store App wird wie in Abbildung 1.2 dargestellt per Default im Vollbildmodus geöffnet. Bei einer Windows Store App steht der Inhalt im Vordergrund, daher besitzt sie keinen Fensterrahmen. Aufgrund dieser Tatsache gibt es zum Schließen einer App nicht das bekannte rote Kreuz, das bei Desktop-Anwendungen in der rechten oberen Ecke des Fensterrahmens sitzt. Abbildung 1.2 Eine Windows Store App besitzt keinen Fensterrahmen. 41

4 1 Einführung in Windows 8, WinRT und.net Sie schließen eine Windows Store App auf einem Touch-Gerät, indem Sie vertikal von der oberen Bildschirmkante zur unteren wischen. Bei der Bedienung mit der Maus und Tastatur lässt sich die App an der oberen Kante»anpacken«und zum Schließen einfach nach unten ziehen. Mit (Alt) + (F4) haben Sie die altbekannte Alternative zum Schließen einer Windows Store App Die Charms Bar Windows 8 besitzt auf der rechten Seite des Bildschirms die in Abbildung 1.3 dargestellte Charms Bar. Die Charms Bar ist eine Leiste»mit Zaubern«(»Charms«). Sie wird auf einem Touch-Gerät beim Hereinwischen vom rechten Bildschirmrand geöffnet. Die Charms Bar öffnet sich ebenfalls, wenn Sie die Maus in die rechte obere oder untere Ecke bewegen oder wenn Sie die Tastenkombination + (C) drücken. Abbildung 1.3 Die Charms Bar von Windows 8 wird auf der rechten Seite angezeigt. Wie Abbildung 1.3 zeigt, bietet die Charms Bar verschiedene Möglichkeiten, wie Suchen, Teilen, Geräte und Einstellungen. Die Möglichkeiten sind dabei immer kontextspezifisch: Egal, welche App Sie geöffnet haben, die Einstellungen zur geöffneten App finden Sie immer über die Charms Bar. Lässt sich eine App durchsuchen, erreichen Sie diese Funktionalität ebenfalls über die Charms Bar. Ist in FriendStorage wie in Abbildung 1.3 eine Freundesliste geöffnet und wird in der Charms Bar auf Suchen geklickt, öffnet sich eine Suchleiste mit einem Eingabefeld. In Abbildung 1.4 wurde in dieses Eingabefeld der Name»Huber«eingegeben. Beachten Sie, dass die ( )-Taste auf der Bildschirmtastatur den Text Suchen enthält. Be- 42

5 1.1 Die Merkmale einer Windows Store App achten Sie auch, dass in der Suchleiste unterhalb des Eingabefelds bereits eine Vorschau der in FriendStorage gefundenen Personen angezeigt wird. 1 Abbildung 1.4 Über die Charms Bar lässt sich eine Suche starten. Wurde auf der in Abbildung 1.4 angezeigten Tastatur auf (Suchen) getippt oder auf der physischen Tastatur die ( )-Taste gedrückt, startet FriendStorage die Suche und zeigt das Ergebnis aus Abbildung 1.5 an. Abbildung 1.5 Die FriendStorage-App zeigt das Ergebnis der Suche an. 43

6 1 Einführung in Windows 8, WinRT und.net In der Suchleiste in Abbildung 1.5 ist die FriendStorage-Anwendung ausgewählt. In der Suchleiste lässt sich auch eine andere Anwendung auswählen und durchsuchen. Standardmäßig ist immer die aktuell geöffnete Anwendung ausgewählt. Neben der hier dargestellten Suche bietet die Charms Bar weitere Möglichkeiten. So kann beispielsweise über die Teilen-Funktion eine App verschiedenen anderen Apps bestimmte Inhalte zur Verfügung stellen. Mehr dazu lesen Sie in Kapitel 16,»Contracts und Extensions« Die App Bar Bei Windows Store Apps finden Sie die Anwendungsfunktionen typischerweise in der App Bar. Die App Bar ist eine Leiste am unteren Bildschirmrand. In Abbildung 1.6 sehen Sie die App Bar von FriendStorage, die beim Bearbeiten eines Freundes angezeigt wird. Darauf befinden sich Buttons zum Speichern und Abbrechen. Abbildung 1.6 Die App Bar beim Bearbeiten eines Freundes Der Benutzer blendet die App Bar mit einer Wischgeste von der unteren oder oberen Kante ein. Auch ein Klick der rechten Maustaste oder die Tastenkombination + (Z) zeigt die App Bar an. Neben der unteren App Bar gibt es bei einigen Anwendungen auch eine obere App Bar. Während in der unteren App Bar üblicherweise Anwendungsfunktionen untergebracht werden, dient die obere App Bar zur Navigation innerhalb der App. 44

7 1.2 Entwickeln für Windows Snapping von Anwendungen Windows Store Apps lassen sich auch an den Rand andocken, was als Snapping bezeichnet wird. In Abbildung 1.7 wurde die FriendStorage-App an den linken Bildschirmrand angedockt, um im restlichen Bereich zur Abwechslung eine Runde»Minesweeper«zu spielen. 1 Abbildung 1.7 Für eine Partie»Minesweeper«wurde FriendStorage links angedockt. Beachten Sie, dass die FriendStorage-App im angedockten Zustand die Freundesgruppen anders darstellt. Alle Gruppen und Freunde stehen untereinander, die Bilder sind kleiner etc. Sie als Entwickler müssen für diesen angedockten Zustand ein passendes Aussehen Ihrer Anwendung gestalten. Mehr zum Snapping und zu weiteren Layoutthemen in Kapitel 5,»Layout«. 1.2 Entwickeln für Windows 8 Zum Entwickeln von Anwendungen stehen Ihnen unter Windows 8 verschiedene Möglichkeiten offen. Obwohl dieses Buch Windows Store Apps mit XAML und C# behandelt, sollten Sie in der Lage sein, diese Variante in das Gesamtkonzept von Windows 8 einzuordnen. Dazu lernen Sie in diesem Abschnitt die Architektur unter Windows 8 näher kennen. 45

8 1 Einführung in Windows 8, WinRT und.net Die Architektur unter Windows 8 Zum Entwickeln einer Anwendung unter Windows 8 haben Sie prinzipiell zwei Möglichkeiten: Sie entwickeln eine Windows Store App für das Modern UI. Sie entwickeln eine Anwendung für den Desktop. Eine Windows Store App läuft auf dem Modern UI und lässt sich über den Windows Store von Microsoft vertreiben. Die Windows Store App läuft nicht auf dem klassischen Desktop und ist somit nicht kompatibel mit Windows 7 und älteren Windows- Versionen. Die klassische Desktop-App läuft hingegen nicht auf dem Modern UI, sondern nur auf dem klassischen Desktop. Hinweis Es ist nicht möglich, eine einzige native Anwendung sowohl für das Modern UI als auch für den Desktop zu entwickeln. Im vorherigen Abschnitt haben Sie bereits einige Merkmale einer Windows Store App kennengelernt. Ihnen ist bestimmt klar, dass die Designprinzipien mit App Bar, Charms Bar, Snapping etc. komplett andere als bei einer Desktop-Anwendung sind. Selbst wenn es technisch möglich wäre, eine Anwendung für das Modern UI und den Desktop zu bauen, wäre dies aus designtechnischen Gründen nicht zu empfehlen. Abbildung 1.8 zeigt einen groben Überblick der Architektur zum Entwickeln unter Windows 8. Im linken Teil finden Sie die Windows Store Apps, im rechten Teil die Desktop-Apps. Windows Store Apps Desktop Apps View XAML DirectX HTML/CSS HTML XAML Win Forms MFC Direct X Model Controller C#/VB.NET für Windows Store Apps C++/CX JavaScript WinJS/ Chakra Engine Java Script Silverlight Internet Explorer C#/VB.NET 4.5 = CLR + Bibliothek C++/CLI C++ Systemdienste Kommunikation & Daten Windows Runtime (WinRT) APIs Grafik & Medien Application Model Geräte & Drucken Win32 Kernel Windows Kernel Abbildung 1.8 Möglichkeiten zum Entwickeln von Windows Store Apps und Desktop-Apps 46

9 1.2 Entwickeln für Windows 8 Nehmen Sie sich Zeit, um sich die sehr wichtigen Details von Abbildung 1.8 zu verinnerlichen. Im unteren Teil von Abbildung 1.8 ist der Kern von Windows dargestellt, der Windows Kernel. Darauf aufbauend finden Sie die nativen Programmierschnittstellen WinRT für Windows Store Apps und Win32 für Desktop-Apps. Während die Win32- API schon seit Jahrzehnten existiert, ist die WinRT die mit Windows 8 eingeführte, moderne und objektorientierte Windows-Schnittstelle (= Windows-API). 1 Achtung Beachten Sie, dass Microsoft eine Windows-Version speziell für ARM-Prozessoren entwickelt hat. Diese Windows-Version ist im Grunde eine abgespeckte Variante des klassischen Windows 8 und nennt sich Windows RT. Zugegeben, für uns Entwickler ein etwas verwirrender Name, da die neue API WinRT heißt. Windows RT unterstützt aufgrund der ARM-Prozessor-Architektur keine klassischen Desktop-Apps. Lediglich die speziell für ARM-Prozessoren entwickelte Office-Suite und der Internet Explorer sind im Desktop-Modus verfügbar. Wenn Sie also eine Applikationen entwickeln möchten, die sowohl unter ARM-Prozessoren (mit Windows RT) als auch unter x86/x64-architekturen (volles Windows 8) läuft, fällt die Wahl auf eine Windows Store App. Diese ist durch die WinRT prozessorunabhängig Windows Store Apps entwickeln Zum Entwickeln von Windows Store Apps haben Sie verschiedene Möglichkeiten: XAML mit C#/VB: Dabei kommt eine Untermenge des.net Frameworks zum Einsatz. Sie schreiben wie in.net»managed Code«, rufen darin APIs der nativen WinRT auf und verwenden für die Darstellung die XML-basierte Beschreibungssprache XAML. XAML mit C++: Sie schreiben nativen Code in C++. Mit den Component Extensions (CX) wird eine Erweiterung für C++ verwendet, die schlankeren Code erlaubt. Für die Darstellung kommt ebenfalls XAML zum Einsatz. DirectX mit C++: Sie schreiben nativen Code in C++ und verwenden zum Zeichnen DirectX. Dies ist insbesondere zum Programmieren von Spielen interessant. HTML/CSS mit JavaScript: Sie schreiben die Oberfläche mit HTML/CSS und Ihre Logik in JavaScript. Für JavaScript wird dabei die auch im Internet-Explorer verwendete Chakra-Engine genutzt. Mit der WinJS-Library sind Aufrufe von WinRT- APIs möglich. In den folgenden Abschnitten dieses Kapitels erfahren Sie mehr Details zur WinRT und zum.net für Windows Store Apps. 47

10 1 Einführung in Windows 8, WinRT und.net Desktop-Anwendungen entwickeln Zum Entwickeln von klassischen Desktop-Anwendungen bietet Ihnen Microsoft zahlreiche Möglichkeiten. Hier ein kleiner Ausschnitt der existierenden Technologien: Windows Presentation Foundation (WPF): eine UI-Bibliothek und seit Version 3.0 Teil des.net Frameworks. Die WPF nutzt zur Darstellung XAML und für die Logik C#/VB. Windows Forms: eine UI-Bibliothek und seit Version 1.0 Teil des.net Frameworks. Die Darstellung und die Logik werden in C#/VB programmiert. Die WPF ist der strategische Nachfolger von Windows Forms. Silverlight: Das ursprünglich unter dem Codenamen WPF/Everywhere bekannte Browser-Plugin stellt eine Untermenge der WPF dar. Es nutzt ein abgespecktes.net Framework und erlaubt das Entwickeln von Anwendungen mit XAML und C#/ VB. Silverlight-Anwendungen lassen sich auch außerhalb des Browsers als sogenannte Out-of-Browser-App (OOB) in einem eigenen Fenster ausführen. Microsoft Foundation Classes (MFC) ist eine UI-Bibliothek zum Entwickeln von nativen Anwendungen mit C++. In der Vergangenheit hat sich zum Entwickeln von Geschäftsanwendungen das.net Framework mit der WPF etabliert. Hinweis Neben den klassischen Desktop-Anwendungen bietet Microsoft mit ASP.NET eine Möglichkeit zum Entwickeln von Web-Anwendungen. 1.3 Die Windows Runtime (WinRT) Die WinRT ist die moderne, objektorientierte Windows-Schnittstelle, die neben der Win32-API zum Einsatz kommt. Doch die WinRT ist mehr als nur eine Schnittstelle sie ist, wie der Name schon sagt, eine Runtime. Die WinRT bildet die Grundlage für Windows Store Apps. Daher lernen Sie in diesem Abschnitt die WinRT genauer kennen. Starten wir mit den Grundlagen Die WinRT-Grundlagen Mit Windows 8 hat Microsoft die WinRT eingeführt eine neue Runtime, die für Ihre Windows Store App die Controls bereitstellt und Zugriff auf die zentralen Funktionen des Betriebssystems bietet. Die WinRT enthält verschiedene Klassen für UI, Dateizugriff, Netzwerk etc. 48

11 1.3 Die Windows Runtime (WinRT) Hinweis Windows Store Apps haben keinen Zugriff auf die»alte«win32-api. 1 Die Bibliotheken der WinRT sind in nativem Code geschrieben und basieren auf einem erweiterten Component Object Model (COM). Die WinRT ist also nativ in C/ C++ implementiert und somit nicht in.net geschrieben. Dennoch sind die Bibliotheken selbst wie bei.net in Namespaces aufgeteilt. Diese Namespaces beginnen mit Windows, beispielsweise Windows.UI.Xaml.Controls für die UI-Controls oder Windows.Storage für Dateizugriffe. Dazu mehr in Abschnitt Hinweis Falls sich Ihnen beim Begriff COM die Nackenhaare aufstellen, kann ich Sie beruhigen. Die WinRT basiert zwar auf einem erweiterten COM, für Sie als Entwickler bleibt dieses Prinzip jedoch weitestgehend verborgen. Die WinRT selbst ist sprachneutral. Das heißt, sie ist nicht an eine Programmiersprache gebunden. Dazu besitzt die WinRT auch ein eigenes Typsystem, das beim Verwenden von C# automatisch auf die.net-typen gemappt wird. Dieses Mapping bezeichnet man als Language Projection. Dadurch fühlen sich WinRT-Komponenten in C# wie gewöhnliche.net-klassen an. Die WinRT wurde so gestaltet, dass sie perfekt zu objektorientierten Sprachen wie bspw. C# passt. Sie enthält daher neben den Namespaces viele weitere aus.net bekannte Konzepte: Klassen Events und Delegates Methoden Properties... Ihre Inhalte geben die nativen Bibliotheken der WinRT über Metadaten preis. Und hier kommt ein wirklich spannender Punkt: Diese Metadaten verwenden das gleiche Format wie die Metadaten einer in.net geschriebenen Bibliothek (Assembly). Da die nativen Bibliotheken der WinRT diese Metadaten nicht direkt enthalten können, werden sie in separaten Windows-Metadata-Dateien (.winmd) gespeichert. Entwickeln Sie Ihre Windows Store App mit XAML und C#, nutzen Sie dazu eine Untermenge von.net und die WinRT. Dabei lassen sich insbesondere aufgrund der Metadaten WinRT-Typen genau gleich wie.net-typen verwenden. 49

12 1 Einführung in Windows 8, WinRT und.net Hinweis Zum Verwenden von nativem Code sind in C# normalerweise P/Invoke-Deklarationen notwendig. Aufgrund der Metadaten der WinRT entfällt dies bei Windows Store Apps. Die WinRT-Typen lassen sich in Ihrem C#-Code genauso wie.net-typen nutzen. Als Fazit dieser Grundlagen halten wir fest, dass die WinRT Folgendes ist: WinRT = erweitertes COM +.NET-Metadaten Doch Moment, wie war das mit COM? COM ist die Technologie, die Microsoft mit der Einführung des.net Frameworks im Jahr 2002 für tot erklärt hat! Und zehn Jahre später ist COM in einer erweiterten Form doch wieder zurück, da die 2012 eingeführte WinRT darauf basiert. Um zu verstehen, warum Microsoft wieder auf COM setzt, was die Vorteile und Nachteile von.net sind und wie es zur WinRT kam, machen wir einen kleinen Ausflug in die Geschichte. Hinweis zum erweiterten COM Im Gegensatz zum klassischen COM hat die bei der WinRT eingesetzte, erweiterte Version von COM einige Verbesserungen. Hier ein kleiner Einblick: Ein neues Publish-Subscribe-Modell wurde basierend auf Events und Delegates umgesetzt. In klassischem COM basiert dieses auf Events und Sinks. Es wurden Interfaces mit Parametern eingeführt. Wenn die verwendete Sprache diese unterstützt, werden sie dort»hineinprojiziert«. Bei C# kommen dafür die Generics zum Einsatz. Bei klassischen COM sind die Interfaces in Type Libraries (.tlb) definiert. Das erweiterte COM der WinRT nutzt dafür die auf.net basierenden Metadaten in.winmd-dateien. Falls Sie tiefer in die COM-Welt bei der WinRT reinschauen möchten, sollten Sie sich die.idl-dateien (Interface Definition Language) im Pfad C:\Program Files (x86)\ Windows Kits\8.0\Include\WinRT ansehen. Dort finden Sie beispielsweise die Datei windows.ui.xaml.controls.idl mit den Definitionen für die Controls. Dabei sehen Sie auch, wie die COM-Interfaces mit dem exlusiveto-attribut exklusiv auf Klassen gemappt werden. So ist beispielsweise das Interface IButton exklusiv für die Klasse Button definiert. [uuid(280335ae c7-8e0b-602be71229a2)] [version(0x )] [exclusiveto(windows.ui.xaml.controls.button)] interface IButton : IInspectable { } 50

13 1.3 Die Windows Runtime (WinRT) Von»früher«über COM und.net zur WinRT Ende der 80er, Anfang der 90er Jahre sah die Programmierung ungefähr wie in Abbildung 1.9 dargestellt aus: unten das Herz von Windows, der Windows Kernel; darüber die für Programmierer verfügbare Schnittstelle Win32. C++-Entwickler bauten mit ihren Compilern native Bibliotheken, aus denen sie die Funktionen der Win32-API aufriefen. Auch VB-Programmierer bauten native Bibliotheken, und in irgendwelchen anderen Sprachen wurden ebenfalls native Bibliotheken entwickelt, die auf die Win32-API zugriffen. 1 C++ VB andere Sprachen Compiler Compiler Compiler nativer Code Runtime, Bibliotheken nativer Code Runtime, Bibliotheken nativer Code Runtime, Bibliotheken Windows API (Win32) Windows Kernel Abbildung 1.9 Früher wurden zahlreiche Insellösungen produziert. Mit jeder Sprache wurden Insellösungen entwickelt. Die großen Fragen, die man sich zu der in Abbildung 1.9 dargestellten Architektur stellte, waren folgende: Wie kann eine in C++ entwickelte Bibliothek auf Funktionen einer in VB geschriebenen Bibliothek zugreifen? Wie kann eine Insellösung von den Innovationen profitieren, die in einer anderen Insellösung stattfinden? Anfang der 90er Jahre brachte Microsoft mit dem Component Object Model (COM) nicht nur die Antworten, sondern auch gleich die Lösung zu diesen Fragen. COM erlaubt es einer nativen Bibliothek, ihre Funktionen über ein binäres Interface der Außenwelt zur Verfügung zu stellen. Dieses binäre Interface entspricht einem standardisierten Format. Es wird in der Interface Definition Language (IDL) erstellt und ist in einer Type Library (.tlb-datei) gespeichert. Über diese Interfaces können mit C++ entwickelte Bibliotheken plötzlich mit in VB entwickelten Bibliotheken sprechen. Es ergibt sich das in Abbildung 1.10 dargestellte Bild. 51

14 1 Einführung in Windows 8, WinRT und.net C++ VB andere Sprachen Compiler Compiler Compiler nativer Code Runtime, Bibliotheken nativer Code Runtime, Bibliotheken nativer Code Runtime, Bibliotheken Component Object Model (COM) Windows API (Win32) Windows Kernel Abbildung 1.10 COM lässt die unterschiedlichen Bibliotheken über binäre Interfaces miteinander»sprechen«. Hinweis Bei COM implementiert jede Komponente das Interface IUnknown. Dieses besitzt die Methode QueryInterface, mit der sich die von der Komponente implementierten Interfaces abfragen lassen. Darüber hinaus definiert das Interface die Methoden AddRef und Release. Mit diesen Methoden wird der Referenzzähler hoch- und heruntergezählt. Bei COM wird die Lebenszeit von Objekten über diesen Referenzzähler gesteuert und nicht wie bei.net über den Garbage Collector. COM ermöglichte die Entwicklung von wiederverwendbaren Komponenten über mehrere Programmiersprachen hinweg. Eine COM-Komponente wird dazu in der Registry mit einer eindeutigen ID (GUID) eingetragen. Die Komponente wird von anderen Bibliotheken nicht über den Pfad, sondern über den entsprechenden Eintrag in der Registry gefunden. COM-Komponenten werden daher auch als ortsunabhängig bezeichnet, da sie mit Hilfe einer GUID aufgefunden werden. Mit COM+ und DCOM erschienen noch reichhaltigere Technologien. Auch das Object Linking and Embedding (OLE) basiert auf COM. Damals war es erstmals möglich, in Word ein Excel-Spreadsheet einzubinden, das in Excel getätigte Änderungen direkt widerspiegelt. Auch ActiveX basiert auf COM. Mit ActiveX lassen sich COM-Komponenten im Browser nutzen. 52

15 1.3 Die Windows Runtime (WinRT) Obwohl mit COM eine komponentenbasierte Entwicklung möglich war, tauchten auch mit COM ungeahnte Herausforderungen auf. Hier nur einige davon: COM ist kein nativer Teil der Sprachen. Innerhalb einer C++-Komponente lassen sich alle Sprachfeatures von C++ nutzen. Ein separater Wrapper ist notwendig, um C++-Typen den COM-Typen zuzuordnen. Die Versionsunterstützung von Komponenten wurde nicht durchdacht. Dies führte zur sogenannten»dll-hölle«: Wird eine neue Version einer Komponente registriert, enthält die Registry unter derselben GUID eine neue DLL, eventuell mit einem leicht geänderten Interface. Existierender Code, der die COM-Komponente nutzt, erzeugt plötzlich Fehler, da die aufgerufenen Funktionen im neuen Interface nicht mehr gefunden werden. 1 Neben diesen Problemen mit COM gab es für Microsoft einen weiteren wichtigen Punkt: die 1996 erschiene Sprache Java. Java wurde von Anfang an zum Programmieren von komponentenbasierter Software entwickelt. Zudem war Java plattformunabhängig und mit vielen Funktionen wie Java-Applets auch bereit für das boomende Internet. Gegen die moderne, objektorientierte Sprache Java wirkte COM alt und schwerfällig. Microsoft erkannte die Probleme und brachte im Jahr 2002 das bis heute sehr erfolgreiche.net Framework heraus. Abbildung 1.11 zeigt die Architektur unter Windows mit dem.net Framework. C# VB.NET andere Sprachen C++ (CLI) Compiler Microsoft Intermediate Language (MSIL) Bibliothek.NET Framework JIT Common Language Runtime (CLR) nativer Code Windows-API (Win32) Windows Kernel Abbildung 1.11 Das.NET Framework unterstützt verschiedene Sprachen. 53

16 1 Einführung in Windows 8, WinRT und.net Das.NET Framework besteht aus der Laufzeitumgebung namens Common Language Runtime (CLR) und einer umfangreichen Klassenbibliothek. Die CLR selbst enthält Features wie Garbage Collection, Exception Handling oder auch den Just-in-Time Compiler (JIT)..NET-Bibliotheken, sogenannte Assemblies, liegen in der Microsoft Intermediate Language vor. Diese Zwischensprache wird üblicherweise mit ihrer Abkürzung MSIL oder einfach nur als IL bezeichnet. Es wird bei der IL auch von Managed Code gesprochen, da der Code von der CLR verwaltet (»gemanagt«) wird. Aus verschiedenen Hochsprachen wie C#, VB und auch C++ lassen sich.net-assemblies kompilieren. Diese werden dann zur Laufzeit mit dem JIT in nativen Code kompiliert und von der CLR ausgeführt. Aufgrund der IL lässt sich aus C# einfach eine in VB entwickelte Assembly nutzen, da diese ebenfalls in der IL vorliegt. Darüber hinaus lassen sich die Assemblies mit einer Version versehen und auf einem Rechner in einem Verzeichnis namens Global Assembly Cache (GAC) unterbringen. Jede Assembly kennt die Versionen der von ihr referenzierten Assemblies, womit die unter COM existierende»dll-hölle«mit.net der Vergangenheit angehört. Mit dem.net Framework hat Microsoft ein solides Konzept zum Entwickeln von komponentenorientierter Software auf den Markt gebracht..net unterstützt sehr viele Sprachen, so auch C++. Wird C++ mit.net verwendet, kommt eine von Microsoft entwickelte Variante der Programmiersprache namens C++/CLI zum Einsatz. CLI steht dabei für»common Language Infrastructure«. In C++/CLI entwickelte Programme lassen sich als.net-assemblies in IL-Code kompilieren. Obwohl sich mit C++.NET-Assemblies erstellen lassen, wählen eingefleischte C++-Entwickler lieber den Weg ohne.net; sie erstellen nativen Code. Der meistgenannte Grund ist dabei die bessere Performanz. Insbesondere für 3D-Applikationen und Spiele ist das.net Framework nicht geeignet, da native C++-Anwendungen mit DirectX hier die beste Leistung bringen. Doch nicht nur im Spielebereich ist C++ interessant, auch für Geschäftsanwendungen gibt es immer noch Firmen, die mit den Microsoft Foundation Classes (MFC) und C++ nativen Code erstellen. Dennoch muss man sagen, dass.net-anwendungen mit WPF und Windows Forms weitaus verbreiteter sind. Obwohl das.net Framework alle Probleme von COM löst, fallen Ihnen beim Betrachten von Abbildung 1.11 eventuell doch noch ein paar nicht ganz optimale Details auf: Für neue Funktionen in der Win32-API sind.net-wrapper notwendig. Gibt es neue Funktionen in der Win32-API, erwarten.net-entwickler für diese nativen Funktionen immer eine.net-assembly als Wrapper. Diese Wrapper-Assembly enthält dann in.net geschriebene P/Invoke-(Plattform/Invoke-)Deklarationen zum Aufruf der Win32-Funktionen. Das heißt in anderen Worten, sobald in Win32 etwas dazukommt, muss jemand für.net die Wrapper schreiben. 54

17 1.3 Die Windows Runtime (WinRT) C++-Entwickler, die nativen Code kompilieren, profitieren nicht von den Innovationen im.net Framework. Im.NET Framework gibt es viele interessante Technologien, die eben für.net-assemblies zugänglich sind. Beispielsweise enthält das.net Framework mit der WPF eine sehr mächtige UI-Bibliothek. Ein C++-Programmierer kann diese Bibliothek nicht nutzen, wenn er weiterhin nativen Code kompilieren möchte. 1 Halten wir fest: Für neue Win32-Funktionen müssen immer wieder Wrapper geschrieben werden, die diese Funktionen für.net zur Verfügung stellen. Darüber hinaus profitieren die C++-Entwickler, die nativen Code kompilieren möchten, nicht von den im.net Framework stattfindenden Innovationen. Erweitert man die Sicht von.net- und C++-Entwicklern noch auf die Entwickler von Web-Anwendungen, ergibt sich das in Abbildung 1.12 dargestellte Bild..NET- Sprachen C++ (CLI) Compiler HTML/CSS/JavaScript MSIL Bibliothek JavaScript-Bibliotheken.NET Framework JIT CLR nativer Code Internet Explorer Windows API (Win32) Windows Kernel Abbildung 1.12 Die Desktop-Welt mit.net-, C++- und Web-Anwendungen Microsoft möchte zum Entwickeln von Windows Store Apps C++-Entwicklern wieder die gleichen Möglichkeiten wie C#/VB-Entwicklern bieten. Zudem möchten sie die JavaScript-Entwickler ebenfalls mit ins Boot holen. Wenn Sie Abbildung 1.12 genau betrachten, fällt Ihnen auf, dass der für dieses Ziel kleinste gemeinsame Nenner die Windows-API ist. Dass die existierende Win32-API weder modern noch objektorientiert ist, war sicher einer der Gründe, dass Microsoft mit der WinRT in Windows 8 eine komplett neue Windows-API eingeführt hat, die neben der Win32-API lebt. Schauen wir uns die Architektur näher an. 55

18 1 Einführung in Windows 8, WinRT und.net Die Architektur der WinRT Die WinRT ist in nativem Code geschrieben und nutzt das Beste aus der COM- und der.net-welt: COM-basierte, binäre Interfaces (Application Binary Interface): Dadurch können Komponenten unterschiedlicher Sprachen miteinander reden..net-metadaten: Sie beschreiben die Inhalte einer Komponente..NET-Konzepte: Die WinRT nutzt viele.net-konzepte, wie Namespaces, Klassen, Methoden, Properties, Events, Delegates etc. COM als natürlicher Teil jeder Sprache. Bisher werden C++, C#/VB und JavaScript unterstützt. Die Architektur der WinRT ist in Abbildung 1.13 dargestellt. Bevor wir in den folgenden Abschnitten einzelne Teile genauer betrachten, werfen wir einen kurzen Blick darauf. Windows Store App Language Projection Language Support (CLR, WinJS, CRT) Windows Metadata & Namespaces UI Pickers Controls Media XAML Storage Network... Windows Runtime Core Webhost (HTML, CSS, JavaScript) Runtime Broker Windows Kernel Abbildung 1.13 Die Architektur der WinRT Im unteren Teil von Abbildung 1.13 ist der Windows Kernel. Darauf baut die WinRT auf. Sie besteht aus den folgenden Teilen: Windows Runtime Core: Der Kern der WinRT; er enthält viele Low-Level-Funktionen wie beispielsweise die Speicherverwaltung. Windows-Metadaten & Namespaces: Die im.net-format gespeicherten Metadaten der WinRT ordnen die WinRT-Klassen in Namespaces ein. Mehr zu den Metadaten lesen Sie in Abschnitt

19 1.3 Die Windows Runtime (WinRT) XAML, Storage, Network...: Die WinRT enthält volle Unterstützung für XAML als UI-Beschreibungssprache. Sie enthält zudem Klassen zum Speichern von Daten, Network-Klassen zur Kommunikation mit Services etc. Einen Überblick dieser Teile erhalten Sie, wenn wir in Abschnitt 1.3.8,»Übersicht der Namespaces«, die Namespaces betrachten. Runtime Broker: Der Aufruf bestimmter WinRT-APIs läuft über den Runtime Broker. Dieser prüft, ob eine App eine bestimmte WinRT-API überhaupt aufrufen darf, denn standardmäßig laufen Windows Store Apps in einer Art Sandbox ab. Mehr dazu erfahren Sie in Abschnitt 1.3.7,»Sandbox und Broker«. Webhost: Wird die Windows Store App mit HTML/CSS/JavaScript entwickelt, wird sie im Webhost ausgeführt. Der Webhost weiß, wie HTML-Seiten gerendert werden und der darin enthaltene JavaScript-Code ausgeführt wird. Language Support: Die WinRT unterstützt verschiedene Sprachen. Für C#/VB steht dabei eine Untermenge von.net und somit die CLR zur Verfügung. Für Java- Script gibt es die WinJS-Bibliothek und für C++ die C Runtime Libraries (CRT). Language Projection: Durch die»sprachprojektion«fühlen sich die WinRT-APIs immer an, als ob sie Teil der Sprache sind, in der sie genutzt werden. So starten die Methodennamen von WinRT-Klassen in JavaScript mit einem kleinen Buchstaben, in C# dagegen mit einem großen. Nähere Einzelheiten finden Sie in Abschnitt 1.3.6,»Language Projection«. 1 In den folgenden Abschnitten werfen wir einen detaillierteren Blick auf die wichtigsten Teile der WinRT. Anschließend finden Sie einen Überblick der Namespaces und lernen die Stärken der integrierten UI-Bibliothek mit XAML kennen Language Support Die WinRT unterstützt verschiedene Sprachen zum Entwickeln von Windows Store Apps: XAML mit C#/VB: Nutzt das.net für Windows Store Apps. XAML mit C++: Basiert auf nativem Code. DirectX mit C++: Basiert auf nativem Code. HTML mit JavaScript: Nutzt die Chakra-Engine kompiliert JavaScript just in time und die WinJS-Bibliothek. Abbildung 1.14 zeigt einen Ausschnitt der bereits gezeigten Architektur unter Windows 8. Sie finden darin die erwähnten Möglichkeiten. Beim Entwickeln mit C# kommt das.net für Windows Store Apps zum Einsatz. Diese Untermenge des.net Frameworks lernen Sie nach den folgend betrachteten Details zur WinRT näher kennen. 57

20 1 Einführung in Windows 8, WinRT und.net Windows Store Apps View XAML DirectX HTML/CSS Model Controller C#/VB.NET für Windows Store Apps C++/CX JavaScript Chakra/ WinJS Windows Runtime (WinRT) APIs Windows Kernel Abbildung 1.14 Die unterstützten Sprachen in der WinRT Metadaten Die WinRT basiert auf einem erweiterten COM und stellt ihre Funktionen über Metadaten bereit. Diese Metadaten verwenden dasselbe Format wie die.net-metadaten. Da die Bibliotheken der WinRT nativ implementiert sind, können sie die Metadaten nicht direkt enthalten. Sie sind daher in separaten.winmd-dateien (»winmd«steht für»windows Metadata«) gespeichert. Die.winmd-Dateien finden Sie auf Ihrem Rechner in folgendem Verzeichnis: C:\Windows\System32\WinMetadata. Da die Metadaten der WinRT das Format der.net- Metadaten nutzen, lassen sie sich auch mit den bekannten.net-tools betrachten. Typischerweise wird zum Anschauen der Metadaten der Intermediate Language Disassembler (IL DASM) genutzt. Der IL DASM wird mit Visual Studio installiert. Hinweis Zum Starten des IL DASM öffnen Sie am besten eine Developer-Eingabeaufforderung, die ebenfalls mit Visual Studio installiert wird. Durchsuchen Sie dazu einfach Ihre Apps unter Windows 8 nach»developer«. In der Developer-Eingabeaufforderung tippen Sie ildasm ein, und das Tool öffnet sich. In Abbildung 1.15 wird im IL DASM die Datei Windows.UI.Xaml.winmd geöffnet. Beachten Sie auch die anderen.winmd-dateien im WinMetadata-Verzeichnis. 58

21 1.3 Die Windows Runtime (WinRT) 1 Abbildung 1.15 Die».winmd«-Dateien der WinRT Abbildung 1.16 zeigt die geöffnete Datei Windows.UI.Xaml.winmd. Der Namespace Windows.UI.Xaml.Controls ist aufgeklappt, womit die darin enthaltenen Klassen wie AppBar, Border und Button zu erkennen sind. Abbildung 1.16 Die Datei»Windows.UI.Xaml.winmd«im Intermediate Language Disassembler (IL DASM) 59

22 1 Einführung in Windows 8, WinRT und.net Da die WinRT dasselbe Metadaten-Format wie.net verwendet, lässt sich auch in Windows Store Apps Reflection verwenden, um zur Laufzeit diese Metadaten auszulesen. Hinweis In den Metadaten lassen sich Typen und Assemblies mit einem neuen Intermediate- Language-(IL-)Schlüsselwort namens windowsruntime versehen. Dieses Schlüsselwort legt fest, dass der Typ eine WinRT-Komponente ist. Das Schlüsselwort ist auch in Abbildung 1.16 zu sehen..net erkennt anhand dieses Schlüsselwortes, dass es die Parameter umwandeln muss (Marshalling), da das WinRT-Typsystem nicht dasselbe Typsystem ist wie jenes von.net. Dies geschieht allerdings alles automatisch im Hintergrund. Beim Entwickeln in C# müssen Sie sich keine Sorgen darüber machen, wie ihr C#-String in den entsprechenden WinRT-HSTRING umgewandelt wird es geschieht automatisch Language Projection Die WinRT selbst ist sprachneutral. Darüber hinaus hat die WinRT ein sprachneutrales Typensystem. Über sogenannte Language Projections (»Sprachprojektionen«) werden die APIs der WinRT in die Sprachen C#, VB, C++ und JavaScript projiziert. Durch die Language Projection wirkt die WinRT in jeder Sprache wie ein natürlicher Bestandteil. So beginnen Methoden in C# mit einem Großbuchstaben, in JavaScript mit einem Kleinbuchstaben. Ebenso werden Collection-Typen der WinRT in Collection-Typen der verwendeten Sprache projiziert. Dadurch lassen sich in C++ die Collections der Standard Library nutzen, in C#/VB die typischen.net-collections wie List<T>. Hinweis Welche WinRT-Typen auf welche.net-typen gemappt werden, lesen Sie in Abschnitt 1.4.6,»Die WinRT und.net im Zusammenspiel«. Abbildung 1.17 verdeutlicht die Language Projection; links das WinRT-Objekt, dazwischen die Metadaten und auf der rechten Seite die Language Projection für die verschiedenen Programmiersprachen. Bei C#/VB sitzt zwischen der Language Projection und der App noch die CLR, bei JavaScript die JavaScript-Engine Chakra. Schauen wir uns ein kleines Beispiel für die Language Projection an. In Abbildung 1.18 wird dazu in JavaScript ein FileOpenPicker-Objekt erstellt. Dabei handelt es sich um eine WinRT-Klasse. Zur filetypefilter-eigenschaft des Pickers wird der String.png hinzugefügt. Via IntelliSense wird zudem die picksinglefileasync-methode ausgewählt. 60

23 1.3 Die Windows Runtime (WinRT) WinRT- Objekt Projection C++-App 1 oder -Komponente geschrieben in C#, VB oder C++ Windows- Metadaten Projection Projection CLR Chakra C#/VB-App JavaScript- App Abbildung 1.17 Die Language Projection für die verschiedenen Sprachen Abbildung 1.18 In JavaScript beginnen die Methoden der WinRT mit einem Kleinbuchstaben. Beachten Sie in Abbildung 1.18 Folgendes, bevor wir uns dieses Codefragment in der C#-Version anschauen: Properties und Methoden beginnen mit einem Kleinbuchstaben. Zum Hinzufügen eines Filters wird die in JavaScript übliche append-methode aufgerufen. Abbildung 1.19 zeigt die C#-Variante. Wie Sie sehen, beginnen die Properties und Methoden in C# mit einem Großbuchstaben. Zum Hinzufügen eines Filters wird nicht wie in JavaScript die append-methode, sondern die für C# übliche Add-Methode aufgerufen. 61

24 1 Einführung in Windows 8, WinRT und.net Abbildung 1.19 In C# beginnen die Methoden der WinRT mit einem Großbuchstaben. Aus dem Code in Abbildung 1.19 geht nicht hervor, ob es sich beim FileOpenPicker tatsächlich um eine WinRT-Klasse oder doch nur um eine.net-klasse handelt. Es ist natürlich eine WinRT-Klasse. Die Language Projection sorgt dafür, dass diese WinRT- Klasse sich in C# wie eine.net-klasse anfühlt. Hinweis Da die WinRT selbst sprachneutral ist, sind natürlich weitere Language Projections möglich. Dadurch sind in Zukunft neben C#, VB, C++ und JavaScript weitere Sprachen denkbar, in denen sich Windows Store Apps entwickeln lassen. Technisch geschieht dabei vieles über das Interface IInspectable, das direkt von COMs IUnknown erbt. IInspectable ist das Basis-Interface aller WinRT-Klassen. Das Interface erlaubt einer Klasse, sich selbst in andere Sprachumgebungen zu projizieren Sandbox und Broker Windows Store Apps werden in einer Art Sandbox ausgeführt. Rufen Sie aus Ihrer App WinRT-Funktionen auf, gibt es zwei Arten davon: Direkt an Windows weitergegebene Aufrufe. Dabei handelt es sich um keine sicherheitsrelevanten Aufrufe. Vom Runtime Broker der WinRT übermittelte Aufrufe. Hier handelt es sich um sicherheitsrelevante Aufrufe, wie beispielsweise ein Zugriff auf die Kamera. Abbildung 1.20 verdeutlicht den Sachverhalt. Links sehen Sie Ihre App. Aus dem Anwendungsprozess folgen Aufrufe von WinRT-APIs. Die WinRT greift dann entweder direkt auf Windows zu oder nutzt für sicherheitsrelevante APIs ihren Runtime Broker als Vermittler. 62

25 1.3 Die Windows Runtime (WinRT) Windows Store App Process.exe WinRT- APIs Direkte API-Aufrufe Sicherheitsrelevante API-Aufrufe Broker Windows Kernel 1 Abbildung 1.20 Sicherheitsrelevante API-Aufrufe werden vom Broker übermittelt. Eine typische WinRT-API, die über den Runtime Broker läuft, ist der Zugriff auf die Kamera. Abbildung 1.21 zeigt den Zugriff auf die Kamera aus der FriendStorage-App. Der Runtime Broker sorgt für eine Abfrage beim Benutzer, bevor er tatsächlich den Zugriff auf die Kamera zulässt. Abbildung 1.21 Der Runtime Broker lässt den Zugriff auf die Kamera nur zu, wenn der Benutzer diesem für die geöffnete App auch zustimmt. Hinweis Eine Windows Store App muss mitteilen, welche sicherheitsrelevanten APIs sie nutzen möchte. Dazu gehört der Zugriff auf die Webcam, das Mikrofon, das Internet, die Bibliotheken des Benutzers (Dokumente, Bilder, Videos) und vieles mehr. Der Benutzer sieht dann diese benötigten Funktionen im Windows Store, bevor er die App kauft. Mehr dazu lesen Sie in Kapitel 2,»Das Programmiermodell«, bei einem Blick auf die Funktionen in der Package.appxmanifest-Datei. 63

26 1 Einführung in Windows 8, WinRT und.net Übersicht der Namespaces Die Klassen der WinRT sind in Namespaces eingeordnet. Diese beginnen bei der WinRT mit Windows. Tabelle 1.1 zeigt einige der Namespaces. Endet ein Namespace mit einem *, bedeutet dies, dass es noch zahlreiche Sub-Namespaces gibt. Namespace Windows.ApplicationModel.* Windows.Data.Json Windows.Data.Xml.* Windows.Devices.* Windows.Foundation.* Windows.Graphics.* Windows.Media.* Windows.Networking.* Windows.Security.* Beschreibung Bietet alles rund um die Applikation, etwa: Ist sie im Designer geöffnet? Wie lautet die Version des App- Pakets? In Sub-Namespaces gibt es viel weitere Funktionalität, beispielsweise um Daten via Charms Bar mit anderen Anwendungen zu teilen. Enthält Basisfunktionalität zum Parsen von JSON- Daten. Alles Notwendige zum Durchlaufen von XML-Dokumenten oder zum Ausführen von XSLT-Code finden Sie hier. In diesen Sub-Namespaces ist der Zugriff auf diverse Geräte definiert. Enthält Basisfunktionalitäten der WinRT. So befinden sich darin Klassen, die die asynchrone Programmierung unterstützen. Auch Collection-Interfaces der WinRT, die durch die Language Projection auf.net-typen gemappt werden, sind hier zu finden. Mehr zu diesen Mappings in Abschnitt 1.4.6,»Die WinRT und.net im Zusammenspiel«. Benötigen Sie Informationen über den physischen Bildschirm oder möchten Sie Bitmaps kodieren/ dekodieren, sind Sie hier richtig. Mehr zu den Bitmap-Operationen in Kapitel 19,»2D-Grafik«. Enthält u.a. Klassen, um ein Bild oder ein Video über die Webcam aufzunehmen. Alles, was Sie brauchen, um Daten im Hintergrund zu laden, via Sockets zu kommunizieren und vieles mehr. Klassen für Authentifizierung, Zertifikate, Verschlüsselung etc. Tabelle 1.1 Wichtige Namespaces der WinRT 64

27 1.3 Die Windows Runtime (WinRT) Namespace Windows.Storage.* Windows.System.* Beschreibung Zum Speichern/Lesen von Dateien, zum Komprimieren von Dateien, zum Auslesen von Dateieigenschaften oder zum Anzeigen eines FileOpenPickers sollten Sie hier nachschauen. Mehr dazu in Kapitel 13,»Dateien, Streams und Serialisierung«. Im Sub-Namespace UserProfile finden Sie Benutzerinformationen. Im Sub-Namespace Threading sind die Core-Threading-Klassen der WinRT. 1 Tabelle 1.1 Wichtige Namespaces der WinRT (Forts.) Die meisten Klassen, die Sie für Ihre mit XAML und C# entwickelte Oberfläche nutzen, finden Sie in Namespaces, die mit Windows.UI.Xaml beginnen. Diese sind in Tabelle 1.2 dargestellt. Bedenken Sie, dass all diese Teile in nativem Code in der WinRT implementiert sind. Namespace Windows.UI.Xaml.Controls Windows.UI.Xaml.Controls. Primitives Windows.UI.Xaml.Data Windows.UI.Xaml.Documents Windows.UI.Xaml.Input Windows.UI.Xaml.Markup Windows.UI.Xaml.Media.* Beschreibung Hier finden Sie die Controls für Ihre App wie Button, CheckBox, ListView oder AppBar. Mehr zu den Controls lesen Sie in Kapitel 4,»Controls«. Enthält einfachere Elemente, aus denen die Controls bestehen. Um Ihre XAML-Oberfläche an Daten zu binden, finden Sie in diesem Namespace die entsprechenden Daten-Klassen. Enthält Klassen zum Formatieren von Text, wie Bold, Italic oder Underline. Definiert die ganze Infrastruktur für Benutzereingaben. Definiert ein paar Klassen für die XAML-Unterstützung, wie beispielsweise das ContentProperty- Attribute. Mehr dazu in Kapitel 3,»XAML«. Brushes, Geometrie-Objekte oder Transformationen sind in diesem Namespace zu finden. Sub-Namespaces unterstützen die Darstellung von Bitmaps und die Ausführung von Animationen. Tabelle 1.2 Die wichtigsten UI-Namespaces der WinRT 65

28 1 Einführung in Windows 8, WinRT und.net Namespace Windows.UI.Xaml.Navigation Windows.UI.Xaml.Printing Windows.UI.Xaml.Shapes Beschreibung Enthält Klassen für Navigations-Events, die beim Verwenden der Klassen Page und Frame zum Einsatz kommen. Mehr dazu in Kapitel 2,»Das Programmiermodell«. Enthält die PrintDocument-Klasse, mit der sich Inhalte an den Drucker senden lassen. Enthält einfache Formen wie Rectangle oder Ellipse. Tabelle 1.2 Die wichtigsten UI-Namespaces der WinRT (Forts.) Tipp Wenn Sie bereits mit der WPF oder mit Silverlight Anwendungen entwickelt haben, sollten Ihnen die Namespaces ziemlich bekannt vorkommen. In der WPF/Silverlight beginnen die UI-Namespaces mit System.Windows. Es gibt dort auch Sub-Namespaces wie System.Windows.Controls, System.Windows.Data, System.Windows.Documents oder System.Windows.Input. Falls Sie Teile Ihrer WPF/Silverlight-Anwendung in Ihre neue Windows Store App migrieren möchten, benennen Sie somit die Namespaces beginnend mit System.Windows einfach in Windows.UI.Xaml um. Die darin enthaltenen Klassen sind meist ähnlich oder sogar gleich Die Stärken der UI-Technologie mit XAML Die UI-Bibliothek der WinRT bietet mit den Klassen aus den mit Windows.UI.Xaml beginnenden Namespaces viele Stärken. Diese Stärken sind bereits aus der WPF und Silverlight bekannt und in Tabelle 1.3 dargestellt. Eigenschaft flexibles Inhaltsmodell Beschreibung Die WinRT besitzt ein flexibles Inhaltsmodell. Dies bedeutet, dass ein Button und auch viele andere visuelle Elemente einen beliebigen Inhalt haben können. Beispielsweise ist es möglich, in einen Button ein Layout-Panel zu setzen und darin wiederum mehrere andere Controls zu platzieren. Ihrer Kreativität können Sie freien Lauf lassen, um das gewünschte Design zu finden. In Kapitel 4,»Controls«, lesen Sie mehr über die Subklassen von ContentControl und ItemsControl, die das flexible Inhaltsmodell unterstützen. Tabelle 1.3 Die Stärken der UI-Bibliothek der WinRT 66

29 1.3 Die Windows Runtime (WinRT) Eigenschaft Layout Styles Templates Daten Animationen und Transitions Beschreibung Die WinRT besitzt einige Layout-Panels, um Controls in einer Anwendung dynamisch anzuordnen und zu positionieren. Aufgrund des flexiblen Inhaltsmodells lassen sich die Layout- Panels der WPF auch beliebig ineinander verschachteln, wodurch Sie in Ihrer Anwendung auch ein sehr komplexes Layout erstellen können. Ein Style ist eine Sammlung von Eigenschaftswerten. Diese Sammlung lässt sich einem oder mehreren Elementen der Benutzeroberfläche zuweisen, wodurch deren Eigenschaften dann die im Style definierten Werte annehmen. Sie definieren einen Style üblicherweise als Ressource, um ihn beispielsweise mehreren TextBox-Elementen zuzuweisen, die alle die gleiche Hintergrundfarbe und die gleiche Breite haben sollen. Ohne Styles müssten Sie auf jeder TextBox diese Properties setzen. Mit Styles werden die Werte automatisch gesetzt. Das Aussehen eines Controls wird mit einem ControlTemplate beschrieben. Durch Ersetzen des ControlTemplates (durch Setzen der Template-Property der Klasse Control) lässt sich das komplette Aussehen eines Controls anpassen. Das Erstellen einer Subklasse ist dazu nicht notwendig. Die Elemente in Ihrer Applikation können Sie mit Data Binding an verschiedene Datenquellen binden. Dadurch ersparen Sie sich die Programmierung von Event Handlern, die die Benutzeroberfläche oder die Datenquelle bei einer Änderung aktualisieren. Neben dem Data Binding können Sie mit Data Templates das Aussehen Ihrer Daten auf der Benutzeroberfläche definieren. Mit dem integrierten System für Animationen und Transitions (Übergänge) unterstützt Sie die WinRT beim Gestalten von»flüssigen«windows Store Apps. 1 Tabelle 1.3 Die Stärken der UI-Bibliothek der WinRT (Forts.) Eine weitere Stärke ist, dass die WinRT XAML nutzt, wodurch der Prozess zwischen Entwickler und Designer besser unterstützt wird. Ein Designer kann im Programm Blend eine in XAML definierte Oberfläche»polieren«und anschließend wieder dem Entwickler überreichen, der in Visual Studio weiterprogrammiert. Mehr zu diesem Prozess am Anfang von Kapitel 3,»XAML«. 67

30 1 Einführung in Windows 8, WinRT und.net 1.4.NET für Windows Store Apps Beim Entwickeln von Windows Store Apps mit C#/VB kommt eine Untermenge des.net Frameworks 4.5 zum Einsatz: Das.NET für Windows Store Apps. Abbildung 1.22 verdeutlicht diese Untermenge..NET Framework 4.5 Windows Phone.NET für Windows Store Apps Silverlight 5 Abbildung 1.22 Das.NET für Windows Store Apps stellt eine Untermenge des.net Frameworks 4.5 dar. Microsoft bezeichnet eine Untermenge des»großen«.net Frameworks als Profil. Es gibt noch weitere Profile, wie Abbildung 1.22 zeigt: Silverlight und Windows Phone. Mit Visual Studio 2012 lassen sich sogenannte portable Klassenbibliotheken erstellen. In einer solchen Bibliothek steht genau die Schnittmenge der ausgewählten Profile zur Verfügung. Dies hat den Effekt, dass sich die Bibliothek in unterschiedlichen Profilen nutzen lässt. Mehr zur portablen Klassenbibliothek lesen Sie in Kapitel 2,»Das Programmiermodell«, beim Betrachten der Vorlagen von Visual Studio. Hinweis In.NET 4.0 existierte noch das sogenannte Client Profile, das ebenfalls eine für Desktop-Anwendungen geeignete Untermenge darstellte. Darin fehlten beispielsweise sämtliche Klassen für ASP.NET. In.NET 4.5 gibt es dieses Client Profile nicht mehr. Beim.NET für Windows Store Apps wurden einige aus.net 4.5 bekannte Klassen entfernt. Gründe dafür sind, dass die entsprechende Funktionalität entweder in der WinRT zu finden ist oder in Windows Store Apps einfach nicht gebraucht wird. Manche Teile wurden auch leicht geändert. Nachfolgend betrachten wir die Architektur des.net für Windows Store Apps, bevor wir genauer hinschauen, was in die WinRT 68