Entwicklung Einer Windows Phone 7 Applikation Unter Verwendung Moderner Imperativer Und Funktionaler Sprachelemente

Masterarbeit
Entwicklung einer Windows Phone 7 Applikation unter Verwendung moderner imperativer und funktionaler Sprachelemente
Zur Erlangung des akademischen Grades eines Master of Science - Media Processing and Interactive Services -
Fakultt Informatik Referent: Prof. Dr. Oliver Braun Korreferent: Dipl.-Mathematiker Michael Otto eingereicht von: Ronny Schleicher Matr.-Nr. 290723 Obertor 6 98590 Rodorf Schmalkalden, den 24.09.2011
Zusammenfassung Mit dem Windows Phone 7 bietet Microsoft eine neue Smartphone-Generation an, die sich von den bisherigen Konzepten der Windows Mobile Serie komplett unterscheidet. Der Schritt von ehemals fast reinen Businessgerten, die bis auf wenige Ausnahmen selten den Weg zum Endkunden gefunden haben, hin zu ConsumerGerten fr den einfachen Benutzer, und damit einem sehr viel breiterem Marktsegment, scheint damit vollzogen. Bei solch einem Kurswechsel ist es nicht nur ntig die Hard- und Software endkundenfreundlich zu gestalten. Auch ein neues Entwicklungskonzept fr Anwendungssoftware muss dabei Bestandteil des Kurswechsels sein. Das ist mit dem Windows Phone 7 passiert. In dieser Arbeit wird das Entwicklungskonzept des Windows Phone 7 im Bereich gebotenen der Hard- und Software untersucht. Ein Schwerpunkt ist das Prfen der Verfgbarkeit und Anwendbarkeit moderner imperativer und funktionaler Sprachelemente. Diese Konzepte werden in dieser Arbeit untersucht und vorgestellt. Um bei der Analyse der durch das Windows Phone 7 und dessen Software gebotenen Entwicklungsmglichkeiten den praktischen Nutzen zu prfen, wurde im Rahmen dieser Arbeit eine Windows Phone 7 Applikation entwickelt, die einen Cloud-Service der FH-Schmalkalden nutzt. Im Rahmen dieser Entwicklung wurden die imperative und funktionaler Sprachelemente nicht nur theoretisch analysiert, sondern auch in einem praktischen Kontext eingesetzt, um sich ein ganzheitliches Bild des Windows Phone 7 in Bezug auf Aspekte der modernen Softwareentwicklung zu verschaen.
Danksagung Zu allererst mchte ich den Personen meiner Arbeitsgruppe danken, die mit mir das Gemeinschaftsprojekt FHS-Spirit bearbeitet haben. Benjamin Ldicke, der sich fr den REST-Service verantwortlich zeigte und viele tolle Ideen und Mglichleiten einbrachte, um unsere gemeinsame Aufgabe zu realisieren. Florian Schuhmann, der den Web-Service bearbeitete und darber hinaus noch viele andere Aufgaben bernahm, wie das Erstellen der Latex-Vorlage, die in dieser Arbeit verwendet wurde. Sebastian Stallenbergen, der im Bereich der Android-Applikation ttig war und mit dem gerade die Fragestellungen zu mobilen Endsystemen, die auch Bestandteil meiner Arbeit waren, diskutiert und gelst werden konnten. Danken mchte ich ebenfalls dem Referenten der Arbeit, Prof. Dr. Oliver Braun, der mit seinem Sprit-Projekt diese Arbeit erst mglich machte, immer fr neue Ideen oen war und fr Fragen und Probleme jederzeit als Ansprechpartner zu Verfgung stand. Dipl.-Mathematiker Michael Otto mchte ich dafr danken, der es als Korreferent diese Arbeit betreute und sich im Bereich der Server-Komponenten sehr fr das Projekt eingesetzt hat. Abschlieend mchte ich noch bei meiner Familie, also meiner Frau Stefanie und meinem kleinen Sohn Alexander bedanken, die mit mir gemeinsam die vier arbeitsreichen Semester des Masterstudiums berstehen mussten und denen oft gemeinsame Zeit gefehlt hat.
Inhaltsverzeichnis
1 Einleitung 1.1 Prmissen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Hinweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 FHS-Spirit Projekt 2.1 Entwicklungsgeschichte des FHS-Spirit Teilprojektes . 2.2 Projektverlauf . . . . . . . . . . . . . . . . . . . . . . 2.3 Leitungsmerkmale . . . . . . . . . . . . . . . . . . . . 2.4 Anforderungsbeschreibung der mobilen Applikationen 1 1 1 2 3 3 4 4 5 6 6 7 7 8 9 9 10 13 13 14 14 14 15 15 15 15 17 17 17 17 18 19 19
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
3 Windows Phone 7 3.1 Was ist ein Windows Phone 7? . . . . . . . . . . . . . . . . . . . . . 3.1.1 Metro-Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Cloud-Computing und Cloud-Services . . . . . . . . . . . . . . 3.1.3 iPhone und Windows Phone 7 . . . . . . . . . . . . . . . . . 3.1.4 Android und Windows Phone 7 . . . . . . . . . . . . . . . . . 3.1.5 Windows Phone 7 Kernel . . . . . . . . . . . . . . . . . . . . . 3.2 Hardwarevoraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Technologien zum Entwickeln mit Windows Phone 7 . . . . . . . . . 3.3.1 Silverlight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 XNA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.3 Eingesetzte Technik fr die Spirit Applikation . . . . . . . . . 3.4 Untersttzte Sprachen und Technologie . . . . . . . . . . . . . . . . . 3.4.1 C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Visual Basic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.3 F# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.4 LINQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.5 Gemischtsprachige Programmierung . . . . . . . . . . . . . . . 3.4.6 Eingesetzte Sprachen fr die Spirit Applikation . . . . . . . . 3.5 Verfgbare Entwicklungsumgebungen . . . . . . . . . . . . . . . . . . 3.5.1 Microsoft Visual Studio 2010 . . . . . . . . . . . . . . . . . . . 3.5.2 Microsoft Expression Blend 4 . . . . . . . . . . . . . . . . . . 3.5.3 Alternative Entwicklungsumgebungen . . . . . . . . . . . . . . 3.5.4 Verwendete Entwicklungsumgebungen fr die Spirit-Applikation
4 WP7 Spirit Applikation Backend 21 4.1 Netzwerkkommunikation - Datenformate und Protokolle . . . . . . . 21 4.1.1 REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Ronny Schleicher
IV
Inhaltsverzeichnis
Fachhochschule Schmalkalden SS 2011 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 22 22 22 22 24 27 28 28 29 30 30 30 31 31 32 34 35 35 35 36 37 38 39 39 39 39 40 42 42 43 45 45 47 48 50 50 51 52 57 57 59 60
4.2
4.3
4.1.2 JSON . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.3 XML . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.4 Verwendetes Datenformat in der Spirit Applikation Mglichkeiten der Umsetzung der REST-Schnittstelle . . . 4.2.1 WebClient-Klasse . . . . . . . . . . . . . . . . . . . 4.2.2 HttpWebRequest-Klasse . . . . . . . . . . . . . . . 4.2.3 Eingesetzte Technik in der Spirit Applikation . . . Verarbeitung der JSON Daten . . . . . . . . . . . . . . . . 4.3.1 Bibliotheken zur Verarbeitung von JSON . . . . . . 4.3.2 C# und JSON . . . . . . . . . . . . . . . . . . . . 4.3.3 F# und JSON . . . . . . . . . . . . . . . . . . . . 4.3.4 Linq to JSON . . . . . . . . . . . . . . . . . . . . . 4.3.5 Eingesetzte Technik in der Spirit Applikation . . .
5 WP7 Spirit Applikation Frontend 5.1 UI Design . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Design-Steuerelemente . . . . . . . . . . . . . . . 5.1.2 Bildschirmorientierung . . . . . . . . . . . . . . . 5.1.3 Eingesetzte Techniken in der Spirit Applikation . 5.2 XAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 XAML in Silverlight und dem Windows Phone 7 5.2.2 Markup . . . . . . . . . . . . . . . . . . . . . . . 5.2.3 Code-Behind . . . . . . . . . . . . . . . . . . . . 5.2.4 Ergebnis Markup und Code-Behind . . . . . . . . 5.2.5 Verwendeten Techniken in der Spirit Applikation 5.3 XAML und Datenreprsentation . . . . . . . . . . . . . . 5.3.1 UI-Elemente und Code-Behind . . . . . . . . . . 5.3.2 UI-Elemente und Modelle . . . . . . . . . . . . . 5.3.3 Eingesetzte Techniken in der Spirit Applikation . 6 Systementwurf und Implementierung 6.1 Systembersicht . . . . . . . . . . . . . . . . . . . . . 6.1.1 Komponentendiagramm der Spirit Applikation 6.2 Implementierung der FHSSpirit-App . . . . . . . . . 6.2.1 Elemente der FHSSpirit-App . . . . . . . . . 6.2.2 Funktionsweise der FHSSpirit-App . . . . . . 6.2.3 Pages im Frontend . . . . . . . . . . . . . . . 6.3 Implementierung des FHSSpirit-DataControl . . . . 6.3.1 Instanziierung DataControlNews . . . . . . . 6.3.2 Umsetzung der Rest-Schnittstelle . . . . . . . 6.3.3 Verarbeitung der JSON-Daten mit LINQ . . . 6.4 Implementierung der Modelle . . . . . . . . . . . . . 6.4.1 Modelle in C# . . . . . . . . . . . . . . . . . 6.4.2 Modelle in F# . . . . . . . . . . . . . . . . . 6.4.3 Fazit zu gemischtsprachigen Modellen . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
Ronny Schleicher
Inhaltsverzeichnis
Fachhochschule Schmalkalden SS 2011 61 61 61 62 62 62 63
7 Bereitstellung 7.1 Bereitstellung im Marketplace . . . . . . . 7.2 Hinweise zur Zertizierung . . . . . . . . . 7.3 Bereitstellungsformat . . . . . . . . . . . . 7.4 Entwicklungsgerte . . . . . . . . . . . . . 7.5 Integrierter Trial-Modus . . . . . . . . . . 7.6 Erwerb der Spirit Applikation im Windows
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Marketplace
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
8 Ausblicke 64 8.1 Windows Phone 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 8.2 FHS-Spirit Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 9 Fazit Literaturverzeichnis A Anhang A.1 Windows Phone 7 Spirit Applikation als Open-Source A.2 Installation . . . . . . . . . . . . . . . . . . . . . . . A.2.1 Zertikate installieren . . . . . . . . . . . . . A.3 Automatischen Test . . . . . . . . . . . . . . . . . . . A.4 Benutzerhandbuch . . . . . . . . . . . . . . . . . . . A.5 Mainpage . . . . . . . . . . . . . . . . . . . . . . . . A.6 Detailansicht News . . . . . . . . . . . . . . . . . . . A.7 Detailansicht Stundenplne . . . . . . . . . . . . . . 66 67 68 68 68 68 68 69 69 70 71
Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
B Anhang 72 B.1 Eingesetzte Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 B.2 JSON-Parser mit F# . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Eidesstattliche Erklrung 77
Ronny Schleicher
VI
1 Einleitung
Das Windows Phone 7 wird im Rahmen dieser Arbeit als Entwicklungsplattform fr eine prototypische Softwareimplementierung eingesetzt. Dabei werden die gestellten Anforderungen und deren Realisierungsmglichkeiten unter Verwendung moderner funktionalen und imperativen Sprachelemente untersucht. Die Anforderungen an die zu entwickelnde Software kommen aus dem in Kapitel 2 beschriebenen FHS-Spirit Projekt und verknpfen so eine wissenschaftliche Arbeit mit realen Anforderungen eines wirklichen Anwendungsfalls. Somit werden ergnzende Einblick in die fr Softwareentwickler gebotenen Mglichkeiten des Windows Phone 7 mglich. Zustzlich wird durch die prototypische Softwareimplementierung untersucht, welche Entwicklungsumgebungen, Werkzeuge und Fremdsoftware sich fr die Umsetzung eignen und welche Technologien sich mit welchem Aufwand auf dem Windows Phone 7 einsetzten oder integrieren lassen.
1.1 Prmissen
Da es sich bei der zu entwickelten Software um einen Client-Applikation handelt, die mit einem Server kommuniziert, gibt es einige Prmissen, die bei der Umsetzungen der Software beachtet werden mssen. Diese ergeben sich aus dem Projekt in Kapitel 2, das in seinem Funktionsrahmen den praktischen Teil dieser Arbeit beeinusst. Prmissen der Windows Phone 7 Spirit Applikation im Bezug auf die Client-ServerKommunikation sind: REST als Zugrismechanismus fr Netzwerk-Ressourcen generalisiertes REST -Interface fr alle Applikationen XML oderJSON als Datenformat der REST -Schnittstelle Einsatz von Zertikaten fr die Netzwerkfunktionalitt
1.2 Hinweise
Die einzelnen Kapitel dieser Arbeit bauen teilweise aufeinander auf. Viele Begrilichkeiten in Bezug auf das Windows Phone 7 werden in Kapitel 3 eingefhrt und in darauf in den folgenden Kapitel verwendete.
Ronny Schleicher
Seite 1 von 77
1. Einleitung
Fachhochschule Schmalkalden SS 2011
Kapitel 6 baut auf den Inhalten und Schlussfolgerungen der Kapitel 4 und 5 auf, in denen Nomenklaturen fr Datenformate und Begrie im Bereich der Softwareentwicklung fr das Windows Phone 7 eingefhrt werden. Dieses Kapitels, und auch die vorherigen beiden Kapitel, setzen Grundkennnisse in der Softwareentwicklung voraus, da hier wesentliche Dinge zur Implementierung erlutert werden.
1.3 Gliederung
Im Kapitel 2 wird zunchst das FHS-Spirit Projekt vorgestellt und erlutert, in welchem Zusammenhang diese Arbeit mit den dort beschriebenen Projekt steht. Im Kapitel 3 wird das Windows Phone 7 aus Benutzer- und Entwicklersicht beschrieben. Dabei werden zunchst Hard- und Softwareeigenschaften des Windows Phone 7 analysiert und Technologien vorgestellt, die fr die Entwicklung von Software fr das Windows Phone 7 essentiell sind. Hier wird auch ein berblick auf zur Verfgung stehenden Entwicklungsumgebungen gegeben. Ebenso werden imperative und funktionale Programmiersprachen vorgestellt, die bei der Entwicklung von Windows Phone 7 Software eingesetzt werden knnen. Kapitel 4 beschreibt Technologien, die im Windows Phone 7 zu Verfgung stehen, um die prototypischen Anforderungen an die Applikation zu erfllen. Dabei werden Basistechnologien untersucht, um die eigentliche Backend-Funktionalitt bereitzustellen. Schwerpunkte in diesem Kapitel sind die verschiedenen Mglichkeiten der Netzwerkkommunikation und die Verarbeitung der Datenformate. Dabei werden sowohl die im Windows Phone 7 vorhandenen Technologien und alternativen Anstze durch Erweiterungen mit zustzlicher Fremdsoftware untersucht. Das Kapitel 5 beschreibt ebenfalls Technologien des Windows Phone 7, der Schwerpunkt liegt in diesem Fall allerdings auf der Frontend-Funktionalitt. Hier geht es um die Funktionen und Techniken, die zur Umsetzungen der Benutzerschnittstelle, also der eigentlichen Oberche des Windows Phone 7, genutzt werden knnen. Die Umsetzung der Windows Phone 7 Spirit Applikation und somit die konkrete Anwendung der in Kapitel 4 und Kapitel 5 ermittelten Lsungsmglich ndet in Kapitel 6 statt. Hier wird der Systementwurf der Windows Phone 7 Spirit Applikation vorgestellt und die eigentliche Implementierung erlutert. Kapitel 7 enthlt eine Beschreibung zur Bereitstellung von Windows Phone 7 Applikation im Allgemeinen. Hier benden sich auch Hinweis zu Zertikaten, Entwicklungs- und Testgerten sowie dem Marketplace, in dem Windows Phone 7 Applikation erworben werden. In den Ausblicken in Kapitel 8 ndet sich eine Ideensammlung fr Funktionalitten, die im Rahmen des Prototypen, der Windows Phone 7 Spirit Applikation, oder des Rest-Service noch nicht zur Verfgung standen. Fr Weiterentwicklungen sind die dort formulierten Vorschlge aber mit Sicherheit interessant. Im letzten Kapitel 9 ndet sich ein Fazit zur gesamten Arbeit und der daraus entstandenen Windows Phone 7 Spirit Applikation.
Ronny Schleicher
Seite 2 von 77
2 FHS-Spirit Projekt
Das FHS-Spirit Projekt ist eine Gemeinschaftsarbeit Studierender der Fachhochschule Schmalkalden, die das Ziel hat, das Informationssystem der Fakultt weiter auszubauen, neue Idee umzusetzen und auch Altsoftware durch moderne Technologien, Sprachen und Herangehensweisen zu verbessern. Studenten aus verschiedenen Semestern und Studiengngen versuchen gemeinsam etwas dazu beizutragen, entweder durch theoretische Arbeiten, indem bestimmte Fragestellungen untersucht und ihre Ergebnisse zugnglich machen, oder praktische durch Arbeiten, die als Ergebnis konkrete prototypische Implementierungen hervorbringen, die gegebenenfalls die Grundlage fr weitere Arbeiten oder Lsungen darstellen. Im Rahmen zahlreicher Studien-, Bachelor- und Masterarbeiten wird so versucht, Studierenden durch das Arbeiten an einem groen Gemeinschaftsprojekt ein Gefhl dafr zu vermitteln, wie Software nicht nur durch den Einzelnen sondern durch eine Gemeinschaft immer weiter wachsen und sich weiterentwickeln kann.
2.1 Entwicklungsgeschichte des FHS-Spirit Teilprojektes

Die Grundidee dieses Teil-Projektes war es, einen FHS-Cloud Service zu entwickeln, der die aktuellen Hochschulinformationen zur Verfgung stellt und von verschiedenen Plattformtechnologien genutzt werden kann. Diese Plattformtechnologien schlossen nicht nur Desktop-Systeme sondern auch aktuelle und zuknftige mobile Technologien ein, deren Entwicklung ebenfalls Bestandteil des Projektes sein sollte. Bevor es zum eigentlichen Projekt kam, wurden im Vorfeld zunchst Ideen fr Server- und Clienttechnologien zusammengetragen. Bei den Vorschlgen konnten sich natrlich auch Studenten beteiligen, die so die Gelegenheit bekamen, eine studentische oder wissenschaftliche Arbeit ber ein Projekt anzufertigen, fr das sie sich selbst interessierten. Nach ca. sechs Monaten fand sich eine Gruppe von vier Studierenden zusammen, die sich bereit erklrte, die Ideen in ihren Masterarbeiten auf Basis wissenschaftlicher Arbeiten zu untersuchen und zu beschreiben. Das Ziel war es, neben Formulierung und Bearbeitung der Masterthesis, prototypische Entwicklungen auf den mobilen Plattformen Android und Windows Phone 7, eine Implementierung mit HTML5 und serverseitig eine Scala basierte Applikation mit modernen Datenbankmanagementsystemen zu erstellen. Alle entwickelten Applikationen sollten im Rahmen der Arbeiten als Open-Source zur Verfgung gestellt werden.
Ronny Schleicher
Seite 3 von 77
2. FHS-Spirit Projekt
2.2 Projektverlauf
Bei dem Projekt wurde mit vier Studenten ungefhr drei Monaten lang der Systementwurf, das Datenmodell und die Schnittstellen in gemeinsamen Besprechungen entwickelt, die zwei Mal wchentlich stattfanden. In der Zeit zwischen den Besprechungen galt es meist, technische Fragestellungen zu untersuchen, die sich durch die Analyse eingebrachter Vorschlge in den Besprechungen selbst ergaben. In diesen Besprechungen war stets der rege Austausch zwischen den Studenten und dem verantwortlichem Professor eine wichtige Basis fr das Vorankommen des Projektes. Auch Studenten, die an anderen Projekten im Rahmen von Spirit arbeiteten, nahmen an diesem Besprechungen Teil. Ein Schwerpunkt stellt dabei der Entwurf des generischen Datenmodells da, das den Anspruch hatte, auch zuknftige Ideen und Funktionalitten abbilden zu knnen. Nach ungefhr einem Monat entwickelte sich von der Idee ein konkreter Systementwurf mit einem Datenmodell, das in den folgenden Besprechungen immer weiter verfeinert wurde. In der zweiten Hlfte der Masterarbeiten begann die Arbeitsgruppe mit dem Entwurf und der Implementierung der ersten Prototypen. Auch die Denition der Schnittstelle wurde in dieser Zeit angepasst und in einen Zustand gebraucht, der fr die Implementierung der Client-Anwendungen die ntige Funktionalitt bot. Im letzten Drittel der Bearbeitungszeit wurde sich verstrkt der Entstehung der jeweiligen Masterthesis gewidmet und die Dokumentation der Schnittstellen weiter verfeinert. Die Implementierungen wurden in einen Beta-Status gebracht, der die Funktionsweise und Einsatzmglichkeit des Gesamtsystems verdeutlicht und die Interoperabilitt zwischen den unterschiedlichen Technologien hervorhebt.
2.3 Leitungsmerkmale
Das in diesem Projekt entwickelte Informationssystem beinhaltet einen Cloud-Service, der eine Rest-Schnittstelle zum Abfragen und ndern von Informationen bietet. Dieser Service stellt die serverseitige Komponente des Informationssystems dar und ist mit der Programmiersprache Scala entwickelt. Als Datenbasis dient ein PostgreSQL Datenbanksystem. Auerdem wurde mit dem Lift-Framework ein Web-Service entwickelt, der ebenfalls die Rest-Schnittstelle nutzt und die Mglichkeiten von HTML5 implementiert. Dieser Web-Service ist vorwiegend als Schnittstelle fr Browser auf Desktopsystemen angedacht. Im Bereich der mobilen Endgerte wurde je einen Applikation fr Android und Windows Phone 7 entwickelt. Die Windows Phone 7 Applikation bildet die Grundlage fr diese Arbeit und wurde als das Equivalent zur Adroid-Applikation bearbeitet.
Ronny Schleicher
Seite 4 von 77
2. FHS-Spirit Projekt
Abbildung 2.1 zeigt in einem Komponentendiagramm noch einmal alle wesentlichen Bestandteile des gesamten Projektes mit den wichtigsten Schnittstellen. Deutlich zu erkennen ist, dass der Rest-Service eine zentrale Rolle einnimmt und die Basis fr alle andern Applikationen und dem Web-Service bildet.
Abbildung 2.1: Komponentendiagramm mit den Schnittstellen der Systeme untereinander. Die grau hinterlegte Komponente bzw. das Endgert Windows Phone 7 stellt dabei den Teil dar, der in dieser Masterthesis bearbeitet wurde.
2.4 Anforderungsbeschreibung der mobilen Applikationen

Der Funktionsumfang der mobilen Applikationen und damit auch der Windows Phone 7 Spirit Applikation, die Gegenstand dieser Arbeit ist, besteht aus einer prototypischen Implementierung zum Empfangen und Anzeigen von fakulttsspezischen Nachrichten und Neuigkeiten. Die Applikation soll also im ersten Schritt in der Lage sein, Neuigkeiten mit dazugehrigen Kommentaren ber die Rest-Schnittstelle abzufragen und in geeigneter Form dem Anwender zur Verfgung zu stellen. Eine Liste mit den Ideen zu Funktionalitten, die im Rahmen des Projektes entwickelt und niedergeschrieben, aber in den Prototypen nicht umgesetzt wurden, bendet sich im Anhang Kapitel 8.
Ronny Schleicher
Seite 5 von 77
3 Windows Phone 7
Ziel dieses Kapitels ist es, die Ideen und das Entwicklungskonzepte hinter dem Windows Phone 7 verstndlich zu vermitteln. Neben der eigentliche Frage, was das Windows Phone 7 eigentlich ist, werden die Hardwarevoraussetzungen des Gertes beschrieben und Technologien analysiert, die fr die Entwicklung von Software fr das Windows Phone 7 zur Verfgung stehen. Auch die Programmiersprachen und Entwicklungsumgebungen, die fr das Windows Phone 7 in Frage kommen, werden beschrieben und auf ihre Verwendungsmglichkeiten im Rahmen der Windows Phone 7 Spirit Applikation untersucht.
3.1 Was ist ein Windows Phone 7?

Seit dem 21. Oktober 2010 ist das Windows Phone 7 in Deutschland erhltlich und lste damit die Generation der Windows Mobile 6.x Gerte zwar nicht unmittelbar, aber in relative kurzer Zeit, vollstndig ab. Es handelt sich im Bereich der mobilen Endgerte, gem der Aussage von Microsoft, um eine komplette Neuentwicklung. Beim Windows Phone 7 ist, im Gegensatz zu den Vorgngerversionen, deren Hauptzielgruppe Businesskunden waren, der Endkunden die Zielgruppe dieser Gertegeneration. Neu bei Windows Mobile Gerten ist mit der Einfhrung von Windows Phone 7 der starke Focus in Bezug auf Cloud-Computing und Cloud-Services. Ein Ergebnis dieser Neuausrichtung ist unter anderem ein fest im System integrierter Push Notication Service. Aus Entwicklersicht ist die vernderte Art- und Weise, wie mit der EndgerteHardware und den dazugehrigen Schnittstellen im Windows Phone 7 umgegangen wird, ein wirklicher Vorteil. Wo im Bereich der Windows Mobile 6.x Entwicklung aufgrund fehlender Standards noch individuell fr jedes Gert implementiert werden musste, sind diese Schnittstellen nun vereinheitlicht. Eine weitere, fr Entwickler nicht unerhebliche, Tatsache ist, dass auf dem Windows Phone 7 keine wirkliche EXE mehr gestartet wird, sondern die Applikationen ber einen Launcher in einer Sandbox gehosted werden. Die vollstndige Kontrolle ber das ausgefhrte Programm behlt damit das Windows Phone 7. Die nderungen zur Windows Mobile 6.x Generation sind gewaltig, bilden aber die Basis fr eine sehr interessante und neue Entwicklungsplattform mit neuer Zielgruppe. Die Ausrichtungen in Sachen Cloud, Multimedia, Benutzerfreundlichkeit und Einfachheit sind gleichzeitig Basis fr neue Entwicklungsideen und Anwendungsflle.
Ronny Schleicher
Seite 6 von 77
3. Windows Phone 7
3.1.1 Metro-Design
Die wohl aulligste Neuerung beim Windows Phone 7 ist die komplett neue konzipierte Benutzeroberche. Mit diesem Metro Design entwickelte Microsoft, auch im Rahmen der Windows Phone 7 Konzeption, ein Designkonzept fr Benutzeroberchen, beim dem, wie der Name schon vermuten lsst, die Informationsprsentation in Flughfen, U-Bahnen und Bahnhfen als Inspiration diente. Die Idee, dass das Oberchendesign Beschilderungen nachempfunden ist, hat das Ziel die eigentliche Information, und nicht die Informationsprsentation, als zentrales Element zwischen Applikation und Nutzer zu stellen. Informationen werden dabei als eindeutige Piktogramme, gut lesbarer Text oder als Kombination von beiden dargestellt. Abbildung A.3 enthlt die typischen Benutzeroberchen des Windows Phone 7 im Metro-Design:
Abbildung 3.1: Metro-Design auf dem Startbildschirm des Windows Phone 7. Unter[Wil11] sind sogenannten Metro-Design-Regeln fr Windows Phone 7 Entwickler zu nden, die interessante Hinweise enthalten, wie Oberchen im Metro-Design implementiert werden.
3.1.2 Cloud-Computing und Cloud-Services

Der Fokus des Windows Phone 7 liegt auf Cloud-Services und Cloud-Computing. Demzufolge ist es nicht verwunderlich, dass das Windows Phone 7 schon im Auslieferungszustand einige fest integrierte Cloud-Dienst enthlt. Der Windows-Live-Dienst dient der Synchronisation mit dem Hotmail-Konto und ist somit fr E-Mails, Kalender und Kontaktdaten zustndig. Der XBOX-Live-Dienst stellt die Verbindung zum Game-Hub sicher, in dem Spiele mit anderen Mitspielern gespielt werden knnen, die ebenfalls ein X-BOX-Live-Konto besitzen. Auerdem wird ein Live-Avatar zur Verfgung gestellt, der den Mitspieler dort reprsentiert.
Ronny Schleicher
Seite 7 von 77
3. Windows Phone 7
Der Bing-Dienst dient der schnellen Suche im Internet und der Facebook-Dienst stellte die Verbindung zu dem bekannten Sozialen-Netzwerk sicher. Neben diesen Diensten, die aufgrund fehlender APIs 1 fr Softwareentwickler eher eine untergeordnete Rolle spielen, gibt es noch zwei spezielle Dienste, die fr selbst entwickelte Windows Phone 7 Applikation Funktionalitt zur Verfgung stellen. Location-Dienst Mit dem Location-Dienst knnen ber eine API geobasierte Informationen, also Positionsdaten ber den aktuellen Standort, abgefragt werden. Somit wird die Mglichkeit geboten, diese Daten in der eigenen Windows Phone 7 Applikation zu nutzen und so standortabhngige Funktionalitten zu entwickeln. Push Notication Service Der Push Notication Service ist aus entwicklungstechnischer Sicht eine sehr interessante Funktionalitt des Windows Phone 7. Er bietet die Mglichkeit, einem selbst entwickelten Web-Service eine URL2 zu schicken, unter der die eigene Windows Phone 7 Applikation erreichbar ist, selbst wenn die Applikation nicht mehr ausgefhrt wird. Falls der Web-Service nun Daten an die Windows Phone 7 Applikation bermitteln mchte, sendet er die Daten nicht direkt nicht an die Applikation, sondern an die entsprechende URI. Diese URI qualiziert allerdings nicht das Windows Phone 7 oder die Windows Phone 7 Applikation direkt, sondern den Push Notication Service in der Cloud, der eine Nachricht an das entsprechende Windows Phone 7 sendet. Anschlieend bekommt der Benutzer die Mglichkeit, mit Hilfe der eingeblendeten Nachricht, die entsprechende Windows Phone 7 Applikation, quasi ber eine Verknpfung, sofort zu Starten.
3.1.3 iPhone und Windows Phone 7

Anders als beim iPhone3 , bei dem es nur einen einzigen Hardwarehersteller gibt, werden fr das Windows Phone 7 verschiedene Gerte unterschiedlicher Hersteller angeboten. Da Apple seine Gerte selber entwirft und produziert, gibt es keine oziellen Hardwareanforderungen. Das ist beim Windows Phone 7 anders. Hier existiert eine detaillierte Spezikation (siehe Kapitel 3.2), die die Hardwareanforderungen denieren. Jeder Hersteller, der aus seinen Gerten Windows Phone 7 machen mchte, muss diese Anforderungen erfllen, um einen Lizenz zur Herstellung zu erhalten.
API: Application Programming Interface - Programmierschnittstelle URL: Uniform Resource Locator 3 http://www.apple.com/de/iphone/
2
Ronny Schleicher
Seite 8 von 77
3. Windows Phone 7
Eine Gemeinsamkeit zwischen Windows Phone 7 und dem iPhone besteht darin, dass das Betriebssystem bei beiden Plattformen nicht gendert oder angepasste werden darf und somit einen feste und unvernderliche Basis fr die Entwicklung von Applikationen bietet. Ebenso ist der Zugri auf smtliche Sensoren bei beiden Systemen standardisiert. Auerdem mssen alle Applikationen, die im Windows-Marketplace oder im App-Store angeboten werden, einen Kompatibilitts- und Performancetest bestehen, bevor sie fr die Installation auf den Endgerten zugelassen werden. Damit soll bei beiden Systemen eine gewisse Qualitt der Applikationen sichergestellt werden.
3.1.4 Android und Windows Phone 7

Der grte Unterschied zwischen Android4 und Windows Phone 7 ist, dass Android von den Herstellern ohne jegliche Hardwarebeschrnkungen geliefert und verkauft werden darf. So beschrnkt sich der Einsatz von Android nicht nur auf Smartphones, sondern wird auch auf Navigationsgerten, Table-PC und anderer, grtenteils mobiler, Hardware eingesetzt. Auerdem ist Android eine komplett oene Plattform, die Softwareanpassungen jeglicher Art, vom Kernel ber Sensoren und APIs bis hin zur Benutzeroberche erlaubt. Bei Applikationen die im Android Market angeboten werden, ndet deshalb lediglich einen inhaltliche Prfung statt, da Kompatibilittsund Performancetest aufgrund der heterogenen Endsysteme kaum mglich sind. Eine Gemeinsamkeit zwischen Android und dem Windows Phone 7 besteht in der gemischtsprachigen Programmierung (siehe Kapitel 3.4.5) und der Tatsache, dass man bei beiden Endsystemen zwischen verschiedenen Hardwareherstellern whlen kann.
3.1.5 Windows Phone 7 Kernel

Windows Phone 7 ist fr Entwickler und Anwender eine Plattform, die komplett auf .NET basiert. Allerdings stellt .NET nicht das eigentliche Betriebssystem dar, sondern dient als Abstraktionsschicht fr Anwendungssoftware. Die Basis fr den Kernel ist aktuell ein Windows Embedded Betriebssystem mit der genauen Bezeichnung Windows Embedded CE 6.0 R3 (3. Oktober 2009), dessen Systemkomponenten, also Treiber, DLLs fr Netzwerkstacks sowie Audio- und Video-Codec, fast ausschlielich aus nativen C und C++ DLLs bestehen. Ein Auszug zum Thema Windows Phone 7 Kernel von Olivier Bloch5 [Blo10]: Windows Phone 7 is based on the Windows Embedded CE kernel the next generation of the Windows Embedded CE platform will be Windows Embedded Compact 7 when released, and the current version is Windows Embedded CE 6.0 R3. Although Windows Phone 7 was built on the Windows Embedded CE kernel at its core, the Windows Phone team has incorporated innovative features and functionality on top of the platform to develop an OS specically designed to meet the needs of mobile phone manufacturers.
4 5
http://www.android.com/ Olivier Bloch: Technical Evangelist Microsoft Corp.
Ronny Schleicher
Seite 9 von 77
3. Windows Phone 7
3.2 Hardwarevoraussetzungen
Ander als bei Android, wo es in Bezug auf die Hardware im Prinzip keine Beschrnkungen gibt, oder beim iPhone, bei dem die Hardware vom Hersteller in den verschiedenen Versionen selbst festgelegt wird, gibt es beim Windows Phone 7 folgende fest denierte Hardwarevoraussetzungen, die ein Hersteller mit seinen Gerten erfllen muss. Display Beim Display wird ein kapazitiver Touchscreen, also eine Screen der mittels elektrischer Feldstrkemessung die Berhrungspunkte ermittelt, mit Multi-Touch-Untersttzung fr mindestens vier Berhrungspunkte und einer Ausung von 800x480 Pixel gefordert. Resistive, also druckempndliche, Touchscreens werden nicht untersttzt. Prozessor Die Mindestanforderung hier ist eine Rechenleitung von 1 GHz. Mehrkernsystem werden aktuell nicht untersttzt, sind aber Bestandteil der Roadmap knftiger Versionen. Grak Ein DirectX 9 6 kompatibler Grakchipsatz mit hardwareseitiger Beschleunigung fr DirectX und Direct3D sollen eine ssige Darstellung der Silverlight-Applikationen und XNA-Spiele gewhrleisten und mssen somit vorhanden sein. Audio Das Mikrofon und die Lautsprecher inkl. Kopfhreranschluss mssen ber die API steuerbar sein. Das integrierte FM-Radio, das allerdings, wie bei Smartphones blich, nur mit angeschlossenen Kopfhrern funktioniert, bietet noch weitere Schnittstellen im Audiobereich, die ebenfalls von der API untersttzt werden mssen. Speicher Die minimale Gre des Arbeitsspeichers betrgt 256MB, die des Datenspeichers 8GB. Eine Erweiterung des Datenspeichers mittel austauschbarer Speicherkarte ist nicht vorgesehen. Tastatur Die integrieren Software-Tastatur, die unter Windows Mobile 5.x und 6.x auch als Soft-Input-Panel oder SIP bezeichnet wurde, ist Standard bei allen Windows Phone
6
http://msdn.microsoft.com/de-de/directx/
Ronny Schleicher
Seite 10 von 77
3. Windows Phone 7
7 Gerten. Hardwaretastaturen sind nur als optionale Komponente konzipiert, die lediglich Texteingaben ermglichen und nicht zum eigentlichen Steuern von Applikationen verwendet werden knnen. Denierte Gertetasten Jedes Windows Phone 7 verfgt mit der Power-Taste, der Taste zur Lautstrkeregelung und der Kamerataste ber drei fest denierte Hardware-Tasten. Die Power-Taste dient, je nach Gertezustand, zum Ein- und Ausschalten des Bilderschirms oder des kompletten Gertes. Die Lautstrketaste Taste reguliert die systemweiten Gertelautstrkeregelung. Auerdem kann mit ihr bei eingehenden Telefonaten der Rufton deaktiviert werden. Die Kamerataste wird zur Aktivierung der Kamera verwendet und funktioniert auch bei Bildschirmsperre oder StandbyMode. Sie muss durch halbes drcken auerdem einen Autofokus untersttzen. Darber hinaus muss jedes Windows Phone 7 ber drei weitere kapazitive Tasten verfgen. Mit der Starttaste gelangt der Anwender immer sofort auf die Startseite, die beim Windows Phone 7 einfach nur als Start bezeichnet wird. Mit der Suchtaste wird ein Suchdienst gestartet. Das ist in den meisten Fllen der Bing-Dienst, im Marketplace eine spezielle Marketplace-Suche, in den Kontakten die Personensuche und im E-Mail Bereich ein E-Mai-Suche. Die kapazitive Zurck-Taste nimmt eine besondere Rolle ein. Beim Aktivieren der Taste wird standartmig immer die zuletzt angezeigt Seite, auch Page genannt, wiederhergestellt. Somit ist einen Navigation innerhalb einer und zwischen verschiedenen Windows Phone 7 Applikationen mglich. Interessant fr Entwickler ist, dass das Auslsen der Taste in einer Windows Phone 7 Applikation abgefangen werden kann. Somit ist es mglich, auf das Zurck in der eigenen Applikation entsprechen zu reagieren. Bei einer Client-Anwendung wre es so mglich, vor dem Beenden Abmelde-Protokolle ausfhren oder Daten zu speichern. Allerdings darf eine eigene Implementierung der Zurck-Taste das Navigationsmodell des Windows Phone 7 nicht behindern oder auer Kraft setzen. Bei den Tests im Rahmen der Freigabe einer Applikation fr den Marketplace wird dementsprechend auch auf ein funktionierendes Navigationsmodell geprft[Mic11b]. Sensoren Es groes Problem bei der Windows Mobile 5.x und 6.x Generationen war zum einen der heterogene Zugri ber die APIs auf die in den Gerten vorhandenen Sensoren, zum anderen die Heterogenitt der Sensoren selbst. Beim Windows Phone 7 sind dagegen die enthaltenen Sensoren im Bezug auf ihre Schnittstellen homogen.
Ronny Schleicher
Seite 11 von 77
3. Windows Phone 7
Folgende Sensoren mssen in jedem Windows Phone 7 vorhanden sein: Accelerometer: Dient zur Beschleunigungsmessung. A-GPS: Das Assised Global Position System dient zur Positionsbestimmung. Neben der herkmmlichen GPS-Funktionalitt bietet dieses System auch die Mglichkeit, eine Standortbestimmung per GPS-Triangulation oder ber vorhandene WLAN-Netze mit IP-Lokalisierung durchzufhren. Kompass: In der aktuellen Version des Windows Phone 7 ist ein API fr den Zugri aus diese Sensordaten nicht enthalten. Proximity: Mit dem Nherungssenor wird ermittelt, ob ein Objekt einen Abstand vom 15mm zum Sensor unterschreitet. Der Proximity-Sensore ndet unter anderem Verwendung um zu ermitteln, ob sich das Gert bei einem laufenden Telefonat am Ohr bendet oder nicht. Das System reagiert mit Aktivierung bzw. Deaktivierung des Displays. Lichtsensor: Dient zur Ermittlung der Strke des umgebenden Lichtes und wird zur automatischen Anpassung der Helligkeit des Displays verwendet. Auch hier bietet die API aktuell keine Zugrismglichkeiten. Kamera Alle Windows Phone 7 besitzen eine Kamera mit mindestens 5 Megapixeln, einem Autofokus und Blitzlicht. Auch hier gibt es eine API um diese Funktionalitt in der eigenen Applikation zu nutzen. Netzwerkverbindungen Die Art der aktuell verfgbaren Daten- bzw. Netzwerkverbindung ist fr den Entwickler, was den Zugri ber die reinen APIs angeht, im Grunde genommen Homogen. Trotzdem soll der Vollstndigkeit halber erwhnt werden, dass das Windows Phone 7, genau wie anderer Smartsphones auch, mehrere Arten von Netzwerkverbindungen untersttzt. Allerdings sieht die API hier vom Ansatz her nicht vor, unterschiedliche Applikationsverhalten bei unterschiedlichen Verbindungsarten zu untersttzen. Die genau verwendeten Datennetztechnologien knnen, aufgrund regionaler Unterschiede, tatschlich von Gerte zu Gerte variieren. Allerdings muss jedes Windows Phone 7 ber die regional bliche Datennetztechnologie und WLAN verfgen. Einschrnkungen Hinsichtlich der im Windows Phone 7 eingesetzten Hardware und deren Anwendungsmglichkeit gibt es, fr Entwickler und fr Anwender gleichermaen, aktuell noch einige Einschrnkungen. Bluetooth erlaubt nur die Verbindung zu einem Headset. Es ist also nicht mglich Fotos oder sonstige Daten per Bluetooth an andere Gerte zu bertragen. Auch eine Nutzung des Windows Phone 7 per USB als mobiler Datentrger ist vom Hersteller aus derzeit nicht vorgesehen.
Ronny Schleicher
Seite 12 von 77
3. Windows Phone 7
3.3 Technologien zum Entwickeln mit Windows Phone 7

Die gesamte Anwendungssoftware, die auf einen Windows Phone 7 ausgefhrt werden kann, basiert auf dem .NET Compact Framework 3.5 und damit auf Managed Code. Demzufolge ist es, anders als bei den Vorgngern, nicht mehr mglich, nativen Code auszufhren. Mit XNA und Silverlight werden zwei .NET Technologie bereitgestellt, die die Windows Phone 7 Entwicklungsparadigmen untersttzen. Hierbei handelt es sich im brigen auch um die einzigen zwei Technologien, die das Entwickeln auf dem Windows Phone 7 ermglichen.
3.3.1 Silverlight
Silverlight ist im Windows Phone 7 Kontext als Framework zur Anwendungsentwicklung zu verstehen und lst die bis bisher verwendeten Windows Forms ab. Vorteile und Grnde fr den Einsatz von Silverlight gegenber Windows Forms sind unter anderem[Mic11h]: Hierarchische Steuerelementen: Im Gegensatz zu Windows Forms, das die Steuerelemente nur ach darstellen kann, ist es mit Silverlight mglich, Steuerelement zu Gruppieren und hierarchische Darzustellen. Damit wird eine hohe Flexibilitt der Steuerelemente erreicht und es sind dynamische Oberchen, exible Styles und Layouts mglich. Grakdarstellung durch Vectoren: Da Windows Forms auf Pixelbasis arbeiten, ist das skalieren der Oberche ohne Verpixelung nicht ohne weiteres mglich. Die Darstellung der SilverlightElemente erfolgt dagegen auf Vektorbasis und lst somit dieses Problem. Animationen: Silverlight untersttzt von Haus aus Animationen, mit denen ansprechende Benutzeroberchen fr Endanwender erstellt werden knnen. Trennung von Design und Animationen: Eine Trennung von Oberchengestaltung (Markup), und dem dazugehrigem Quellcode (Code-Behind), ist Bestandteil des Entwicklungsmodells von Silverlight. Die Oberche wird dabei in XAML erstellt, whrend die Funktionalitt in der dazugehrigen Quellcodedatei untergebracht ist. In Kapitel 5.2 wird dieses Konzept nher beschrieben. Silverlight wurde von Anfang an als Sandbox7 konzipiert und wird aktuell als Browsererweiterung eingesetzt. Dies unterscheidet sich nicht gravierend vom Einsatz in einem geschlossenen System, wie Windows Phone 7, da auch hier nur die eingeschrnkte API des .NET Compact Framework 3.5 zur Verfgung steht und die laufenden Applikationen hnlich eingeschrnkte Rechte besitzen.
http://de.wikipedia.org/wiki/Sandbox
Ronny Schleicher
Seite 13 von 77
3. Windows Phone 7
Hinzu kommt, dass Silverlight lediglich auf einer Teilmenge der WPF 8 basiert, was wiederum eine gute Voraussetzung fr den Einsatz auf nicht so leistungsfhiger Hardware, wie der bei Smartphones, ist.
3.3.2 XNA
Das XNA-Framework ist ein fester Bestandteil des Windows Phone 7 und stellt aktuell die Spiele-Plattform dar, die von Entwicklern genutzt wird, um Spiele fr die XBOX 360 und fr das Windows Phone 7 zu programmieren. Allerdings ist das XNA-Framework nicht als einzelne Bibliotheken-Sammlung erhltlich, sondern ist im Lieferumfang des XNA Game Studio 4.0 9 enthalten. Das XNA Gamestudio 4.0 ist wiederum eine Erweiterung des Visual Studio 2010 und integriert die ntigen Bibliotheken, Dienstprogramme, Projektvorlagen und Dokumentationen in die eigentliche Entwicklungsumgebung. Der Programmcode wird also im Visual Studio 2010 geschrieben. Im XNA Framework sind alle ntigen Klassen und Bibliotheken enthalten, die ntig sind, um umfangreiche 2D- und 3D-Spiele zu implementieren. Allerdings ist XNA keine Game-Engine, die ein Design via drag-and-drop ermglicht. Es stellt vielmehr die Basis dar, auf der eine solche Game-Engine zu entwickelt werden kann. Auerdem stellt XNA keine Steuerelement und Controls wie z.B. Buttons oder ListBoxes bereit. Falls man Steuerelemente bentigt, mssen diese von Hand implementiert werden. Alternativ dazu ist es mglich, auch vorhandene Bibliotheken fremder Quellen zu nutzen.
3.3.3 Eingesetzte Technik fr die Spirit Applikation

In der Windows Phone 7 Spirit Applikation wird Silverlight eingesetzt, da es der passende Framework fr Applikationen ist, die mit Hilfe von Steuerelement und Controls Informationen fr den Benutzer reprsentieren sollen. Funktionen, mit denen man die Strken von Silverlight im Bereich der 2D- und 3D-Darstellung nutzen kann, sind in den Anforderung an die Windows Phone 7 Spirit Applikation nicht zu nden.
3.4 Untersttzte Sprachen und Technologie

Aktuell ist im Lieferumfang des Visual Studios 2010 lediglich C# als Sprache fr die Entwicklung von Windows Phone 7 Projekten enthalten. Allerdings sind mittlerweile ein RTW10 fr Visual Basic und Online-Projektvorlagen fr F# erhltlich, die das Sprachenspektrum erweitern.
Windows Presentation Foundation http://msdn.microsoft.com/de-de/library/bb200104.aspx 10 Release to Web - Software-Release die per Download zur Verfgung gestellt werden.
9
Ronny Schleicher
Seite 14 von 77
3. Windows Phone 7
3.4.1 C#
C# wird in der Version 4.0 untersttzt und ist die mit Abstand am meistens genutzte Sprache in der Windows Phone 7 Entwicklung. Jede Beispielimplementierung im MSDN ist in C# zu nden und auch die meisten Webcasts11 nutzen diesen Sprache fr Schulungszwecke. Besonders interessant ist, dass gerade die funktionalen Elemente dieser Sprache, wie Lambda Ausdrcke, die Einbettung von LINQ und anonyme Methoden, stark in den Vordergrund gestellt werden.
3.4.2 Visual Basic

berraschenderweise fehlte Visual Basic 2010 fr das Windows Phone 7 in der ersten Release des Visual Studio 2010. Seit Anfang 2011 kann man es als RTW nachinstallieren. Auch Visual Basic 2010 protiert von den funktionalen Elementen des .NET Frameworks. Eine der neuen Funktionen in Visual Basic 2010 ist die Untersttzung mehrzeilige Lambda-Ausdrcke und -Unterroutinen[Mic11f].
3.4.3 F#
Seit Anfang 2011 ist es mglich F# bei der Windows Phone 7 Entwicklung zu verwenden und so eine funktionalen Programmiersprache einzusetzen. Hierfr muss man lediglich die ntigen Online-Projektvorlagen installieren, damit das Visual Studio 2010 die Mglichkeit bietet, diesen Projekttyp anzulegen. Der Trend hin zur funktionaler Entwicklung hat damit seine erste eigene .NET Sprache hervorgebracht, die zudem die volle Untersttzung und Funktionalitt des .NET Frameworks bietet[Mic11c].
3.4.4 LINQ
LINQ, die Language INtegrated Query, ist eine Abfragesprache, die auf eine beliebige Datenquelle angewendet werden kann. Anders als bei SQL, bei der, bis auf einige exotische Ausnahmen, immer einen Datenbank die Basis der Abfrage darstellt, muss bei LINQ lediglich ein so genannter LINQ-Provider vorhanden sein, der die Datenquelle untersttzt. LINQ ist hierbei als einheitliches Datenzugrismodell zu sehen, das die Abfrage und Verarbeitung verschiedener Datenmodelle unter Verwendung des jeweiligen Providers ermglicht. Folgende LINQ-Provider sind Bestandteil des .NET Framework: LINQ to Objects Findet Verwendung fr Collections die IEnumerable implementieren. LINQ to XML Zugri auf XML Strukturen.
11
http://www.microsoft.com/germany/msdn/webcasts/default.mspx
Ronny Schleicher
Seite 15 von 77
3. Windows Phone 7
LINQ to SQL Die im .NET Framework mitgelieferten Provider arbeiten lediglich mit MSSQL Servern zusammen. Allerdings sind Provider fr andere Datenbanksysteme wie MySQL, Oracle oder SQLite in Entwicklung bzw. erhltlich. LINQ to Dataset Bezieht sich auf Daten im einem Dataset[Mic11e]. LINQ to Entities Bietet die Mglichkeit Abfragen fr konzeptionelle Modelle im Entity Framework zu erstellen[Mic11d]. Interessant ist auch, dass Abfragen durch LINQ zum bersetzungszeitpunkt mit Hilfe des jeweiligen LINQ-Providers geprft und optimiert werden. Anders als bei SQL ndet also keine Interpretation des Statements zur Laufzeit statt. Dies ermglicht eine sehr eziente Verarbeitung der LINQ-Statements im laufenden Programm. Alternative LINQ-Provider LINQ stellt dabei keine geschlossenen, auf Microsoft Produkte beschrnkte, Technologie dar. Weitere, teilweise noch in der Entwicklung oder dem Beta-Stadium bendlichen LINQ-Provider sind unter anderem[Sys07]: LINQ to JSON LINQ to SharePoint LINQ to Amazon LINQ to Google LINQ to Active Directory (LDAP) LINQ to NHibernate LINQ to MySQL / Oracle / SQLite LINQ to Flickr LINQ und Windows Mobile 6.x beraschenderweise ist LINQ fr relative viele ehemalige Windows Mobile 6.x Entwickler Neuland, obwohl es im .NET Compact Framework 3.5, wenn auch in eingeschrnkter Form, bereits vorhanden war. Ursache dafr ist, dass lediglich der .NET Compact Framework 2.0 im Lieferumfang von Windows Mobile 6.x enthalten war. Ein ROM Update der Endgerte auf den .NET Compact Framework 3.5 in Korrespondenz mit mglichen nderungen an der eigenen Software schien den Aufwand gegenber den Vorteilen, den man sich durch LINQ und anderer neuer Funktionalitt versprach, nicht zu rechtfertigen.
Ronny Schleicher
Seite 16 von 77
3. Windows Phone 7
3.4.5 Gemischtsprachige Programmierung

Gemischtsprachig Programmierung, also die Verwendung verschiedener Programmiersprachen in einer Applikation, ist, genau wie beim .NET Framework 3.5, auch mit der Compact-Version einsetzbar und stellt eine interessante Mglichkeit zum Entwickeln von Windows Phone 7 Applikationen dar. So ist es mglich, die Vorteile der einzelnen Sprachen ezient fr die zu lsenden Aufgaben in einer Applikation gemeinsam einzusetzen, ohne dass im Zusammenspiel der Sprachen Mehraufwand beim Entwickeln generiert wird. Gerade im Bezug auf die relative neue funktionale Programmiersprache F# ergeben sich hier fr Softwareentwickler Chancen, solche Technologien auch in bestehenden Applikationen einzusetzen und bestimmte Programmteile funktional zu implementieren, ohne die komplette Applikation auf ein Sprachenparadigma zu beschrnken.
3.4.6 Eingesetzte Sprachen fr die Spirit Applikation

In der Windows Phone 7 Spirit Applikation wird gemischtsprachige Programmierung eingesetzt, um die Vorteile von imperativen und funktionalen Sprachen nutzen zu knnen. Der imperative Teil ist mit C# implementiert, da Visual Basic weniger Funktionalitt bietet und keine nennenswerten Vorteile bringt. Die funktionalen Teile werden mit LINQ und F# implementiert. Die Einsatz von LINQ wird im Kapitel 4.3 noch einmal begrndet. Die Verwendung von F# soll zustzlich klren, inwieweit sich die neue funktionale Sprache zum Entwickeln von Windows Phone 7 Applikation eignet.
3.5 Verfgbare Entwicklungsumgebungen

Um Applikationen fr das Windows Phone 7 zu entwickeln, werden von Microsoft mit dem Visual Studio 2010 und Expression Blend 4 aktuell zwei Entwicklungsumgebungen angeboten. Erweiterung fr Ecplise12 sind nicht erhltlich. Die Recherche nach alternativen Entwicklungsumgebungen brachte mit der Meme IDE lediglich ein Ergebnis. Vorgreifend ist deshalb zu sagen, dass Software fr das Windows Phone 7 aktuell im Grunde nur mit Microsoft-Produkten entwickelt werden kann.
3.5.1 Microsoft Visual Studio 2010

Mit dem Visual Studio 2010 bietet Microsoft fr das Windows Phone 7 eine Entwicklungsumgebung an, die eine sehr gute Integration der bentigten Komponenten bietet. Alle ntigen Softwarepakete und Programme, wie Simulator, Remote-Debugger und Oberchen-Designer sind verfgbar, um Software fr das Windows Phone 7 entwickeln zu knnen. Auch eine sehr detaillierte Hilfe in den EFIGS-Sprachen13
12 13
http://eclipse.org EFIGS-Sprachen: English, French, Italian, German, Spanish
Ronny Schleicher
Seite 17 von 77
3. Windows Phone 7
kann lokal installiert oder online genutzt werden. Zustzlich stehen ozielle WebCast und Online-Tutorien zur Verfgung. Die kostenlose Variante Visual Studio 2010 Express Edition14 , die fr die Entwicklung von Windows Phone 7 Applikationen prinzipiell ausreicht, wird bereits mit allen ntigen Softwarekomponenten angeboten, so dass eine Nachinstallation zustzlicher Softwarekomponenten hier nicht ntig ist. Bei den kostenpichtigen Varienten15 muss gegebenenfalls das Paket Windows Phone Developer Tools RTW 16 nachinstalliert werden, da der Windows Phone 7 SDK17 zum Release-Zeitpunkt der kommerziellen Versionen noch nicht zur Verfgung stand. Da der Windows Phone 7 SDK, egal ob mit oder ohne Nachinstallation, eine integrierte Komponente des Visual Studio 2010 ist, stehen in den kommerziellen Varianten alle Online-Updates, Online-Vorlagen und andere Erweiterungen zur Verfgung. Auch Funktionalitten, wie die Anbindung an den Team Fundation Server18 , staische Codeanalyse sowie die integrierten Architektur und Modellierungswerkzeuge, sind fr die Windows Phone 7 Projekte nutzbar. Hinweis zur Verwendung von F#: F# kann aktuell nicht als eine Erweiterung mit einem RTW-Paket, so wie Visual Basic, nachinstalliert werden. Die einzige Mglichkeit, die Spracherweiterungen zu installieren, besteht in der Auswahl einer OnlineProjekt-Vorlage, die diese Sprache verwendet. Allerdings stehen in der kostenlosen Variante Visual Studio 2010 Express Edition Online-Vorlagen fr Projekte nur eingeschrnkt zu Verfgung. Demzufolge ist es nicht ohne weiteres mglich F#-Projekte in der Express Edition zu verwenden. F# als Programmiersprache fr Windows Phone 7 kann demzufolge nur fr die kostenpichtigen Varianten des Visual Studio 2010, die Online-Vorlagen uneingeschrnkt untersttzen, eingesetzt werden.
3.5.2 Microsoft Expression Blend 4

Expression Blend 4 ist keine Entwicklungsumgebung im herkmmlichen Sinne. Es handelt sich vielmehr um eine Sammlung verschiedener Designwerkzeuge zum Erstellen von Silverlight Oberchen. Whrend das Visual Studio 2010 als Werkzeug fr Programmierer konzipiert ist, ist Expression Blend 4 eher fr Oberchen-Designer gedacht, die keinen oder nur wenig Quellcode schreiben. Expression Blend 4 ist also eher mit Adobe Photoshop19 oder Adobe Premiere20 vergleichbar. Als Basis fr Expression Blend 4 dienen die gleichen Projekt- und Solution-Dateien wie fr das Visual Studio 2010. Somit ist es mglich, und vom Ansatz her auch so gedacht, dass auf einem Projekt mit beiden Werkzeugen und eventuelle auch mit verschiedenen Personen gearbeitet wird. Expression Blend 4 ist in das Visual Studio
http://www.microsoft.com/germany/express/ http://www.microsoft.com/germany/visualstudio/products/features.aspx 16 http://www.microsoft.com/download 17 Software Development Kit 18 http://www.microsoft.com/germany/visualstudio/products/team/visual-studio-teamfoundation-server.aspx 19 http://www.adobe.com/de/products/photoshop.html 20 http://www.adobe.com/de/products/premiere.html
15 14
Ronny Schleicher
Seite 18 von 77
3. Windows Phone 7
2010 integriert. Das bedeutet, dass es mglich ist, im Visual Studio 2010 einzelne Dateien oder komplette Projekte direkt mit Expression Blend 4 zu nen und zu bearbeiten. Allerdings ist Expression Blend 4 in keiner Variante kostenlos erhltlich, sondern nur als kostenpichtige Software separat zu beziehen oder in bestimmten kostenpichtigen Varianten des Visual Studio 2010 im Lieferumfang enthalten. Es ist auch nicht die Aufgabe von Expression Blend 4 den Oberchen-Designer im Visual Studio 2010 zu ersetzen. Oberchen-Design mit Expression Blend 4 ist im Grunde genommen eine anderer und sehr leistungsfhige Herangehensweise Silverlight-Oberchen zu entwickeln. Als Sprache fr das Windows Phone 7 wird C# untersttzt, wobei von Erweiterungen ausgegangen werden kann.
3.5.3 Alternative Entwicklungsumgebungen

Im Bereich alternative Entwicklungsumgebungen fr Windows Phone 7 und Windows Mobile konnte mit Meme IDE 21 lediglich eine Software ausndig gemacht, die neben den Produkten vom Microsoft eine Entwicklungsumgebung fr mobile Windows-Endgerte zur Verfgung stellt. Die Idee hinter dem Produkt Meme IDE ist cross platform development fr mobile Applikationen. Hierbei wird unter Verwendung der Meme IDE mit einer eigenen Programmiersprache, dem MemeScript, die komplette mobile Applikation entwickelt. Anschlieend ist es mglich aus diesem Quellcode lauhige Applikationen fr Windows Mobile, Android und iPhone zu erzeugen. Es muss also fr die Untersttzung verschiedener mobiler Endgerte lediglich eine Applikation entwickelt werden, die unterschiedlich bersetzt und verpackt wird. Leider untersttzt dieser wirklich sehr interessante Ansatz fr die Entwicklung mobiler Applikationen zurzeit nicht Windows Phone 7, sondern nur dessen Vorgnger Windows Mobile 6.5. Es bleibt zu hoen, dass eine Untersttzung fr Windows Phone 7 in der Roadmap fest vorgesehen ist, da zurzeit keine andere Software mit einem vergleichbaren Konzept im Bereich der mobilen Applikationen zu nden ist. Auch eine sehr umfangreiche Dokumentation zur Meme IDE und dem MemeScript liegt bereits vor. Auerdem gibt es mit MemeCloud auch alternative Anstze zum Deployment vom mobilen Applikationen.
3.5.4 Verwendete Entwicklungsumgebungen fr die Spirit-Applikation

Bei der Umsetzung der Windows Phone 7 Spirit-Applikation wurde neben dem Visual Studio 2010 auch Expression Blend 4 verwendet. Wie unter Punkt 3.5.1 beschrieben, ist das Visual Studio 2010 zurzeit die einzige Entwicklungsumgebung, die das Implementieren von Windows Phone 7 ermglicht. Alternativen sind im Prinzip nicht vorhanden.
21
http://www.memeapps.com
Ronny Schleicher
Seite 19 von 77
3. Windows Phone 7
Expression Blend 4 wurde zum Gestalten der Oberchen eingesetzt. Obwohl der Einarbeitungsaufwand bei Expression Blend 4 beachtlich sein kann, wenn man mit dieser Art von Software noch nicht gearbeitet hat, sind die Mglichkeiten, die geboten werden, enorm. Schnelles Prototypen der Oberchen in Kombination mit dem Simulator und der guten Vorschau in Expression Blend 4 egalisiert rasch die Einarbeitungszeit und fhrt im Bereich der Oberchengestaltung zu sehr guten Ergebnissen. Viele Entwrfe der Windows Phone 7 Spirit Applikation dieser Arbeit sind mit Expression Blend 4 entstanden. Auch die nale Oberche wurde mit Expression Blend 4 entworfen und anschlieend mit dem Visual Studio 2010 implementiert. Gerade die Integration von Expression Blend 4 in das Visual Studio 2010 beschleunigt die Design- und Implementierungsarbeit enorm. Allerdings muss erwhnt werden, dass das erzielte Ergebnis auch ohne Expression Blend 4 mglich gewesen wre, da die Spirit-Applikation im Bereich der Oberche letztendlich Daten reprsentiert und auf Animationen und Eekte weitgehend verzichtet. Doch selbst bei relativ nchternen Oberchen erleichtert Expression Blend 4 die Gestaltung mitunter erheblich.
Ronny Schleicher
Seite 20 von 77
4 WP7 Spirit Applikation Backend

In diesem Kapitel werden die zur Windows Phone 7 Spirit Applikation ntigen Backend-Technologien vorgestellt und begrndet, warum die jeweilige Technik in der Applikation Verwendung ndet. Unter Backend wird in diesem Kontext der Empfang der Daten ber Netzwerk, die Datenverarbeitung und die Bereitstellung der Daten fr das Frontend in Kapitel 5 verstanden.
4.1 Netzwerkkommunikation - Datenformate und Protokolle

Eine wesentliche Kernfunktionalitt bildet die Netzwerkkommunikation zwischen dem Cloud-Service und der jeweiligen Client. Der .NET Compact Framework 3.5 bietet im Bereich dieser Funktionalitten verschiedene Klassen, Methoden und Verfahren an, die die Verarbeitung erleichtern sollen.
4.1.1 REST
Die Bezeichnung REST, ein Akronym fr Representational State Transfer, wurde in der Dissertation von Roy T. Fielding1 eingefhrt und beschreibt einen eine spezielle Softwarearchitektur, die sich durch die zentralen Elemente Ressourcen und Reprsentationen, verteilte Hypermedia-Informationssysteme und einheitliche Schnittstellen auszeichnet.2 3 REST bildet fr den Cloud-Service der FH-Schmalkalden ein zentrales Architekturmerkmal. Jede Client-Anwendung muss in der Lage sein, die dort implementierte REST-Schnittstelle, die auf dem Http-Protokoll basiert, entsprechend der Spezikation zu bedienen.
4.1.2 JSON
Ein bereitgestelltes Datenformat des Cloud-Service ist JSON, die JavaScript Object Notation.4 Hierbei handelt es sich um ein sehr kompaktes Datenformat, das in diesem Fall als Container fr die eigentlichen Nutzdaten dient. Mit dem Setzen des Content-Type der http Anfrage auf application/json wird das Datenformat fr die jeweilige Anfrage auf JSON festgelegt.
1 2
http://www.ics.uci.edu/ elding/pubs/dissertation/top.htm http://it-republik.de/jaxenter/artikel/RESTDer-bessere-Web-Service-2158.html 3 http://de.wikipedia.org/wiki/Representational_State_Transfer 4 http://de.wikipedia.org/wiki/JavaScript_Object_Notation
Ronny Schleicher
Seite 21 von 77
4. WP7 Spirit Applikation Backend
4.1.3 XML
Neben JSON besteht auch die Mglichkeit, die Daten im XML-Format5 zu empfangen. Hierfr muss lediglich der Content-Type der http Anfrage auf application/xml gesetzt werden. Die empfangene XML-Datenstruktur entspricht vom Inhalt her genau dem, was auch ber JSON zurckgeliefert wird.
4.1.4 Verwendetes Datenformat in der Spirit Applikation

In der Windows Phone 7 Spirit Applikation wird JSON eingesetzt, da dieses Format die Informationen mit verhltnismig wenig Overhead bertrgt. Gerade wenn wenig Bangbreite zur Verfgung steht und bzw. oder keine Datenat zur Verfgung steht, was bei Smartphone durchaus der Fall sein kann, ist ein kompaktes Format zur Datenbertragung immer von Vorteil. Fr die interne Weiterverarbeitung ist es aufgrund des Einsatzes von LINQ (siehe Kapitel 3.4.4) unerheblich welches Datenformat verwendet wird, da fr JSON und XML der jeweilige LINQ-Provider zur Verfgung steht.
4.2 Mglichkeiten der Umsetzung der REST-Schnittstelle

Der .NET Compact Framework 3.5 bietet keine explizite Untersttzung fr RESTSchnittstellen an. Allerdings sind mit den im .NET Compact Framework 3.5 enthaltenen Klassen die ntigen Werkzeuge vorhanden, um einen REST-Schnittstelle selbst zu implementieren. Um mit diesen Klassen in einer Windows Phone 7 Applikation einen Web-Request zu erzeugen, und somit Daten von einer REST-Schnittstelle zu empfangen, existieren zwei Mglichkeiten, die nachfolgend beschrieben werden.
4.2.1 WebClient-Klasse
Unter Verwendung der Klasse WebClient wird in Listing 4.1 ein asynchroner WebRequest gestartet. In Codezeile 11 wird ein Objekt der Klasse WebClient erzeugt. Anschlieend wird in Codezeile 12 das Event OpenReadCompleted abonniert. Das geschieht mit Hilfe des += Operator und des EventHandlers OpenReadCompletedEventHandler. Als Parameter wird dem EventHandler im Konstruktor die Methode onEventOpenReadCompleted bergeben, die beim Auftreten des abonnierten Events gerufen werden soll. Der EventHandler erzeugt hierfr ein Delegate6 , um Event um Methode zu verbinden.
5 6
Extensible Markup Language, http://www.w3.org/XML/ Als Delegate bezeichnet man ein Objekt, das einen Zeiger auf Methode kapselt.
Ronny Schleicher
Seite 22 von 77
In Codezeile 13 wird dann der eigentliche Web-Request abgesetzt. Nachdem die angeforderte Daten vollstndig empfangen wurden, wird der Event onEventOpenRead Completed ausgelst und demzufolge die Methode onEventOpenReadCompleted gerufen, in der das Ergebnis der Anfrage ab Codezeile 20 verarbeitet werden kann. Der Aufruf processData steht hier symbolisch fr eine Methode, die die Daten verarbeitet. Listing 4.1: Web-Request mit C# und der Klasse System.Net.WebClient 1 // . . . 2 using System . Net ; 3 4 p u b l i c p a r t i a l c l a s s MainPage : P h o n e A p p l i c a t i o n P a g e 5 { 6 // . . . 7 U r i u r i = new U r i ( "http ://212.201.64.226:8080/ fhs -spirit/ news" ) ; 8 9 p r i v a t e void r e q u e s t D a t a ( ) 10 { 11 W e b C l i e n t wc = new W e b C l i e n t ( ) ; 12 wc . OpenReadCompleted += new Op enR ead Com pl eted Ev ent Han dle r ( onEventOpenReadCompleted ) ; 13 wc . OpenReadAsync ( u r i ) ; 14 } 15 16 p r i v a t e void onEventOpenReadCompleted ( o b j e c t s e n d e r , OpenReadCompletedEventArgs e ) 17 { 18 i f ( e . E r r o r == n u l l ) 19 { 20 System . IO . S t r e a m R e a d e r s r = new System . IO . S t r e a m R e a d e r (e . Result ) ; 21 // s r b e i n h a l t e t d i e a n g e f o r d e r t e n Daten 22 processData ( sr ) ; 23 } 24 } 25 } Wichtig ist, dass bei dieser Vorgehensweise das Ergebnis des Web-Requests, also die Methode onEventOpenReadCompleted, im Mainthread der Windows Phone 7 Applikation ausgefhrt wird. Demzufolge ist die Applikation fr den Zeitraum, den sie fr die Verarbeitung der empfangenen Daten in der Methode bentigt, blockiert. Das Sequenzdiagramm 4.1 soll den genauen Ablauf noch einmal verdeutlichen.
Ronny Schleicher
Seite 23 von 77
Abbildung 4.1: Sequenzdiagramm mit dem Ablauf der Kommunikation unter Verwendung der Klasse WebClient. Wenn in der Methode onEventOpenReadCompleted die Menge der zu verarbeiten Daten relativ gering ist und so gewhrleistet wird, dass der Mainthread der Windows Phone 7 Applikation und somit die gesamte Applikation nicht zu lange blockiert ist, ist dieser Ansatz akzeptabel. Auch ist es mglich, dass das Blockieren der Applikation fr den Zeitraum der Verarbeitung gewollt ist und mit Hilfe eines Progressbars visualisiert wird. Eine dritte Mglichkeit ist das hndische Erzeugen eines Workerthreads in der Methode onEventOpenReadCompleted, der die asynchrone Verarbeitung der Daten im Hintergrund bernimmt. Dies bedeutet allerdings einen direkten Mehraufwand in der Implementierung.
4.2.2 HttpWebRequest-Klasse
Eine andere Mglichkeit, einen Web-Request abzusetzen, bietet die Klasse HttpWebRequest. Hier wird das Ergebnis des Web-Request nicht ber das EventHandling behandelt, sondern mit einem Callback-Mechanismus verarbeitet.
Ronny Schleicher
Seite 24 von 77
Auch hier steht der Aufruf processData symbolisch fr eine Methode, die die Daten verarbeitet. Listing 4.2: Web-Request mit C# und der Klasse System.Net.HttpWebRequest 1 2 using System . Net ; 3 4 p u b l i c p a r t i a l c l a s s MainPage : P h o n e A p p l i c a t i o n P a g e 5 { 6 // . . . 7 U r i u r i = new U r i ( "http ://212.201.64.226:8080/ fhs -spirit/ news" ) ; 8 9 p r i v a t e void r e q u e s t D a t a ( ) 10 { 11 HttpWebRequest wr = ( HttpWebRequest ) HttpWebRequest . Create ( u r i ) ; 12 wr . Method = "GET" ; 13 wr . B e g i n G e t R e s p o n s e ( r e s p o n s e C a l l b a c k , httpWebRequest ) ; 14 } 15 16 p r i v a t e void r e s p o n s e C a l l b a c k ( o b j e c t s e n d e r , OpenReadCompletedEventArgs e ) 17 { 18 i f ( e . E r r o r == n u l l ) 19 { 20 WebResponse r e s p o n s e = httpWebRequest . EndGetResponse ( r e s u l t ) ; 21 System . IO . Stream s t r e a m = r e s p o n s e . GetResponseStream ( ) ; 22 System . IO . S t r e a m R e a d e r s r = new System . IO . StreamReader ( stream ) ; 23 // s r b e i n h a l t e t d i e a n g e f o r d e r t e n Daten 24 processData ( sr ) ; 25 Dispatcher . BeginInvoke ( _setLabelContent , strContent ); 26 } 27 } 28 } Der wichtigste Unterschied im Vergleich zur Verwendung der WebClient Klasse ist allerdings nicht die Tatsache, dass statt des EventHandling-Mechanismus eine callback-Methode mit Hilfe eines Delegates gerufen wird, sondern dass die verwendetet Callback-Methode responseCallback immer in einem eigenen Workthread abgearbeitet wird.
Ronny Schleicher
Seite 25 von 77
Daraus folgt, dass die Verarbeitung der empfangenen Daten in der Methode response Callback() nicht dazu fhrt, dass der Mainthread der Windows Phone 7 Applikation blockiert. Der genaue Ablauf wird im Sequenzdiagramm 4.2 noch einmal dargestellt.
Abbildung 4.2: Sequenzdiagramm mit dem Ablauf der Kommunikation unter Verwendung der Klasse WebRequest. Da die Ausfhrung der Methode responseCallback und somit auch die Abarbeitung der empfangenen Daten in einem eigenen Workthread stattndet, ist ein blockieren des Mainthread bei diesem Ansatz nicht mglich. Es ist in diesem Szenario also angedacht, dass die Windows Phone 7 Applikation ber das UI7 , und damit ber den Mainthread, weiter Eingaben des Benutzers entgegen nehmen kann und im Hintergrund anderer Auftrge in eigenen Workerthreads abarbeitet. Wichtig ist in diesem Zusammenhang auch, dass es nicht mglich ist, aus einem Workerthread heraus direkt auf UI-Elemente, zum Beispiel List-Boxen oder EditFelder, zuzugreifen. Die Ausfhrung des Zugris auf das UI-Element muss immer im MainThread sattnden. Aus diesem Grund wird von .NET Compact Framework 3.5 der Aufruf Dispatcher.BeginInvoke angeboten, der es ermglicht einen Delegaten asynchron auf dem Thread ausfhrt, dem der Dispatcher zugeordnet ist. So kann man relative einfach sicherstellen, dass bestimmte Aufrufe auch im richtigen Thread ausgefhrt werden.
7
User Interface
Ronny Schleicher
Seite 26 von 77
Listing 4.3 zeigt eine Beispielimplementierung der Methode processData, die wiederum die Methode Dispatcher.BeginInvoke einsetzt, um aus einem Workerthread heraus ein UI-Elemente zu aktualisieren: Listing 4.3: Dispatcher.BeginInvoke unter Verwendung des Lambda Operators 1 2 p r i v a t e void p r o c e s s D a t a ( System . IO . S t r e a m R e a d e r s r ) 3 { 4 // V e r a r b e i t u n g d e r Daten 5 // . . . 6 D i s p a t c h e r . B e g i n I n v o k e ( ( ) => 7 { 8 // D i e s e r Code w i r d im M a i n t h r e a d a u s g e f u e h r t 9 mainpage . T e x t E x i t S t a t u s . Text = "Fertig" ; 10 }) ; 11 } Im Listing 4.3 wird mit Hilfe des Lambda Operator => der Funktionsblock, der sich rechts vom Operator bendet, und in dem der Code fr den Mainthread vorhanden ist, als anonyme Methode behandelt. Da dieser Aufruf ohne Parameter ausgefhrt werden soll steht links von Lambda Operator lediglich (). Die Entscheidung, ob eine asynchrone Verarbeitung durch Workerthreads fr die eigene Applikation ntig ist, muss von Fall zu Fall neu Entschieden werden. Ein UI, die fr den Anwender zwecks Eingaben oder Interaktion immer zur Verfgung stehen muss, ist auf den ersten Blick eine interessante Funktionalitt, die allerdings auch durch das eigentliche Programm richtig behandelt werden muss. Insbesondere bei Mehrfacheingaben durch den Benutzer und laufenden Workerthreads muss die eigentliche Anwendungslogik dahingehend konzipiert sein und diesen Ansprchen gerecht werden. Fr groe Datenmengen, die im Hintergrund aufbereitet und erst dann an das UI bergeben werden sollen, ist dieses Modell ein guter Ansatz.
4.2.3 Eingesetzte Technik in der Spirit Applikation

In der Windows Phone 7 Spirit Applikation wird zum Abfragen der Daten die Klasse HttpWebRequest verwendet. Entscheidend dafr ist die Mglichkeit, Daten im Hintergrund abzufragen und die lokalen, also clientseitigen, Datenmodelle asynchron zu fllen. Da die Applikation mehrere Seiten besitzt (siehe Kapitel 6.2), bietet sich so die Mglichkeit, einzelne Seiten asynchron zu fllen falls neue bzw. aktualisierte Daten zur Verfgung stehen, ohne dass der Anwender, der eventuell gerade eine vllig andere Seite der Windows Phone 7 Spirit Applikation nutzt, eine Unterbrechung seiner Interaktion hinnehmen muss.
Ronny Schleicher
Seite 27 von 77
4.3 Verarbeitung der JSON Daten

Nachdem die Mglichkeiten des Empfangs der Daten beschrieben wurden, wird nun untersucht, welche Mglichkeiten es mit dem Windows Phone 7 gibt, um die eigentlichen JSON Daten zu verarbeiten. Im .NET Compact Framework 3.5 sind berraschenderweise keine Klassen enthalten, die die Verarbeitung von JSON komplett bernehmen oder wenigstens rudimentre Schnittstellen zum Lesen oder Schreiben von JSON bieten. Hinweis: Der in diesem Zusammenhang oft verwendete Namespace8 System.Run time.Serialization.Json im Assembly System.ServiceModel.Web, lokalisiert in der System.ServiceModel.Web.dll, ist lediglich Bestandteil des im .NET Framework 3.5, aber nicht des .NET Compact Framework 3.5, und kann demzufolge in dieser Form nicht auf dem Windows Phone 7 eingesetzt werden9 .
4.3.1 Bibliotheken zur Verarbeitung von JSON

Die Recherche nach geeigneten Bibliotheken zur Verarbeitung verlief uert positiv. Nahezu fr jede Sprache nden sich Projekte, die es sich zur Aufgabe gemacht haben geeignet Software, und das grtenteils als Open-Source, zur Verfgung zu stellen. Als besonders hilfreich erweist sich hier www.json.org, wo eine bersicht zu mittlerweile fast 50 Sprachen und Frameworks zur Verfgung steht. Fr den .NET Framework 3.5 sind die folgende elf10 Klassen und Bibliotheken fr den Einsatz in einer Windows Phone 7 Applikation untersucht worden: fastJSON: http://www.codeproject.com/KB/IP/fastJSON.aspx JSON_checker: http://www.raboof.com/projects/jsonchecker/ Jayrock: http://jayrock.berlios.de/ Json.NET - LINQ to JSON: http://james.newtonking.com/ JSONSharp: http://code.google.com/p/jsonsharp/ LitJSON: http://litjson.sourceforge.net/ JSON for .NET: http://sourceforge.net/projects/csjson/
8
Namespaces bzw. Namesrume werden im .NET Framework 3.5 eingesetzte, um Funktionsgruppen sinnvoll zu gliedern. 9 http://msdn.microsoft.com/en-us/library/system.runtime.serialization.json.datacontractjson serializer(v=VS.90).aspx 10 www.json.org
Ronny Schleicher
Seite 28 von 77
JsonFx: http://jsonfx.net/download/ JsonExSerializer: http://code.google.com/p/jsonexserializer/ JSON@CodeTitans: http://codetitans.codeplex.com/ uent-json: http://code.google.com/p/fluent-json/ Interessanterweise untersttzen von diesen 11 Projekten nur Json.NET - LINQ to JSON und JSON@CodeTitans den im Windows Phone 7 und eingesetzten .NET Compact Framework 3.5 explizit. Ursache dafr ist das Fehler einiger Klassen und Namenspaces im .NET Compact Framework 3.5 , die hug in den Implementierungen eingesetzt werden. Falls die Anzahl der Windows Phone 7 Gerte zuknftig eine grere Rolle spielen sollte, bleibt zu hoen, dass hier eine grere Sensibilisierung im Bereich der .NET Compact Framework 3.5 und den folgenden Versionen stattndet. Auerdem war es mglich bei einigen Projekten die Implementierung so anzupassen, dass eine Integration in das Windows Phone 7 funktionierte. Allerdings ist eine solche Vorgehensweise meist sehr aufwendig und nicht ohne Risiken. Zuerst muss bei geplanten nderungen identiziert werden, welches Lizenz-Modell hinter dem Open-Source-Projekt steht, damit klar ist ob und in welcher Form nderungen am Quellcode zulssig sind. Falls hier Klarheit besteht muss im nchsten Schritt die Implementierung des Open-Source-Projektes zu einem groen Teil durchdrungen werden, um sinnvolle nderungen an den fremden Quellen vornehmen zu knnen. Zu guter Letzt kommt es nicht selten vor, dass die nderungen bei jeder neuen Version des angepassten Quellcodes nachgezogen werden mssen, falls sie vom Projektteam der Open-Source-Software nicht bercksichtigt werden. Hier kann somit eine neue Fehlerquelle entstehen, die Beachtung nden muss.
4.3.2 C# und JSON

Fast alle Bibliotheken, die es im Bereich JSON fr .NET gibt, sind in der Programmiersprache C# entwickelt. Ebenso sind viele Beispielimplementierungen fr JSON-Parser zu nden, die C# nutzen. Oft handelt es sich dabei nicht um richtige Open-Source-Projekte, sondern vielmehr um Klassensammlungen, die auf Plattformen wie The Code Project 11 oder sourceforge 12 zu nden sind.
11 12
http://www.codeproject.com http://sourceforge.net/
Ronny Schleicher
Seite 29 von 77
4.3.3 F# und JSON

Viele Implementierungen in F# in Kombination mit JSON-Parsern sind aktuell zwar noch nicht zu nden, das hat aber weniger mit den Mglichkeiten der Sprache zu tun, als vielmehr mit der Tatsache, dass F# einfach noch nicht lange genug existiert, um eine so groe Akzeptanz wie die anderen .NET -Sprachen zu erlangen. Durch den funktionalen Ansatz ist es mit F# mglich, sehr kompakte Parser fr JSON zu schreiben. Im Anhang bendet sich in Listing B.1 eine Beispielimplementierung aus einem Blog, die einen funktionierenden JSON-Parser implementiert. Es ist davon auszugehen, dass gerade bei der Entwicklung von Parser fr Datenformate oder Metasprachen, der Anteil an in F# implementierten Projekten und Bibliotheken stark ansteigen wird. Schon jetzt sind auch alternative XML-Parser zu nden, die mit relativ wenig Quellcode realisiert sind und interessante Alternativen zu kompletten Bibliotheken bieten.
4.3.4 Linq to JSON

Mit Linq to JSON, also einem Linq-Provider fr JSON-Daten, hat man die Mglichkeit, LINQ direkt auf JSON-Daten anzuwenden und so mit einer deklarativen Sprache, die zustzlich auch funktionale Elemente bietet, Daten mit einer sehr kompakten und eleganten Schreibweise zu verarbeiten.
4.3.5 Eingesetzte Technik in der Spirit Applikation

In der Spirit Windows Phone 7 Applikation wird die Open-Source-Bibliothek Json. NET von James Newton-King 13 eingesetzt. In dieser Bibliothek ist ein KlassenSammlung fr die Kapselung von JSON-Daten in Objekte und Arrays enthalten, die auch die Serialisierung und Deserialisierung vom und in das JSON-Format untersttzt. Zustzlich ist ein LINQ to JSON Provider enthalten, der den Einsatz von LINQ auf die JSON-Daten ermglicht. Durch den Einsatz dieser Bibliothek wird der Implementierungsaufwand fr die Verarbeitung und Auswertung der JSON-Daten erheblich verschlank und eine sehr kompakte Umsetzung, wie Listing 6.8 in Kapitel 6.3.3 zeigt, mglich. Die Json.NET Bibliothek ist in allen untersttzen Versionen als Visual Studio 2010 Projektdatei erhltlich. Die jeweiligen Projektdateien enthalten alle in Json.NET implementierten Klassen vollstndig und ohne Einschrnkungen. Das bersetzen der Projekte lsst sich ohne Probleme durchfhren. Abhngigkeiten zu anderen Bibliotheken, die nicht Bestandteil der jeweiligen Version des .NET Frameworks sind, gibt es nicht. Zustzlich stehen auch noch fertig bersetzte Bibliotheken in allen untersttzten Versionen zur Verfgung.
13
http://james.newtonking.com/
Ronny Schleicher
Seite 30 von 77
5 WP7 Spirit Applikation Frontend

In diesem Kapitel werden zuerst die technischen Mglichkeiten beschrieben, die das Windows Phone 7 im Bereich der UI-Entwicklung unter Verwendung von Silverlight bietet. Anschlieend werden die jeweiligen Technologien ausgewhlt und deren Einsatz, im Kontext zu den Anforderungen der Windows Phone 7 Spirit Applikation, begrndet. Der Begri Frontend bezeichnet hierbei die Techniken fr das eigentliche User-Interface und schliet die Mglichkeiten, die die UI-Elemente bieten, um sie mit Daten zu fllen, mit ein.
5.1 UI Design
Der Aufbau der Benutzeroberche einer Windows Phone 7 Applikation in Kombination mit Silverlight nutzt ein Rahmen- und Seitenmodell, auch Frame- and Pagemodel, das im wesentlichem der Idee des Silverlight Page Model 1 entspricht. Nachfolgend wird nur noch der Begri Frame- and Page Model verwendet. Einzelne Seiten werden als Pages, und untergeordneten Seiten als Sub-Pages, bezeichnet. Diese Nomenklatur entspricht den verbreiteten Bezeichnungen in der englischsprachigen MSDN und bekannten Foren, sowie den Bezeichner im .NET Compact Framework 3.5 und im Quellcode den Visual Studio 2010 und Expression Blend 4 Projektdateien. Der Frame, auf den die Pages dargestellt werden, muss von der Applikation angelegt werden, um berhaupt Pages anzeigen zu knnen. In diesen Zusammenhang wird auch von sogenannten Rootframe gesprochen. Das Erstellen des ntigen Quellcodes bernehmen die Entwicklungsumgebungen Visual Studio 2010 und Expression Blend 4, ohne das fr Standartapplikation hier Code gendert werden muss. Instanziiert wird der Rootframe in der Methode private void InitializePhone Application() in der Datei App.xaml.cs. Wirklich angewendet bzw. genutzt wird er allerdings erste wesentlich spter in der Methode private void CompleteIni tializephoneApplication(), ebenfalls lokalisiert in der Datei App.xaml.cs, nachdem die Windows Phone 7 Applikation vollstndig initialisiert wurde. Ursache dafr ist, dass beim Initialisieren von Windows Phone 7 Applikation solange ein Begrungsbildschirm eingeblendet wird, bis die Applikation vollstndig geladen ist. Erst danach wird mit dem Rendering des Rootframes und somit mit der Darstellung der Inhalte begonnen wird. Andersfalls wrde man sonst whrend des Ladevorgangs eventuell einen schwarzen Bildschirm oder hnliche unschne Dinge sehen.
1
http://msdn.microsoft.com/en-us/library/cc838245(v=vs.95).aspx
Ronny Schleicher
Seite 31 von 77
5. WP7 Spirit Applikation Frontend
Wie Abbildung 5.1 zeigt, bildet die Grundlage fr das Frame- and Page Model ein Frame der als Container fr 1-n Pages dient. Durch diese Seiten kann man, angelehnt an das Navigieren durch Webseites, vor- und zurckblttern. Auf den einzelnen Pages werden dann die entsprechenden Inhalte dargestellt.
Abbildung 5.1: Frame- and Page Model [Mic11a] des Windows Phone 7. Der Rootframe ist hier rot umrandet dargestellt. Die Pages als Inhalt vom Rootframe sind grn umrande dargestellt. Die Darstellung der Pages hintereinander soll noch einmal die 1-n Beziehung zwischen dem Rootframe zu den Pages verdeutlichen. Allerdings wird in einer laufenden Applikation, mit Ausnahme von speziellen Designs als Vorschau (siehe Kapitel 5.1.1 fortlaufend), immer nur eine Page komplett dargestellt.
5.1.1 Design-Steuerelemente
Beim Windows Phone 7 wird im Wesentlichen zwischen drei Designs unterschieden, die nachfolgende vorgestellt werden. Alle Designs werden vom Visual Studio 2010 und Expression Blend 4 vollstndig untersttzt und unterscheiden sich hinsichtlich der Einsatzmglichkeiten erheblich voneinander.
Ronny Schleicher
Seite 32 von 77
5. WP7 Spirit Applikation Frontend Page-Design
Beim Page-Design handelt es sich um das einfachste Design, welches vom Windows Phone 7 bzw. der Entwicklungsumgebung Visual Studio 2010 angeboten wird. Die Darstellung beschrnkt sich hier auf eine Page, die alle relevanten Steuerelemente enthlt. Das Page-Design eignet sich besonders fr das Erfassen von Nutzereingaben. Das Windows Phone 7 nutzt dieses Design unter anderem, wenn Kurznachrichten geschrieben werden und im Bereich der Einstellungen bei der Sub-Page zum Einstellen der Uhrzeit. Pivot Das Pivot-Design besteht aus einer oder mehreren Pages. Durch berhren der berschriften oder durch Schiebebewegungen nach links oder rechts kann durch die einzelnen Pages navigiert werden. Die Pages benden sich immer nebeneinander und es wird bei diesem Design nur der Inhalt einer Page angezeigt. Verwendet wird das Pivot-Design bei den meisten Funktionen und Mens, die das Windows Phone 7 im Auslieferungszustand bietet. Hier wird sowohl die Variante mit nur einer Page, unter anderem bei der Telefonliste, als auch Varianten mit mehreren Pages, exemplarisch ist hier der integrierten Kalender zu nennen, eingesetzt. Panorama Wenn man sich das Panorama-Design betrachtet, sind auf der ersten Blick die Unterschiede zum Pivot-Design nur schwer zu erkennen. Vor allem wenn in einem neuen Visual Studio 2010 Projekt die beiden Design-Varianten ohne Testdaten betrachtet werden, ist eine Unterscheidung fast nicht mglich. Beide Design-Varianten stellen nebeneinander ein oder mehrere Pages dar. Durch Schiebebewegungen nach links und rechts ist, wie beim Pivot-Design auch, eine Navigation zwischen den einzelnen Pages mglich. Bei einer genaueren Untersuchung der Funktionalitt ergeben sich allerdings einige Unterschiede, gerade im Bereich der verwendeten Bedien- und Visualisierungskonzeption. Die Navigation zwischen den Pages, die Bestandteil der Panorama-Page ist, ist ausschlielich ber die Schiebebewegung mglich und nicht durch das Berhren der berschriften. Auch sind die berschriften der einzelnen Pages nicht komplett sichtbar und eine Page muss nicht zwangslug denn kompletten Darstellungsbereich verwenden. So ist es mglich durch die Schiebebewegungen nach links oder rechts schon Teile der benachbarten Page anzeigen, ohne komplett auf diese zu wechseln. Es ist also mglich, in dieser Design-Variante den Inhalt von mehr als einer Page gleichzeitig anzuzeigen. Verwendung ndet das Panorama-Design beim Windows Phone 7 im Auslieferungszustand unter anderem bei den Kontakten und Bildern. Ebenso sind der Marketplace zum Erwerb neuer Software und Musik, sowie der XBOX-Hub zum Erwerb von Spielen mit dem Panorama-Design umgesetzt. Auch zahlreiche Applikationen anderer Anbieter, die primre Informationen bereitstellen, verwenden dieses Design als oberstes Steuerelement in der Benutzerfhrung.
Ronny Schleicher
Seite 33 von 77
5.1.2 Bildschirmorientierung
Das Windows Phone 7 bietet mit Portrait 2 und Landscape 3 zwei Bildschirmorientierungen an, die in jeder Windows Phone 7 Applikation verwendet werden knnen. Die Standartorientierung fr die meisten im Windows Phone 7 integrierten Applikationen ist Portrait. Eine Ausnahme bildet das Fotograeren und die Wiedergabe von Videos, wo die Standartorientierung Landscape ist. Ein eher geringer Teil der Applikationen, wie die E-Mail-Verwaltung und der Internet Explorer nutzten beide Darstellungsarten in ihren Oberchen. Falls eine Applikation beide Bildschirmorientierungen untersttzten soll, muss dies schon zum Entwurfszeitpunkt, egal ob mit Silverlight (Kapitel 3.3.1) oder XNA (Kapitel 3.3.2) gearbeitet wird, beachtet werden. Unter Verwendung des Beschleunigungssensors (Kapitel 3.2) wird dafr ein Rotationsschwellwert 4 ermittelt, mit dessen Hilfe die aktuelle Orientierung der Applikation errechnet wird. Das Umschalten der Bildschirmorientierung erfolgt dann automatisch. Silverlight ist vom Ansatz her allerdings so konzipiert, dass lediglich eine Bildschirmorientierung untersttzt wird. Es ist aber trotzdem mglich mit speziellen Layouts5 und Implementierungsrichtlinien, welche in der MSDN zu nden sind, Applikationen zu entwickeln, die beide Darstellungsarten auf einer Page implementieren. Bei XNA ist die Standartorientierung Landscape, was allerdings im Quellcode per Parameter gendert werden kann. Ein Wechsel zwischen den Orientierungen wird vom XNA-Framework nicht untersttzt und muss komplett von Hand implementiert werden. Hierfr gibt es allerdings Beispielimplementierungen in der MSDN, die genutzt werden knnen. Portrait Bei der Portrait-Orientierung wird zwischen PortraitUp und PortraitDown unterschieden. PortraitUp bezeichnet die eigentliche Standartorientierung, bei der sich die kapazitiven Gertetasten (siehe Kapitel 3.2) an der Unterseite benden. Dreht man das Gert um 180 Grad auf den Kopf entspricht das der PortraitDown-Orientierung. Der Rotationsschwellwert fr einen Wechsel von Landscape zu Portrait betrgt 60 Grad nach links bzw. rechts. Wenn das Gert mit Landscape-Orientierung ach auf dem Tisch liegt reicht eine Vernderung von 30 Grad, um einen Orientierungswechsel hin zu Portrait auszulsen. Landscape Die Landscape-Orientierung unterscheidet intern zwischen LandscapeLeft, wo sich die kapazitiven Gertetasten an der rechten Seite des Bildschirms benden, und LandscapeRight, mit den Tasten an der linken Bildschirmseite.
2 3
Hochformat Querformat 4 Grenzwert fr die Bildschirmausrichtung in Grad, um von einer Orientierung in eine anderen zu wechseln. 5 Umsetzung meist mit einem Grid-Layout.
Ronny Schleicher
Seite 34 von 77
Um einen Wechsel von der Landscape-Orientierung zur Portrait-Orientierung auszulsen, Betrgt der Rotationsschwellwert von links bzw. rechts ebenfalls 60 Grad. Wenn das Gerte ach auf den Tisch betrgt der Rotationsschwellwert 30 Grad.
5.1.3 Eingesetzte Techniken in der Spirit Applikation

Im Rahmen der Entscheidungsndung, welche Designs und welche Orientierung fr die Windows Phone 7 Spirit Applikation am praktikabelsten sind, wurde zunchst Applikationen anderer Anbieter untersucht, die eine hnliche Funktionalitt bieten. Anschlieend wurden Prototypen mit Expression Blend 4 implementiert und mit Testdaten gefllt, um festzustellen, welches Konzept beim Benutzen der Applikation den besten Eindruckt hinterlsst. So kam es zu der Entscheidung, bei der Windows Phone 7 Spirit Applikation als Benutzeroberche das Panorama-Design mit Portrait-Orientierung einzusetzen. Ursache dafr sind die gute Bedienbarkeit und die ansprechenden Gestaltungsmglichkeiten des Panorama-Designs. Bei Sub-Pages, und Pages die Benutzereingaben erfordern, wird das unspektakulrere Page-Design angewendet, da hier keine schnelle Navigation zu anderen Pages ntig ist.
5.2 XAML
XAML6 ist eine deklarative Markupsprache. Sichtbare UI-Elemente knnen im deklarativen XAML-Markup erstellt und anschlieend die UI-Denition mithilfe von Code-Behind-Dateien, die ber partielle Klassendenitionen an das Markup geknpft sind, von der Laufzeitlogik getrennt werden. XAML stellt die Instanziierung von Objekten in einem spezischen Satz von in Assemblies denierten Untersttzungstypen direkt dar. Dieser Ansatz unterscheidet sich von anderen Markupsprachen, die in der Regel interpretierte werden. XAML ermglicht das Arbeiten an UI und Logik einer Anwendung zudem mit unterschiedliche Personen und unterschiedlichen Tools.7
5.2.1 XAML in Silverlight und dem Windows Phone 7

Wenn eine Windows Phone 7 Applikation mit Silverlight umgesetzte wird, beinhaltet ein Groteil der Oberchenentwicklung die Erstellung von XAML-Dateien. XAML dient hierbei als das Format, in dem die in Silverlight verwendetet Oberchenbeschreibungssprache abgebildet wird. Zu jeder XAML-Datei gehrt bei diesem Konzept immer eine so genannte Code-Behind-Datei, die die eigentliche Programmlogik enthlt. Im MSDN8 wird die eigentlich XAML-Datei als Markup und die korrespondierende Code-Behind-Datei lediglich als Code-Behind bezeichnet. Diese Nomenklaturen nden auch in den folgenden Kapiteln Verwendung.
Extensible Application Markup Language Quelle: http://msdn.microsoft.com/de-de/library/ms752059.aspx#what_is_xaml 8 Microsoft Developer Network: http://msdn.microsoft.com/de-de/
7 6
Ronny Schleicher
Seite 35 von 77
5.2.2 Markup
Listing 5.1 deniert einen Button, der beim Ereignis Click die Methode buttonClick ausfhrt. Die Methode buttonClick ist im korrespondierenden Code-Behind implementiert, wie Listing 5.2 zeigt. Listing 5.1: Datei: Page.xaml <p h o n e : P h o n e A p p l i c a t i o n P a g e x : C l a s s=" WindowsPhoneApplication .Page" ... S u p p o r t e d O r i e n t a t i o n s=" Landscape " O r i e n t a t i o n=" Landscape " d : D e s i g n H e i g h t="480" d : D e s i g n W i d t h="728" s h e l l : S y s t e m T r a y . I s V i s i b l e ="True"> <G r i d x:Name=" LayoutRoot " Background=" Transparent "> <Button C o n t e n t="Button" Name="button1" Margin=" 150 ,150 ,150 ,150" C l i c k=" button1_Click " /> </ G r i d> </ p h o n e : P h o n e A p p l i c a t i o n P a g e>
1 2 3 4 5 6 7 8 9 10
Hinweis: Listing 5.1 enthlt nur die wichtigsten und zum Verstndnis ntigen Elemente. Sonstige TAGS zum Denieren von Namensrumen und setzten von zustzlichen Attribute sind durch (...) substituiert worden. Das Attribute x:Class deniert den Klassennamen, SupportedOrientations deniert, welche Orientierung von dieser Page untersttzt wird. Als mgliche Werte sind "Landscape", "Portrait" oder "PortraitOrLandscape" anwendbar. Die eigentliche Orientierung des Bildschirms ist in dem Attribut Orientation="Landscape" festgelegt. Sich gegenseitig ausschlieende Kombinationen sind in der Konguration nicht mglich. d:DesignHeight="480" und d:DesignWidth="728" legen die Gre der Page fest. Mit tshell:SystemTray.IsVisible="True" wird festgelegt, dass beim Anzeigen der Page im Hochformat der Statusbar9 dauerhaft eingeblendet wird. Dies kann bei Applikationen, die grere Datenmengen ber die vorhandenen Datenverbindungen laden mssen, durchaus von Vorteil sein. Mit diesen Attributen sind die Umgebungsparameter der Page, die dargestellt werden soll, festgelegt. Der eigentliche Inhalt der Page wird zwischen <Grid und </Grid> beschrieben. Hier wird das sogenannte Root-Layout deniert. Dieses Grid-Layout dient als Basis fr die UI-Elemente, die in diesen Tag enthalten sind. Das Attribute x:Name="Layout Root" deniert den Namen des Layouts und mit Background="Transparent", dass das Layout einen transparenten Hintergrund hat. Die Zeile <Button ... /> wird ein Button erzeugt dessen Beschriftung durch das Attribute Content="Button" einfach auf "Button" gesetzt wird und dessen Objektname mit Name="button1" festgelegt wird. Mit Margin="150,150,150,150" wird der Abstand des UI-Elementes zum Rand des korrespondierenden Layouts festgelegt. Das Eingabeformat ist hier
9
Visualisiert mit kleinen Symbolen unter anderem die Signalstrke WLAN- und Datenverbindungen.
Ronny Schleicher
Seite 36 von 77
Abstand linker Rand, Abstand oberer Rand, Abstand rechter Rand, Abstand rechter Rand. Im Ergebnis stellt das Markup so eine recht einfache Mglichkeit da, ein UIElement zentriert dazustellen. Mit Click="button1_Click" wird das Ereignis von Typ Click mit der Methode "button1_Click" verknpft, die im entsprechenden Code-Behind in Listing 5.2 lokalisiert ist und in der die Behandlung des Ereignisses implementiert ist.
5.2.3 Code-Behind
Im Code-Behind des Markups aus Listing 5.1 bendet sich die Implementierung des Event-Handlers. Als Richtiglinie gilt hier, dass so wenig Quellcode wie mglich in die eigentliche Code-Behind-Datei geschrieben werden soll. Somit ist das Code-Behind als Bindeglied zwischen der UI und der eigentlichen Programmlogik zu sehen. Hinweis: Listing 5.2 enthlt eine komplett bersetzbare Implementierung der Klasse WindowsPhoneApplication. Allerdings sind aus platzgrnden die ntigen using Anweisungen durch (...) substituiert worden. Listing 5.2: Inhalt des Code-Behind in C#. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 using System ; ... namespace W i n d o w s P h o n e A p p l i c a t i o n { p u b l i c p a r t i a l c l a s s Page : P h o n e A p p l i c a t i o n P a g e { p u b l i c Page ( ) { InitializeComponent () ; } p r i v a t e void b u t t o n C l i c k ( o b j e c t s e n d e r , R o u t e d E v e n t A r g s e ) { MessageBox . Show ( "Hello World" ) ; } } } In Listing 5.2 ist zu sehen, dass der Ereignisname und der Name des zu verwendenden Handlers im Markup angegeben sind (Listing 5.1), whrend der Quellcode, der den Event-Handler implementiert, im Code-Behind deniert wird. In Codezeile 5 ist die Klasse WindowsPhoneApplication zustzlich mit dem Schlsselwort partial als partieller Typ deniert. Das bedeutet, dass sich die Implementierung der Klasse ber mehrere Abschnitte verteilen kann und diese in unterschiedlichen Dateien lokalisiert sind. Die Notwendigkeit von partiellen Klassen liegt darin begrndet, das neben der Implementierung im Code-Behind auch aus dem Markup Quellcodedateien generiert werden, die Teile der Implementierung der Klasse WindowsPhoneApplication sind.
Ronny Schleicher
Seite 37 von 77
Hier wird auch noch einmal deutlich, dass Markups nicht zur Laufzeit interpretiert werden, sondern in Quellcode umgewandelt und bersetzt werden. In Codezeile 11 beginnt die Implementierung des Event-Handlers der eine Message-Box mit dem Inhalt Hello World erzeugt.
5.2.4 Ergebnis Markup und Code-Behind

Das Ergebnis der Page.xaml in Listing 5.1 und des dazugehrigen Code-Behind in Listing 5.2 zeigen Abbildung 5.3 und Abbildung 5.3 im Windows Phone 7 Emulators, der Bestandteil der Windows Phone 7 Developer Tools ist.
Abbildung 5.2: Screenshot Windows Phone 7 Emulator mit dem erzeugten Button. Nach Klick auf den in Listing 5.1 denierten Button erscheint die im Event-Handler in Listing 5.2 implementierte Message-Box.
Abbildung 5.3: Screenshot des Windows Phone 7 Emulator mit Messagebox.
Ronny Schleicher
Seite 38 von 77
5.2.5 Verwendeten Techniken in der Spirit Applikation

Das es im Bereich der UI-Entwicklung mit Silverlight keinen Alternativen zum XAML-Konzept gibt, wird diese Technologie dementsprechend auch in der Windows Phone 7 Spirit Applikation verwendet. Trotz der Alternativlosigkeit bei der Auswahl ist dies keine schlechte Entscheidung. Durch die Trennung von Markup und Code-Behind sind selbst Applikationen mit viel Funktionalitt und UI bersichtlich zu bearbeiten und mit dem Visual Studio 2010 und Expression Blend 4 stehen zwei auergewhnlich gute Werkzeuge zur Verfgung. Auch die Einarbeitung in das doch eher umfangreiche Thema, ist durch sehr gute Dokumentation, auch fr Entwickler die dieses Konzept berhaupt nicht kennen, in der Regel mit einer steilen Lernkurve verbunden.
5.3 XAML und Datenreprsentation

Eine immer intensiv diskutierte Frage bei fast alle Softwareentwicklungen ist die Realisierung der Trennung zwischen UI- und Applikationslogik. Das Windows Phone 7 bietet mit den Konzepten, die in Silverlight enthalten sind, einige interessante Mglichkeiten, verschiedene Anstze zu realisieren. Nachfolgend wird allerdings nicht auf diverse Entwurfsmuster der Softwareentwicklung eingegangen, die sich mit diesen Themen sehr ausfhrlich beschftigen und fr viele Szenarien Lsungen bieten. Im Gegensatz zu den fertigen Lsungen der Entwurfsmuster werden nachfolgend lediglich die technischen Mglichkeiten beschrieben, die zur Verfgung stehen, um Daten in dem UI zu reprsentieren und zu manipulieren. Diese technologischen Mglichkeiten bieten im Umkehrschluss dann natrlich die Implementierungsgrundlage fr verschiedene Entwurfsmuster, die im Kapitel 6 angewendet werden.
5.3.1 UI-Elemente und Code-Behind

Eine Mglichkeit, die UI-Elemente zu fllen, ist die einfache Implementierung im Code-Behind. Die Elemente, die im Markup deniert werden sind normale Member in der partiellen Klasse, auf die natrlich auch im Code-Behind mittels getter und setter zugegrien werden kann. Diese Vorgehensweise stellt, mit wenigen Ausnahmen, eine sehr statische Lsung dar, die sich bestenfalls fr einen kleinen Prototypen eignet. Die Prmisse, dass, aus entwurfstechnischer Sicht, das Markup so wenig selbst programmierten Quellcode enthalten sollte wie mglich, wird hier komplett ignoriert. Auerdem ist bei diesem Ansatz eine Trennung von UI- und Applikationslogik schwer bzw. gar nicht zu erkennen, da der Quellcode fr die Datenverwaltung und der eigentlichen Datenprsentation in den gleichen Klassen lokalisiert ist.
5.3.2 UI-Elemente und Modelle

Wesentlich ezienter ist das Nutzen von Datenquellen und Modellen. Dabei wird im Markup eine Datenquelle fr ein UI-Element angegeben, die im Code-Behind an ein
Ronny Schleicher
Seite 39 von 77
Modell gebunden wird. Unter Modell ist hier ein Klasse zu verstehen, die vom Interface INotifyPropertyChanged ableitet ist, einen PropertyChangedEventHandler implementiert und mit Hilfe von Properties 10 Daten aufnehmen und zur Verfgung stellen kann. Auf Applikationsseite wird nun lediglich das Modell manipuliert, ohne dass ein direkter Zugri auf die UI-Elemente implementiert werden muss. Besonders bei zusammengesetzten UI-Elementen, die logisch zu einem Modell zusammengefasst werden knnen, ist das eine leistungsfhige Technik, um Daten in der UI zu reprsentieren und dabei klar zwischen UI- und Applikationslogik zu trennen. Wenn Datenquellen und Modelle im Markup fr die UI-Elemente verwendet werden, ergibt sich ein weiterer Vorteil. Es ist nun mglich eine weitere Datenquellen anzugeben, die nur zum Entwurfszeitpunkt ausgewertet wird. Das bedeutete, dass die UI-Elemente, die mit Modell verknpft sind, schon zum Entwurfszeitpunkt im Designer des Visual Studio 2010 oder Expression Blend 4 diese Testdaten anzeigen, ohne dass die Applikation vorher bersetzt werden muss. Man entwirft seine Oberche also nicht einfach mit leeren List- oder Combo-Boxen, sondern sieht schon im Designprozess, wie das UI gefllt mit Daten aussieht. Als Basis fr diesen sogenannte Design-DataContext dient eine XAML-Datei, die, wie eingangs erwhnt, im Markup der Page deniert werden muss. In dieser Datei werden nun die entsprechenden Modelle mit Daten gefllt und dann in der Entwurfsphase vom Designer im Visual Studio 2010 oder Expression Blend 4 verwendet. Allerdings funktioniert der Design-DataContext zum jetzigen Zeitpunkt nicht korrekt, wenn die Modell mit der Programmiersprache F# implementiert sind. Ursache hierfr sind Verweise, die vom Interpreter der XAML-Datenquelle seltsamerweise nicht korrekt aufgelst werden knnen. Das Problem ist bekannt und es ist davon auszugehen, dass es mit dem nchsten Hotx bzw. Servicepack behoben wird, da die Sprache F# im speziellen und die gemischtsprachige Programmierung des .NET Compact Framework 3.5 im Allgemeinen, Aushngeschilder der Windows Phone 7 Softwarewareentwicklung sind. Aktuell stellt dieses Problem allerdings eine erhebliche Einschrnkung dar, wenn man mit einem Design-DataContext arbeitet und auch die Werkzeuge wie Expression Blend 4 entsprechend einsetzt.
5.3.3 Eingesetzte Techniken in der Spirit Applikation

Die in der Windows Phone 7 Spirit Applikation eingesetzten UI-Elemente werden durch Modelle mit Daten gefllt und manipuliert. Der Zugri auf die UIElemente ndet also ber die Modelle in der Applikationslogik statt. Auch der Design-DataContext ndet Verwendung. Da allerdings ein Teil der Modell, siehe Kapitel 6.4.2, mit der Programmiersprache F# implementiert ist, funktioniert der Design-DataContext nur eingeschrnkt.
10
Membervariablen einer Klassen die mit gettern und bzw. oder settern verfgbar sind.
Ronny Schleicher
Seite 40 von 77
Als Programmiersprache fr die Code-Behind-Dateien wird C# verwendet. Der Grund dafr ist, das C# in allen Visual Studio 2010 und Expression Blend 4 Varianten untersttzt wird und durch seine Integration eine sehr gut Mglichkeit fr die Umsetzung von Anforderungen mit beiden Werkzeugen bietet. Fr die Modelle knnen prinzipiell alle .NET Sprachen genutzt werden, die zur Verfgung stehen. Im Hinblick auf moderne funktionale und imperative Sprachen wird fr die Modelle F# und C# verwendet. Im Kapitel 6.4.3 ndet ein Vergleich der beiden Sprachen in Bezug auf die Implementierung der Modellen statt. Neben der Trennung der Modelle durch Namesrume und verschiedene Sprachen ist es natrlich auch mglich, die Modelle in einzelnen DLLs zu separieren. Diese Herangehensweise bietet meist die Grundlage fr eine saubere Trennung zwischen den Modellen, der UI und der eigentlichen Applikationslogik. Ringabhngigkeiten fallen sofort durch Fehlermeldungen auf und demzufolge wird die gewnschte Unabhngigkeit zwischen den einzelnen Programmteilen in hohem Mae gewhrleistet. In der Windows Phone 7 Spirit Applikation sind deshalb nicht nur die Modelle sondern auch die Applikationslogik in eigenen DLLs lokalisiert.
Ronny Schleicher
Seite 41 von 77
6 Systementwurf und Implementierung

Dieses Kapitel beschreibt den Entwurf und die Implementierung der Windows Phone 7 Spirit Applikation unter Verwendung der in den Kapiteln 4 und 5 gewonnen Erkenntnisse. Das Kapitel gliedert sich in vier Abschnitte. Zunchst wird in Abschnitt 6.1 eine Systemberbersicht ber die entwickelte Windows Phone 7 Spirit Applikation gegeben. Anschlieend wird die Implementierung vom Frontend in Abschnitt 6.2, vom Backend in Abschnitt 6.3 und der Modelle in Abschnitt 6.4 beschrieben.
6.1 Systembersicht
Nachfolgend wird ein Top-Down-Entwurf der Windows Phone 7 Spirit Applikation dargestellt. Hierbei sollen die implementierten Komponenten und die Interaktion der Komponenten miteinander verdeutlicht werden. Unter Komponente werden in diesem Zusammenhang immer Teile von Software verstanden, die eine logische Zusammengehrigkeit besitzen und in einer oder mehreren DLLs lokalisiert sind. Das Windows Phone 7 Spirit Applikation ist vom Systementwurf her in drei Komponenten unterteilt, die in vier DLL implementiert sind. Die Tabelle 6.1 stellt hierbei eine bersicht ber die Komponenten und die in ihnen verwendeten Technologien dar: Komponente FHSSpirit-App FHSSpirit-DataControl Modelle verwend. Sprachen und Techniken XAML C# LINQ C# F# C# Anzahl der DLLs 1 1 2
Tabelle 6.1: bersicht ber die Komponenten der Windows Phone 7 Spirit Applikation mit den verwendeten Technologien. Die FHSSpirit-App (Abschnitt 6.2) stellt hierbei die umfangreichste Komponente dar und beinhaltet das Frontend. Das FHSSpirit-DataControl (Abschnitt 6.3) implementiert das Backend und die Modelle (Abschnitt 6.4) implementieren die eigentlichen Datenmodell, die in der Windows Phone 7 Spirit Applikation verwendet werden.
Ronny Schleicher
Seite 42 von 77
6. Systementwurf und Implementierung
6.1.1 Komponentendiagramm der Spirit Applikation

Das Komponentendiagramm 6.1 zeigt die drei Komponenten der Windows Phone 7 Spirit Applikation mit ihren Assoziationen untereinander. Zustzlich zeigt es noch drei horizontale Swimlanes 1 , welche die Interface-Komponenten darstellen, die im Anwendungskontext des Gesamtsystems ebenfalls einen Rolle spielen.
Abbildung 6.1: Komponentendiagramm der Windows Phone 7 Spirit Applikation mit den Interfaces.
Swimlanes dienen in UML2.0 dazu, organisatorische Zustndigkeiten und Gruppierungen in UML Diagrammen besser darstellen zu knnen.
Ronny Schleicher
Seite 43 von 77
6. Systementwurf und Implementierung Swimlane Benutzer
Im oberen Teil in Abbildung 6.1 wird mit der Swimlane Benutzer die Schnittstelle zur eigentlichen UI und zum Windows Phone 7 an und fr sich dargestellt. Sie soll verdeutlichen, das die Windows Phone 7 Spirit Applikation nicht die komplette Benutzerinteraktionen, die mit dem Windows Phone 7 mglich sind, implementiert hat, sondern lediglich gegen ein Interface entwickelt ist, das vom Windows Phone 7 bereitgestellt wird. Gemeint sind hier Benutzeraktionen wie eingehenden Anrufe, das Aktivieren der Kamera oder auch eine vom Windows Phone 7 eingeblendete Meldung fr einen zu schwachen Akkustand und der daraus resultierenden Notabschaltung des Gertes. Smtliche Benutzer- und auch Systemaktionen des Windows Phone 7 sind in der Schnittstelle verallgemeinert, und auf lediglich vier Systemfunktionen reduziert: private void Application_Launching(...) Diese Methode wird nur beim Starten, aber nicht beim Reaktivieren der Applikation ausgefhrt. private void Application_Activated(...) Diese Methode wird beim Reaktivieren der Applikation, also wenn sie wieder in den Vordergrund gebracht wird, ausgefhrt. Beim Starten der Applikation wird diese Methode nicht ausgefhrt. private void Application_Deactivated(...) Diese Methode wird ausgefhrt, wenn die Applikation in den Hintergrund gebracht, und somit deaktiviert, wird. Beim Schlieen der Applikation wird diese Methode nicht ausgefhrt. private void Application_Closing(...) Diese Methode wird beim Schlieen der Applikation ausgefhrt. Beim Deaktivieren wird diese Methode nicht ausgefhrt. Das bedeutet im Ergebnis, dass diese vier Schnittstellen implementiert werden mssen, falls eine Applikation eine Abarbeitung von Daten oder Protokollen bentig, wenn sie von auen beendet oder deaktiviert wird. Die Windows Phone 7 Spirit Applikation bedient diese Schnittstellen zurzeit mit einer Standartimplementierung und kann jederzeit auch von auen deaktiviert oder beendet werden. Swimlane Windows Phone 7 Spirit Applikation Die Swimlane Windows Phone 7 Spirit Applikation in Abbildung 6.1 entspricht dem, was die eigentliche Windows Phone 7 Spirit Applikation als Implementierung enthlt. Zu sehen sind die drei Komponenten FHSSpirit-App, FHSSpirit-DataControl und die Modelle. Die Assoziationen zwischen der FHSSpirit-App und Windows Phone UI entspricht dem, was in Kapitel 6.1.1 Swimlane Benutzer bereits beschreiben ist. Die Assoziation zwischen den FHSSpirit-DataControl und dem Cloud-Service stellt im Wesentlichen die implementierte Rest-Schnittstelle dar, um Daten anfragen und senden zu knnen. Zwischen der FHSSpirit-App und dem FHSSpirit-DataControl gibt es ebenfalls eine
Ronny Schleicher
Seite 44 von 77
Assoziation, da das Frontend die Benutzerinteraktion als Auftrag an das Backend schickt und das Backend die angeforderten Daten dem Frontend zur Verfgung stellt. Sowohl das Frontend(FHSSpirit-App) als auch das Backend(FHSSpirit-DataControl) mssen die Modelle kennen, da die Modelle direkt im Backend mit Daten gefllt, anschlieend an das Frontend geschickt und dort weiterverarbeitet werden. Deswegen besitzen sowohl die FHSSpirit-App also auch das FHSSpirit-DataControl eine Assoziation zu den Modellen. Durch den Einsatz solcher applikationsweiten Datenmodelle entfllt das so genannte Object-Mapping, bei dem Datenstrukturen, die vom einer Komponente erzeugt werden, fr die Verarbeitung in der anderen Komponenten erst auf deren interne Daten- und Objektstruktur umgerechnet werden mssen. Da sich im Systementwurf der Windows Phone 7 Spirit Applikation die Modelle separate in einer eigenen Komponente benden, ist ihre Verwendung im Frontund Backend mglich, ohne dass sich durch ihre Verwendung neue Abhngigkeiten ergeben. Swimlane Cloud-Service Die unterste in Abbildung 6.1 enthaltenen Swimlane Could-Service steht in erster Linie fr der FHS-Spirit Rest-Service, dessen Interface in dieser Swimlane auch enthalten ist. Da die implementierte Schnittstelle mit Rest allerdings einem oziellen Standard entspricht, ist auch eine Kommunikation zu einem anderen Rest-Services mglich. Auerdem soll mit der separaten Swimlane noch einmal verdeutlich werden, das zum Gesamtkonzept des Spirit-Projektes auch ein Cloud-Service mit RestSchnittstelle gehrt, der allerdings ledig ber das implementierte Interface mit der Windows Phone 7 Spirit Applikation assoziiert ist.
6.2 Implementierung der FHSSpirit-App

Die FHSSpirit-App DLL bildet das Frontend der Windows Phone 7 Spirit Applikation. Sie enthlt die Implementierung der partiellen Klasse public partial class App : Application, in der der Einstiegpunkt fr die Windows Phone 7 Applikation lokalisiert ist. Dies ist mit dem main Einstiegpunkt in anderen Sprachen vergleichbar. Auerdem implementiert sie als Frontend alle Pages mit den dazu ntigen Markup und Code-Behind-Dateien. Sie ist die einzigen DLL, die sowohl mit dem Visual Studio 2010 und Expression Blend 4 bearbeitet wird und dementsprechend generierten und selbst geschriebenen Quellcode enthlt.
6.2.1 Elemente der FHSSpirit-App

Die Elemente, die wie folgt beschreiben werden, entsprechen im Wesentlichen dem Inhalt der Projektdatei des Visual Studio 2010 bzw. Expression Blend 4 und sollen in Zusammenhang mit der Funktionsweise der Windows Phone 7 Spirit Applikation gebracht werden.
Ronny Schleicher
Seite 45 von 77
6. Systementwurf und Implementierung Klasse App
Die partielle Klasse public partial class App : Application stellt neben dem Haupteinstiegpunkt und dem Rootframe auch die statische Zugrimethode public static MainViewModel ViewModel() bereit. Die Methode hat als Rckgabe die Klasse MainViewModel, die in der DLL FHSSpirit-DataControl lokalisiert ist und die Aufgabe hat, die dort enthaltenen Modelle, die letztendlich auch wieder auf Klassendenitionen beruhen, zu verwalten. Pages Die in der Windows Phone 7 Spirit Applikation enthaltenen Pages sind alle in der FHSSpirit-App lokalisiert. Sie bestehen immer aus einen Markup, mit der Nomenklatur Klassenname.xaml, und dem dazugehrigen Code-Behind, mit der Nomenklatur Klassenname.xaml.cs. Eine besondere Rolle nimmt hier die Klasse MainPage auf die in Kapitel 6.2.2 noch genauer eingegangen wird. Ressouren Alle fr eine Windows Phone 7 Applikation bentigten Ressourcen, wie verwendete Icons, Logos und Versionsinformationen, benden sich in der DLL FHSSpirit-App. Es werden in dieser Applikation keine Ressourcen dynamisch nachgeladen. Alle fr die Windows Phone 7 Spirit Applikation ntigen Dateien werden unter Verwendung des Ressourcen-Compilers fest in die Applikation gebunden. Diese Vorgehensweise erleichtert die Bereitstellungen, die in Kapitel 7 beschrieben ist, erheblich. SampleData Die Datei MainViewModelSampleData.xaml enthlt Testdatenstze, die zum Designzeitpunkt angezeigt werden knnen. Ich Kapitel 5.3.2 werden die Voraussetzungen dafr beschrieben. Die Datei kann nach entsprechend ihrer recht einfachen Syntax beliebig erweitert werden. Wichtig ist hier, dass die Assemblies korrekt gesetzt sind, wenn sich die verwendeten Modelle in anderen DLL benden. 1 2 3 4 5 6 Listing 6.1: Ausschnitt aus der Datei: MainViewModelSampleData.xaml <l o c a l : M a i n V i e w M o d e l ... x m l n s : x="http: // schemas. microsoft .com/winfx /2006/ xaml" x m l n s : l o c a l="clr - namespace:FHSSpiritDataModels ; assembly = FHSSpiritDataModels " ... </ l o c a l : M a i n V i e w M o d e l> Abbildung 6.1 zeigt einen Ausschnitt der Datei MainViewModelSampleData.xaml. Von besonderer Bedeutung ist hier Codezeile 4, die den Assembly-Verweis auf die Modelle im FHSSpirit-DataControl enthlt und in dieser Datei von Hand eingetragen werden muss.
Ronny Schleicher
Seite 46 von 77
6.2.2 Funktionsweise der FHSSpirit-App

Die Funktionsweise der FHSSpirit-App basiert, wie fr Silverlight Applikationen auf dem Windows Phone 7 blich, auf dem einem angepassten MVVM 2 Entwurfsmuster. Eine komplett sauberer Implementierung des MVVM-Entwurfsmusters ist aufgrund einiger nicht vorhandener Funktionalitten, wie Commands, nicht ohne weiteres mglich[Mic09]. Instanzierung Die FHSSpirit-App instanziiert alle Komponenten, die fr die Windows Phone 7 Spirit Applikation bentigt werden. Dazu gehrt die Klasse MainViewModel, die als Singleton implementiert ist und selbst alle Modelle instanziiert und verwaltet. Auerdem werden die ntigen Controls instanziierte, die sich in der Komponente FHSSpirit-DataControl benden. Aufrufe, die vom den Objekten im FHSSpiritDataControl zurck an die FHSSpirit-App gesendet werden mssen, sind mit Delegaten realisiert. Somit ndet die Kommunikation von der Komponente FHSSpiritDataControl zur Komponente FHSSpirit-App statt, ohne das die Komponente FHSSpiritDataControl die Komponente FHSSpirit-App kennen muss. MainPage Die Klasse MainPage nimmt in der Funktionalitt der Komponente FHSSpirit-App eine besondere Rolle ein. Im Konstruktor dieser Klasse werden die Delegaten fr das FHSSpirit-DataControl festgelegt, damit die Daten, die das Ergebnis von asynchronen Anfragen das FHSSpirit-DataControl sind, vom FHSSpirit-DataControl zurck an die FHSSpirit-App gesendet werden knnen. Listing 6.2: Festlegung der Delegaten im Konstruktor der Klasse MainPage p u b l i c p a r t i a l c l a s s MainPage : P h o n e A p p l i c a t i o n P a g e { D a t a C o n t r o l N e w s m_DataControlNews ; p u b l i c MainPage ( ) { ... t h i s . m_DataControlNews = D a t a C o n t r o l N e w s . I n s t a n c e ; t h i s . m_DataControlNews . m_del_ErrorMessage = t h i s . showError ; t h i s . m_DataControlNews . m_del_ResponseNews = t h i s . responseNews ; ... } ... }
1 2 3 4 5 6 7 8 9 10 11 12 13
Model-View-ViewModel
Ronny Schleicher
Seite 47 von 77
In Listing 6.2 wird in Codezeile 3 eine Referenz des Typs DataControlNews deniert, die in Codezeile 7 mit dem Property Instance auf eine konkrete Instanz der Klasse festgelegt wird. In den Codezeilen 8 und 9 werden zwei Delegaten der Klasse DataControlNews an die Methoden public void showError(...) und public void responseNews(...) der Klasse MainPage gebunden. Wichtig ist in diesem Zusammenhang, das die Parameterlisten der verwendete Methode und des Delegaten identisch sein mssen. Somit ist es mglich, das die Instanz der Klasse DataControlNews Methoden der Klasse MainPage rufen kann, ohne diese direkt zu kennen. Binden der Sichten an die Modelle Die Sichten, oder auch Views, werden im Markup deniert. Hierbei kann es sich um einfache List-Views oder Textfelder handeln, oder auch um selbst denierte UI-Elemente. Die Sichten werden im jeweiligen Markup an die Modelle gebunden. Dies geschieht mit dem Attribut DataContext, wo direkt der Name des Modelles angegeben wird. Die Zuweisung eines Properties aus dem Modell wird dann direkt mit dem Output-Property des UI-Elementes verknpft. Listing 6.3: Ausschnitt aus einem Markup mit Datenbindung der View. 1 <S t a c k P a n e l> 2 <T e x t B l o c k Text="{Binding Owner}" "{Binding Item_CurrentMessage }" /> 3 </ S t a c k P a n e l> Listing 6.3 zeigt den Ausschnitt eines Markups, in dem ein TextBlock deniert wird, der sich auf einem StackPanel bendet. In Codezeile 3 wird die View an ein Modell mit Namen Item_CurrentMessage gebunden und das Property des Modells Binding Owner fr den Inhalt der View verwendet. Dateien an die Modelle gebunden. Ereignissbehandlung Die Ereignisbehandlung durch Benutzerinteraktionen ndet in der Windows Phone 7 Spirit Applikation ausschlielich in den Code-Behind-Datei der jeweilige Page statt. In den Eventhandlern, also den Behandlungsroutinen fr die verschiedenen Ereignisse, werden die Aufrufe anschlieend an die entsprechenden Controls bergeben. Somit ist der Quellcode, der sich in den Code-Behinds bendet, relative einfach und kurz gehalten.
6.2.3 Pages im Frontend

Die in der Windows Phone 7 Spirit Applikation implementierten Pages, die dem Benutzer verschiedene Funktionalitten zur Verfgung stellen, werden in diesem Kapitel vorgestellt und die verwendeten Designs mit einer kurzen Beschreibung erlutert.
Ronny Schleicher
Seite 48 von 77
Hinweis: Ein detaillierte Anleitung zur Bedienung der Windows Phone 7 Spirit Applikation bendet sich im Anhang unter A.4. Begrungsbildschirm Nach dem Starten der Windows Phone 7 Spirit Applikation wird fr den Zeitraum, die das Windows Phone 7 bentigt um die Applikation zu initialisieren, ein Begrungsbildschirm angezeigt, der das Logo der Fachhochschule Schmalkalden und des Spirit-Projektes beinhaltet. Dieser Begrungsbildschirm besteht aus einem Bild das bestimmten Vorgaben in Hhe und Breite entsprechen muss. Aktuell wird ein Bild mit den Abmessungen 480 mal 800 bentigt, damit das komplette Display ausgefllt werden kann. Hauptseite Die Hauptseite der Windows Phone 7 Spirit Applikation nutzt das PanoramaDesign. Sie beinhalte eine Kurzbersicht der aktuellen News, eine Testimplementierung zu den Stundenplnen und einen Page fr die Einstellungen. Von der Hauptseite aus kann in verschiedenen Sub-Pages navigiert werden. News - Detailansicht Die News-Detailansicht implementiert das Page-Design und stellt detailliert Informationen zu einer News dar. Auerdem werden alle Kommentare angezeigt, die zu der betreenden News gehren und es kann zu der Page navigiert werden, in der Kommentare hinzugefgt werden knnen. Kommentar hinzufgen Diese Page ist ebenfalls im einfachen Page-Design implementiert. Unter Verwendung einer TextBox und der virtuellen Tastatur ist es mglich, Kommentare zu der ausgewhlten News zu schreiben. Stundenplan - Detailansicht Der Stundenplan-Detailansicht ist in der Windows Phone 7 Spirit Applikation nicht voll ausimplementiert, sondern bildet nur den Implementierungsrahmen fr zuknftige Weiterentwicklungen. Hier wird das Page-Design, verwendet auf dem sich ein ScrollViewer mit eine Grid-Layout bendet. So ist es mglich, den Inhalt der Seite in alle Richtungen zu schieben und so mehr Informationen in Page zu bringen als die normale Page mit ihren horizontalen und vertikalen Abmessungen zulsst.
Ronny Schleicher
Seite 49 von 77
6.3 Implementierung des FHSSpirit-DataControl

Das FHSSpirit-DataControl ist das zentrale Element im Backend der Spirit-Applikation und als eigene DLL implementiert. Die Aufgabe der DLL und der in ihr implementierten Klassen ist des Empfangen von Auftrgen ausgelst durch Aufrufe in den Code-Behinds infolge von Benutzer-Interaktionen in den Pages. Der Ansatz dahinter ist, das jede Page durch ein eigenes DataControl verwaltete wird und so unabhngig von den bestehenden Implementierungen Erweiterungen hinzugefgt werden knnen.
6.3.1 Instanziierung DataControlNews

In der aktuellen Implementierung enthlt das FHSSpirit-DataControl die Klasse DataControlNews. Es stellt die Verbindung zum Frontend ber Methoden und Delegaten bereit. Die Implementierung hat sowohl einen imperativen und funktionalen Charakter und ist als Singleton implementiert. Urschlich fr die Implementierung als Singleton ist der zustandslose Charakter der Klasse, der es nicht ntig macht, fr jede Anfrage eine neue Instanz der Klasse zu erzeugen. Listing 6.4 zeigt die Implementierung der Klasse DataControlNews als Singleton. Fr den Zugri auf Instance ist bewusst nur der getter implementiert. Auf einen serialisierten Zugri in der get Methode kann verzichtet werden, da der erste Aufruf der Instanz immer seriell bei Initialisieren der Applikation durch die MainApp erfolgt. Listing 6.4: DataControlNews als Singleton ohne serialisierten Zugri. public c l a s s DataControlNews { private DataControlNews ( ) { }
1 2 3 4 5 6 7 private s t a t i c DataControlNews i n s t a n c e ; 8 9 public s t a t i c DataControlNews I n s t a n c e 10 { 11 get 12 { 13 i f ( i n s t a n c e == n u l l ) 14 { 15 i n s t a n c e = new D a t a C o n t r o l N e w s ( ) ; 16 } 17 return i n s t a n c e ; 18 } 19 // . . . 20 } ;
Ronny Schleicher
Seite 50 von 77
In Codezeile 3 wird der Konstruktor der Klasse DataControlNews, wie fr einen Singleton blich, als private deklariert um eine Instanziierung der Klasse von auerhalb mit dem new-Operator zu verhindern.
6.3.2 Umsetzung der Rest-Schnittstelle

Der Zugri auf die Rest-Schnittstelle, und damit das Abfragen der Daten vom FHS Server, erfolgt durch den Aufruf der jeweiligen Methode requestAllNews(). Wie in Kapitel 4.2.2 beschrieben wird die Klasse HttpWebRequest genutzt um den Zugri zu realisieren. Listing 6.5 zeigt die Implementierung der Methode mit den wichtigsten Elementen: Listing 6.5: Methode requestAllNews() der Klasse DataControlNews. p u b l i c void r e q u e s t A l l N e w s ( ) { try { HttpWebRequest httpWebRequest = ( HttpWebRequest ) HttpWebRequest . C r e a t e ( u r i ) ; httpWebRequest . Method = "GET" ; httpWebRequest . A c c e p t = " application /json" ; httpWebRequest . B e g i n G e t R e s p o n s e ( R e s p o n s e C a l l b a c k , httpWebRequest ) ; } catch ( E x c e p t i o n ex ) { t h i s . m_del_ErrorMessage ( ex . Message ) ; } } Nachdem in Codezeile 5 ein neues Objekt von Typ HttpWebRequest erzeugt wird, wird in Codezeile 6 die Http-Protokolleigenschaft auf GET gesetzt und in Codezeile 7 die Accept Eigenschaft in Http-Header auf application/json gesetzt. Anschlieend wird in Codezeile 8 der Web-Request asynchron gestartet. Ein kleine Besonderheit in Listing 6.5 ist die Fehlerbehandlung, die in Codezeile 12 unter Verwendung eines Delegaten realisiert ist. Das Ergebiss des Web-Request aus Listing 6.5 wird in der Methode private void ResponseCallback(IAsyncResult result) direkt verarbeitet. In Listing 6.6 ist die Implementierung zu sehen.
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Ronny Schleicher
Seite 51 von 77
1 2 3 4 5 6 7 8
Listing 6.6: Methode ResponseCallback() der Klasse FHSDataControlNews. p r i v a t e void R e s p o n s e C a l l b a c k ( I A s y n c R e s u l t r e s u l t ) { try { HttpWebRequest httpWebRequest = ( HttpWebRequest ) r e s u l t . AsyncState ; WebResponse r e s p o n s e = httpWebRequest . EndGetResponse ( result ) ; System . IO . Stream s t r e a m = r e s p o n s e . G e t R e s p o n s e S t r e a m ( ) ; System . IO . S t r e a m R e a d e r s r = new System . IO . S t r e a m R e a d e r ( stream ) ; t h i s . p r o c e s s J S O N S t r i n g ( s r . ReadToEnd ( ) ) ; catch ( E x c e p t i o n ex ) { t h i s . m_del_ErrorMessage ( ex . Message ) ; }
9 10 11 12 13 14 15 16 } 17 }
In Codezeile 5 wird die Referenz auf das Objekt AsyncState, welches Bestandteil der Interface-Denition des Typs IAsyncResult ist, auf einen Benutzerdenierten Referenztyp gecasted. In diesen Fall der Typ HttpWebRequest. Anschlieend wird in Codezeile 6 mit Hilfe der Referenz httpWebRequest und der Methode EndGetResponse ein Referenz auf das WebResponse-Objekt erzeugt, welches die eigentlichen Daten im JSON-Format enthlt. In Codezeile 7 und 8 wird nun mit Hilfe der System.IO.Stream- und System.IO.StreamReader-Klassen der ResponseStream ausgelesen. Die Methode ReadToEnd() die in Codezeile 10 auf den StreamReader angewendet wird, konvertiert den kompletten Eingabe-Stream in einen string, der wiederum als Parameter fr die Methode processJSONString() dient, in der die eigentliche Verarbeitung der JSON-Daten implementiert ist.
6.3.3 Verarbeitung der JSON-Daten mit LINQ

In der Windows Phone 7 Applikation werden die JSON Daten beim Senden und Empfangen auf hnliche Art- und Weise verarbeitet. Nachfolgende werden die Verarbeitungsschritte in den Methoden besprochen, die beim Empfangen von JSONDaten verwendet werden. Zudem wird in den Listings und Beschreibungen eine Beziehung zu den in Abschnitt 6.4 verwendeten Modell hergestellt.
Ronny Schleicher
Seite 52 von 77
6. Systementwurf und Implementierung JSON-Daten
Listing 6.7 enthlt einen String mit JSON-Daten, der lediglich einen Teil der Elemente enthlt, die in den nachfolgenden Abschnitten als Datenbasis fr die Beschreibung der implementierten Methoden dient. Dennoch ist es von Vorteil die grobe Struktur der JSON-Daten darzustellen, um beim Lesen der Listing 6.8 und 6.9 leichter zwischen JObject und JArray unterscheiden zu knnen. Listing 6.7: JSON-Daten mit stark vereinfachtem Inhalt. 1 { 2 "news" : [ { 3 "news_id" : 5 , 4 "title" : "Haus F 2. Stock nicht 5 " c o n t e n t ":"Im Zuge dekann d e r . . . ", 6 " d e g r e e C l a s s ":[{ 7 " c l a s s _ i d ":2 , 8 " t i t l e ":"MAI1", 9 },{ 10 " c l a s s _ i d ":3 , 11 " t i t l e ":"MAI2", 12 }] 13 }],{ 14 ... 15 } 16 } Listing 6.7 zeigt einen String mit einen JSON-Objekt "news", das ein Array von weiteren JSON-Objekten beinhaltet. Das erste JSON-Objekt des Arrays ist in Codezeile 2-13 dargestellt. In diesem JSON-Objekt bendet sich in Codezeile 6 -12 ein weiteres JSON-Array mit der Bezeichnung degreeClass, welches wiederum exemplarisch zwei JSON-Objekte enthlt. Diese Unterstruktur ist besonders fr das Verstndnis von Listing 6.9 und die dazugehrige Beschreibung wichtig. Methode processJSONString() In Listing 6.8 ndet unter Verwendung der Bibliothek von Newtonsoft(Querverweis auf Anhang mit Newtonsofts DLL), wie in Kapitel 4.3.5 beschrieben, die Verarbeitung der JSON mit Hilfe des dort vorhandenen LINQ-Providers LINQ to JSON (siehe Abschnitt 3.4.4) statt. Die in Listing 6.8 verwendeten Klassen JObject und JArray sind ebenfalls Bestandteil dieser Bibliothek. Der Prx J dieser Klassen steht in diesem Kontext im brigen fr JSON und nicht fr die Programmiersprache JAVA3 .
http://www.oracle.com/de/technologies/java/index.html
Ronny Schleicher
Seite 53 von 77
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Listing 6.8: Methode processJSONString() der Klasse DataControlNews. p r i v a t e void p r o c e s s J S O N S t r i n g ( s t r i n g strJSON ) { J O b j e c t j O b j e c t = J O b j e c t . P a r s e ( strJSON ) ; var q u e r y = from r e s u l t A r r a y i n ( J A r r a y ) j O b j e c t [ "news" ] l e t r o = r e s u l t A r r a y as J O b j e c t orderby ( s t r i n g ) r o . S e l e c t T o k e n ( " creationDate " ) descending let f l a t = f l a t D e g r e e C l a s s e s ( ro ) l e t comments = addComments ( r o ) s e l e c t new ItemMessageModel { C o n t e n t = ( s t r i n g ) r o . S e l e c t T o k e n ( "content" ) , Course = f l a t , CreationDateTime = ( string ) ro . SelectToken (" creationDate " ) , E x p i r e D a t e = ( s t r i n g ) r o . S e l e c t T o k e n ( " expireDate " ) , ID = ( i n t ) r o . S e l e c t T o k e n ( "news_id" ) , Owner = ( s t r i n g ) r o [ "owner" ] . S e l e c t T o k e n ( " displayedName " ) , T i t l e = ( s t r i n g ) r o . S e l e c t T o k e n ( "title" ) , CountComments = ( i n t ) ( r o [ " newsComment " ] as J A r r a y ) . Count ( ) , NewsComments = comments };
21 22 23 24 ItemMessageModel [ ] m e s s a g e s = q u e r y . ToArray ( ) ; 25 t h i s . m_del_ResponseNews ( m e s s a g e s ) ; 26 }
In Codezeile 3 wird der ber die Parameterliste bergebene string strJSON, der den eigentlichen JSON-String reprsentiert, der statischen Methode JObject.Parse() bergeben. Hier ndet zunchst eine syntaktische berprfung des JSON-Strings statt. Falls syntaktische Fehler im JSON-String vorhanden sind, der String also nicht valide ist, wird mit einer Ausnahme vom Typ JsonReaderException reagiert. Ein Exception-Handling ndet in der Methode processJSONString() nicht satt, da in der rufenden Methode ResponseCallback() ein allgemeingltiger ExceptionHandler mit Fehlerbehandlung implementiert ist. In Codezeile 4 beginnt das LINQ-Statement dieser Methode, das erst in Codezeile 22 mit dem ; endet. Einzelne Zeilen innerhalb eines LINQ-Statements werden nur durch Zeilenumbrche oder Kommata abgeschlossen und nie mit einem Semikolon.
Ronny Schleicher
Seite 54 von 77
Zunchst wird in Codezeile 4 die Abfragemenge, auf der das LINQ-Statement angewendet wird, festgelegt. In diesem Fall wird deniert, dass die Abfrage auf einem JArray arbeitet, welches in einem JObject mit der Bezeichnung "News" lokalisiert ist. In Codezeile 6 ndet zum ersten Mal die let-Klausel Verwendung. Mit ihr kann man dem Ergebnis eines Ausdrucks einen Namen zuweisen. In diesem Fall wird der Bezeichner ro, stellvertretend fr ResultObject, festgelegt, der ein einzelnes Ergebnis, die in der gesamten Ergebnismenge als JObject deniert. In Codezeile 7 wird die Sortierung festgelegt, in diesem Fall nach "creationDate" absteigend, damit die aktuellsten Nachrichten im Modell immer an erster Stelle angezeigt werden. In Codezeile 8 wird, wieder unter Verwendung der let-Klausel, die Methoden string flatDegreeClasses(Object ro) an den Bezeichner flat gebunden. In Codezeile 9 passiert das gleiche analog mit dem Bezeichner comments und der Methode addComments(). Die Vorgehensweise der Hilfs-Methoden wird exemplarisch in Listing 6.9 erlutert. Das eigentliche select des LINQ-Statements erzeugt in Codezeile 11 mit dem Ausdruck select new ItemMessageModel ein neues Objekt des Typs ItemMessageModel und fllt in den Codezeilen 13 - 21 die Member-Variablen des Objektes. In Codezeile 14 und 21 werden hierfr die Hilfsmethoden unter Verwendung der mit let denierten Bezeichner verwendet. Der Objekttyp ItemMessageModel, der in diesem LINQ-Statement verwendet wird, entspricht dem Objekttyp, der als Modell fr die Datenquelle auf UI-Seite dient. Somit wird das Modell der Datenquelle schon im LINQ-Statement gefllt und kann direkt durch die UI verarbeitet werden. Dies ist mglich, da die Modelle in separaten DLL deniert sind, die an jeder Stelle der Applikation, egal ob Frontend oder Backend, genutzt werden knnen. Somit ist keine Datenkonvertierung oder der Einsatz von Object-Mappern zwischen den einzelnen Anwendungsschichten ntig. Die mit new erzeugten Objekte werden in der Variable query gesammelt und in Codezeile 24 in ein Array vom Typ ItemMessageModel kopiert4 . In Codezeile 25 wird die Ergebnismenge mit einem Delegaten einer Methode bergeben, die fr die Verarbeitung verantwortlich ist und nicht in dieser Klasse bzw. DLL implementiert ist. Methode atDegreeClasses() Die Hilfs-Methode flatDegreeClasses() in Listing 6.9, die im vorherigen Abschnitt schon erwhnt wurde, ist eine statische Methode der Klasse DataControlNews, die als Parameter ein JObject erwartet und, hnlich wie die Methode processJSONString, LINQ darauf anwendet, um eine Teilmenge des vorherigen Anfrageergebnisses zu Verarbeiten.
Genau genommen werden hier nur die Referenzen der Objekte kopiert.
Ronny Schleicher
Seite 55 von 77
1 2 3
4 5 6 7 8 9 10 11 12 13 14 15 16 17 }
Listing 6.9: Hilfs-Methode atDegreeClasses() der Klasse DataControlNews. static private string f l a t D e g r e e C l a s s e s ( JObject jObject ) { var q u e r y = from r e s u l t A r r a y i n ( J A r r a y ) j O b j e c t [ " degreeClass " ] l e t r e s u l t O b j e c t = r e s u l t A r r a y as J O b j e c t s e l e c t new D e g r e e C l a s s { D e g C l a s s = ( s t r i n g ) r e s u l t O b j e c t . S e l e c t T o k e n ( "title" ) }; D e g r e e C l a s s [ ] d e g r e e C l a s s e s = q u e r y . ToArray ( ) ; s t r i n g o u t p u t S t r i n g = "" ; foreach ( D e g r e e C l a s s d i n d e g r e e C l a s s e s ) { o u t p u t S t r i n g += d . D e g C l a s s + " " ; } return o u t p u t S t r i n g ;
In Listing 6.9 wird aus allen in einem JObject enthaltenen "DegreeClass"-Objekten, die sich in einem JArray benden, ein string erstellt, der den Rckgabewert der Methode bildet. Dieser string enthlt kommasepariert alle Titel der degreeClassObjekte. Die Zugrimechanismen und die Verwendung von LINQ in Codezeile 3 - 8 entsprechen dem, was in Listing 6.8 bereits beschrieben wurde. In Codezeile 10 wird die Ergebnismenge in ein Array vom Typ DegreeClass kopiert. Anschlieend wird mit einer foreach-Schleife in Codezeile 12 - 15 auf alle Member DegClass.DegClass zugegrien, die sich im Array DegreeClass[] degreeClasses benden und so der outputString gefllt. LINQ mit let-Klausel und Methoden Ein sehr interessanter Aspekt bei den hier gezeigten LINQ-Statements in Kombination mit der Verwendung der let-Klausel ist die Tatsache, dass in einem LINQStatement Methoden gerufen werden knnen. Die Methoden knnen wiederum auf Teilmengen der Abfrage angewendet werden und ebenfalls wieder LINQ oder die verwendete Programmiersprache zur Verarbeitung der Daten nutzen. Auerdem ergibt sich fr den Entwickler in den Methoden die Mglichkeit, Teilmengen der Abfrage zu debuggen, was bei LINQ-Statements in dieser Form nicht mglich ist. Das ist gerade bei aufwendigen LINQ-Statements eine sehr eektiver Weg zur Fehleranalyse. Zudem ist es ber den Einsatz von Methoden in LINQ-Statement mglich, diese dynamisch, also zu Laufzeit des Programms, zu verndern. Ebenso knnen Erweiterungen, die LINQ zurzeit noch nicht bietet, in diesen Methoden realisiert werden.
Ronny Schleicher
Seite 56 von 77
6.4 Implementierung der Modelle

Bei der Implementierung der Modelle wird die Mglichkeit der gemischtsprachigen Programmierung, siehe Kapitel 3.4.5, genutzt. Die Modelle in der DLL FHSSpirit DataControlFS sind mit der Programmiersprache F# und in Modelle in der DLL FHSSpiritDataControl mit der Programmiersprache C# umgesetzt. Da beide Sprachen Vor- bzw. Nachteile haben, nutzt die Windows Phone 7 Spirit Applikation beide Sprachen, um ein ganzheitliches Bild der Implementierungsmglichkeiten zu schaen. Nachfolgende werden die Modelle ItemNewsModel, fr die Nachrichten, und Item NewsCommentModel, fr die Kommentare, die einer Nachrichten hinzugefgt werden knnen, beschrieben. Die Herangehensweise bei diesen beiden Modellen steht exemplarisch fr die Umsetzungen weiterer neuer Modelle. Die Modelle in den Listings 6.10 und 6.11 besitzen nur einen Teil der im der Windows Phone 7 Spirit Applikation implementierten Properties, um Listings mglichst bersichtlich zu halten.
6.4.1 Modelle in C#
In Listing 6.10 wird das Modell fr die News deniert. Mit der using-Anweisung in Codezeile 1 wird die Ressource System.ComponentModel belegt, die das in Codezeile 6 benutzte Interface enthlt. In Codezeile 2 wird die Ressource fr das Modell der Kommentare belegt, da dieses Modell Bestandteil des ItemNewsModel-Modell ist. Die Klasse ItemNewsModel, die hierbei immer genau eine Nachricht reprsentiert, heit ItemNewsModel und implementiert das Interface INotifyPropertyChanged. Dieses Interface ist die Schnittstelle, die fr die Verwendung von Modellen eine zentrale Rolle einnimmt. Jedes verwendete Modell muss dieses Interface implementieren, um es als Datenquelle fr UI-Element ntzen zu knnen. Wenn ein Modell das INotifyPropertyChanged-Interface implementiert, muss jeder Setter, der fr das Modell relevante Daten manipuliert, immer ein PropertyChangedEvent auslsen, damit UI-Elementen (oder andere Objekte), die diese Modell nutzen, ber die nderungen informiert werden und eine Mglichkeit zur Verarbeitung bekommen. In den Codezeilen 8 - 16 wird dafr ein Event-Handling-Mechanismus implementiert, der dafr sorgt, das durch nderungen von Daten am Modell das Event PropertyChanged korrekt ausgelst wird. Die Implementierung, die hier verwendet wird, stellt die Standartimplementierung des MSDN dar. In Codezeile 17 - 29 ist im Modell der News-Identier, also die laufende Nummerierung aller News, mit dem Property ID implementiert. Neben dem Getter in Codezeile 20 lst der Setter in Codezeile 26 mit dem Aufruf NotifyPropertyChanged(D") das Event PropertyChanged aus und erfllt damit die im vorherigen Abschnitt beschriebenen Anforderungen. Die Kommentare, die im Listing 6.11 als Modell implementiert sind, werden in Codezeile 30 -42 als Array im ItemNewsModel verwendet, da jede News 0-n Kommentare besitzen kann. Die Implementierung entspricht, bis auf den genutzten Datentypen, vom Prinzip der Vorherigen.
Ronny Schleicher
Seite 57 von 77
Listing 6.10: Modell der News in C# 1 using System . ComponentModel ; 2 using F H S S p i r i t D a t a M o d e l s F S ; 3 ... 4 namespace F H S S p i r i t D a t a M o d e l s 5 { 6 p u b l i c c l a s s ItemNewsModel : I N o t i f y P r o p e r t y C h a n g e d 7 { 8 p u b l i c event P r o p e r t y C h a n g e d E v e n t H a n d l e r P r o p e r t y C h a n g e d ; 9 p r i v a t e void N o t i f y P r o p e r t y C h a n g e d ( S t r i n g propertyName ) 10 { 11 PropertyChangedEventHandler ha ndl er = PropertyChanged ; 12 i f ( n u l l != h a n d l e r ) 13 { 14 h a n d l e r ( t h i s , new P r o p e r t y C h a n g e d E v e n t A r g s ( propertyName )); 15 } 16 } 17 p r i v a t e i n t m_nID ; 18 p u b l i c i n t ID 19 { 20 g e t { r e t u r n m_nID ; } 21 set 22 { 23 i f ( v a l u e != m_nID ) 24 { 25 m_nID = v a l u e ; 26 N o t i f y P r o p e r t y C h a n g e d ( "ID" ) ; 27 } 28 } 29 } 30 p r i v a t e ItemNewsCommentModel [ ] m_arrNewsComments ; 31 p u b l i c ItemNewsCommentModel [ ] NewsComments 32 { 33 g e t { r e t u r n m_arrNewsComments ; } 34 set 35 { 36 i f ( v a l u e != m_arrNewsComments ) 37 { 38 m_arrNewsComments = v a l u e ; 39 N o t i f y P r o p e r t y C h a n g e d ( " CountComments " ) ; 40 } 41 } 42 } 43 } 44 }
Ronny Schleicher
Seite 58 von 77
6.4.2 Modelle in F#
Listing 6.11 zeigt das Modell fr die Kommentare, die den News hinzugefgt werden knnen. In Codezeile 1 wird zunchst der zu dieser Klasse gehrenden Namespace festgelegt. Anschlieend wird in Codezeile 3 mit der open-Anweisung die Ressource System.ComponentModel belegt. Die Klassendeklaration beginnt in Codezeile 5. In Codezeile 6 - 7 werden zwei Funktionen deklariert die durch das Schlsselwort mutable als vernderlich gekennzeichnet sind und so als Member verwendet werden knnen. Das Event-Handling und das Verwenden des Interfaces INotifyPropertyChanged ist in Codezeile 9 - 12 implementiert. Auch hier handelt es sich um eine Standartimplementierung der MSDN. In Codezeile 14 - 18 sind die Getter und Setter des Properties ID, welches als Identier fr die einzelnen Kommentare verwendet wird, implementiert. In Codezeile 18 wird auch hier wieder mit dem Aufruf ev.Trigger(x, PropertyChangedEvent Args(ID)) das Event PropertyChanged ausgelst. Codezeile 20 - 24 implementiert analog dazu das Property CreationDateTime, das den Zeitpunkt der Erzeugung des Kommentars beinhaltet. Listing 6.11: Methode requestAllNews() der Klasse DataControlNews. 1 namespace F H S S p i r i t D a t a M o d e l s F S 2 3 open System . ComponentModel 4 5 type ItemNewsCommentModel ( ) = 6 l e t mutable m_nID : i n t = 0 7 l e t mutable m _ s t r C r e a t i o n D a t e T i m e : s t r i n g = "" 8 9 l e t ev = new Event<_ , _>() 10 i n t e r f a c e I N o t i f y P r o p e r t y C h a n g e d with 11 [< CLIEvent >] 12 member x . P r o p e r t y C h a n g e d = ev . P u b l i s h 13 14 member x . ID 15 with g e t ( ) = m_nID 16 and s e t ( i d ) = 17 m_nID < i d 18 ev . T r i g g e r ( x , P r o p e r t y C h a n g e d E v e n t A r g s ( "ID" ) ) 19 20 member x . C r e a t i o n D a t e T i m e 21 with g e t ( ) = m _ s t r C r e a t i o n D a t e T i m e 22 and s e t ( c r e a t i o n D a t e T i m e ) = 23 m _ s t r C r e a t i o n D a t e T i m e < c r e a t i o n D a t e T i m e 24 ev . T r i g g e r ( x , P r o p e r t y C h a n g e d E v e n t A r g s ( " CreationDateTime " ) )
Ronny Schleicher
Seite 59 von 77
6.4.3 Fazit zu gemischtsprachigen Modellen

Wenn man die Listings 6.10 und 6.11 betrachtet fllt auf, das mit F# eine wesentlich kompaktere Implementierung mglich ist als mit C#. Beide Listings sind nach den Empfehlungen der jeweiligen Sprache formatiert und enthalten je zwei Member mit den jeweiligen Gettern und Settern. Somit ist die Funktionalitt der Klassen in etwa gleich, die Anzahl der ntigen Codezeilen bei F# ist allerdings wesentlich geringen. Die Tatsache, dass nicht nur bei den Klassen, die die Modelle verwenden, gemischtsprachig gearbeitet werden kann, sondern bei den Modellen selbst Modelle aus anderen Sprachen gentzt werden knnen, bietet interessant Mglichkeiten der ModellImplementierung. Besonders dann, wenn in den Modelle eine gewissen Grundlogik implementiert werden soll, kann unter Umstnden F# hier seinen Strken bei der sehr kompakten Formulierung zur Berechnung von Daten voll ausspielen.
Ronny Schleicher
Seite 60 von 77
7 Bereitstellung
Dieses Kapitel beschreibt die Mglichkeiten der Bereitstellung von Windows Phone 7 Applikation. Dabei wird unter anderem auf den Zertizierungsprozess des Marketplace eingegangen und es werden Besonderheiten bei der Entwicklung von Windows Phone 7 Applikation in Bezug auf die verwendete Hardware erlutert.
7.1 Bereitstellung im Marketplace

Der Marketplace bietet aktuell die einzige Mglichkeit, Windows Phone 7 Applikation zu vertreiben. Ein Deployment per E-Mail, wie es bei Android mglich ist, oder andere Wege sind nicht Vorgesehen. Der Marketplace bietet aufgrund seiner Zertizierungsverfahren ein hohes Ma an Sicherheit und stellt durch Softwaretest, die die Applikationen im Rahmen der Zertizierung durchlaufen mssen, eine gewisse Qualitt sicher. Nach erfolgreicher Zertizierung wird die Windows Phone 7 Applikation im Marketplace bereitgestellt und kann direkt ber jedes beliebige Windows Phone 7 installiert werden. Im Rahmen der Zertizierung enthlt wie Windows Phone 7 Applikation eine Signatur, die das Ausfhren der Applikation auf nicht Entwicklungsgerte, siehe Abschnitt 7.4, erlaubt.
7.2 Hinweise zur Zertizierung

Die erfolgreiche Zertizierung einer Windows Phone 7 unterliegt gewissen Leitlinien, die unter[Mic11g] ausfhrlich beschrieben sind. Vier der wichtigsten Grundstze, die eine Windows Phone 7 Applikation erfllen muss sind: Zuverlssigkeit der Windows Phone 7 Applikation eziente Nutzung von Systemressourcen keine Beeintrchtigung der Telefonfunktionalitt keine Inhalte die mit Schadsoftware gleichzusetzen sind
Neben diesen Grundstzen gibt es noch eine Reihe anderer Vorgaben, wie die maximale Gre der XPA-Dateien, Beschrnkungen bei verwendetet Bilder und Icons, die Verwendung von Musik und vieles andere mehr. Alle Details sind ebenfalls unter[Mic11g] zusammen mit dem eigentlichen Zertizierungsprozess beschrieben.
Ronny Schleicher
Seite 61 von 77
7. Bereitstellung
7.3 Bereitstellungsformat
Das Bereitstellungsformat fr Windows Phone 7 Applikation im Marketplace ist eine Datei im XPA-Format. Dieses Format entspricht dem Format herkmmlicher ZIP-Dateien und enthlt alle Applikationsrelevanten Dateien. Durch einfaches Umbenennen der Dateiendung von xpa in zip ist es mglich, sich den Inhalte wie bei jeder anderen zip-Datei anzeigen zu lassen.
7.4 Entwicklungsgerte
Das Windows Phone 7 lsst nur die Ausfhrung von Applikationen mit einer speziellen Signatur zu, die die entsprechende XPA-Datei im Rahmen der erfolgreichen Zertizierung erhlt. Das bedeutet im Umkehrschluss, dass eigene Windows Phone 7 Applikationen, die sich gerade in der Entwicklung benden, nicht auf dem Gert ausgefhrt werden knnen. Die einzige Mglichkeit, auf einem Windows Phone 7 unsignierte Applikationen ausfhren zu knnen, ist eine Online-Registrierung des Gertes als Entwicklungsgerte. Hierfr muss das Gerte ber USB und unter Verwendung der Zune-Softeware 1 mit einem PC verbunden werden, auf dem die Windows Phone Developer Tools RTW 2 installiert sind. Anschlieend wird das Programm Windows Phone Developer Registration ausgefhrt. Um die nachfolgenden, in diesem Programm angebotenen, Registrierungsschritte erfolgreich durchlaufen zu knnen, ist ein Benutzerkonto im Developer Portal 3 und eine Windows Live ID 4 ntig. Nach erfolgreicher Registrierung des Windows Phone 7 als Entwicklungsgert ist es nun mglich, XPA-Dateien ohne gltige Signatur auszufhren, auf dem Gert zu debuggen und Entwicklertools auf dem Gert einzusetzen. Eine Registrierung als Entwicklungsgerte hat allerdings erheblichen Einuss auf die Sicherheitskonzepte, die mit den Signaturen verbunden sind. Auch die Mglichkeit, das Entwicklertools auf das Gerte angewendet werden knnen, birgt Risiken. Gerade beim Verlust eines Gertes knnen diese Faktoren erheblichen Einuss auf den Schaden haben, der entsteht. Es ist daher nicht ratsam, ein Gerte zum Entwickeln freizuschalten, das regulr verwendet wird und auf dem sich diesbezglich fr den Besitzer sensible Daten benden.
7.5 Integrierter Trial-Modus

Der Integrierte Trial-Modus des Windows Phone 7 bietet fr Entwickler eine einfache Mglichkeit, die eigene Windows Phone 7 Applikation mit einem Trial-Modus auszustatten, ohne dafr explizit Funktionalitt entwickeln zu mssen. Im Namespace Microsoft.Phone.Marketplace benden sich hierfr alle ntigen Klassen
1 2
http://www.zune.net/de-de/default.htm http://www.microsoft.com/downloads/de-de/details.aspx 3 http://create.msdn.com/en-US/ 4 www.hotmail.com
Ronny Schleicher
Seite 62 von 77
7. Bereitstellung
und Funktionen. Der Trial-Modus kann beim Bereitstellen von Windows Phone 7 Applikation als Option gewhlt werden und wir vom Windows Phone 7 und dem Marketplace voll untersttzt. Listing 7.1: Nutzung des Trail-Modus in einer Methode. 1 using M i c r o s o f t . Phone . M a r k e t p l a c e ; 2 3 p u b l i c p a r t i a l c l a s s MainPage : P h o n e A p p l i c a t i o n P a g e 4 { 5 // . . . 6 p u b l i c void s a v e D a t a ( ) 7 { 8 L i c e n s e I n f o r m a t i o n l i = new L i c e n s e I n f o r m a t i o n ( ) ; 9 10 i f ( l i . I s T r i a l () ) 11 { 12 // B e n a c h r i c h t u n g an den B e n u t z e r m i t H i n w e i s 13 // a u f d i e Nutzung e i n e r T r a i l V e r s i o n 14 return ; 15 } 16 else 17 { 18 // A u s f u e h r u n g d e s Q u e l l c o d e s d e r V o l l v e r s i o n 19 } 20 } 21 } Listing 7.1 implementiert ein Methode saveData(), die nur in der Vollversion ihre komplette Funktionalitt bereitstellen soll. Um festzustellen, ob die Windows Phone 7 Applikation im Trial-Modus ausgefhrt wird, muss lediglich der Namespace Microsoft.Phone.Marketplace eingebunden sein und wie in Codezeile eine Referenz des Typs LicenseInformation instanziiert werden. In Codezeile wird die IsTrial() Methode verwendet, um festzustellen, in welcher Variant die Applikation ausgefhrt wird, und entsprechend reagiert .
7.6 Erwerb der Spirit Applikation im Windows Marketplace

Die Windows Phone 7 Spirit Applikation wird zur Zeit nicht im Marketplace bereitgestellt, da fr die Netzwerkverbindung ber Rest ein eigenes, von der Fachhochschule Schmalkalden bereitgestelltes Zertikat verwendet wird, das in dieser Form nicht in den Installationsprozess der Applikation integriert werden kann. Allerdings ist die Applikation als Open-Source-Projekt im Git-Hub verfgbar, siehe Anhang A.1, und kann dementsprechend verwendet werden.
Ronny Schleicher
Seite 63 von 77
8 Ausblicke
Die Ausblicke sind aufgrund ihren unterschiedlichen Thematik in zwei Kapitel unterteil. Kapitel 8.1 enthlt Ausblicke zur Technologie des Windows Phone 7 und Aktivitten, die sich in diesem Entwicklungsbereich aktuell ergeben. Kapitel 8.2 beschftigt sich mit der Weiterentwicklung der Windows Phone 7 Spirit Applikation und den Funktionalitten des FHS-Spirit Projektes im Allgemeinen.
8.1 Windows Phone 7

Mittlerweile ist fr das Windows Phone 7 die Anzahl der verfgbaren Gerte weiter gestiegen, auch eine neue Version des Betriebssystem mit der Bezeichnung Windows Phone 7 Mango1 ist bereits erschienen. Es bietet im Bereich der Cloud-Services viele neuen Funktionen und interessante Verbesserungen. Die Vereinheitlichung der Benutzeroberchen von Desktop- und mobilen Endgerten wird mit Metro weiter vorangetrieben, wobei bei diesem Thema das Windows Phone 7 die Vorreiterrolle eingenommen hatte. Durch den Rckzug von HPs WebOS2 und der Kooperation vom Microsoft mit Nokia hat die Bedeutung vom Windows Phone 7 weiter zugenommen. Aktuell sind die Gerte, die mit Android oder dem iOS ausgerstete sind, dem Windows Phone 7 in Bezug auf Verkaufszahlen allerdings weit berlegen. Ein groer Vorteil des Windows Phone 7 fr Softwareentwickler sind die wirklich sehr guten Entwicklungsumgebungen, die mit dem Visual Studio 2010 und Expression Blend 4 zur Verfgung stehen. Die nchste Generation des Visual Studios in der Version 2011 ist bereits verfgbar und untersttzt die neuen Funktionen, die das Windows Phone 7 Mango bietet. Die Version 2012 ist auch schon auf der Roadmap zu nden und Expression Blend 5 bendet sich in der Beta-Phase. Hier wird sprbar, dass das Windows Phone 7 wirklich sehr stark forciert wird. Das etwas umstndliche Bereitstellen (siehe Kapitel 7) von Windows Phone 7 Applikation ist dagegen ein etwas strenden Faktor, der eine nicht unerhebliche Hrde fr Entwickler darstellt, die zum ersten Mal mit mobiler Entwicklung Kontakt haben. Letztendlich bleibt abzuwarten, ob die Ziele, die Microsoft mit Windows Phone 7 verfolgt, realisiert werden knnen und mit welchen Neuentwicklungen die Konkurrenzprodukte ausgestattet sind.
1 2
http://msdn.microsoft.com/en-us/hh220612 http://de.wikipedia.org/wiki/HP_webOS
Ronny Schleicher
Seite 64 von 77
8. Ausblicke
8.2 FHS-Spirit Projekt

Nachfolgend sind Ideen und Funktionen gelistet, die im Rahmen der Arbeiten an diesem Spirit-Projekt nicht realisiert wurden. Diese Liste umfasst nicht nur Eintrge, die die Windows Phone 7 Spirit Applikation betreen, sondern auch Funktionen, die eine Erweiterung der Server-Komponenten nach sich ziehen. Im Rahmen der prototypischen Entwicklung der Windows Phone 7 Spirit Applikation und den anderen Komponenten sind, gerade zum Ende hin, ebenfalls noch neue Ideen entstanden, die sich hier wiedernden. Handling der FHS ID und Single Sign On An- und Abmeldung sollten mit der FHS-ID und dem entsprechenden Passwort mglich sein. Die Anmeldedaten sollten den Daten entsprechen, die mittlerweile fast an der gesamten Fachhochschule Schmalkalden Gltigkeit besitzen. Benutzergruppen Einzelnen Funktionen, wie das Hinzufgen von Nachrichten, soll nur speziellen Nutzergruppen erlaubt sein. Hierfr knnte eine eigene Benutzerverwaltung aufgebaut oder die bestehenden Benutzerverwaltung der Fachhochschule Schmalkalden genutzte werden. Einbindung des aktuellen Stundenplans Diese Funktionalitt ist vom Konzept und von Datenmodell serverseitig implementiert, besitzt aber noch keine Anbindung an die Datenbasis der aktuellen Stundenplne. Die Windows Phone 7 Spirit Applikation untersttzt diese Funktionalitt nicht. Bereitstellen eines persnlichen Stundenplans Die Funktion umfasst das Erstellen eines persnlichen Stundenplans mit automatischer Aktualisierung bei nderungen der Veranstaltungen durch Ausfall oder Verschiebung. Ebenso knnen hier Seminare und Tutorien eingetragen werden, die man besuchen mchte. Implementierung eines Modules zur Durchfhrung von Umfragen Ein Modul, das es ermglicht, studentische Umfragen im Rahmen der Fachhochschule Schmalkalden durchzufhren, die fr wissenschaftliche Arbeiten verwendet werden knnen.
Ronny Schleicher
Seite 65 von 77
9 Fazit
Diese Arbeit hat moderne imperative und funktionale Sprachelemente des Windows Phone 7 untersucht und sie zusammen mit einem Anwendungsfall, dem SpiritProjekt, auf ihre Leistungsfhigkeit und Anwendbarkeit hin berprft. Als Ergebnis der Arbeit ist festzustellen, dass es mglich ist, mit dem Windows Phone 7 imperativ und funktional zu entwickeln. Neue Sprachen und Sprachelemente, die im Rahmen der .NET -Entwicklung entstanden sind, sind mit einigen Einschrnkungen, auch mit dem Windows Phone 7 anwendbar. Unter Verwendung prototypischer Implementierungen konnten Fragestellungen, die sich aus dem SpiritProjekt und aus der eingesetzten Technologie ergeben haben, untersucht und gelst werden. Auerdem ist festzustellen, dass der Trend hin zu gemischtsprachiger Programmierung, in Bezug auf das Windows Phone 7, kein Trend mehr ist, sondern Stand der Technik. Die einzelnen Fragestellungen von UI-Design ber die Applikationslogik bis hin zu den Netzwerkschnittstellen werden mit verschiedenen Sprachen, und teilweise auch verschiedenen Entwicklungsumgebungen gelst, die miteinander interagieren. Im Bezug aus das Spirit-Projekt ist festzustellen, dass das Windows Phone 7 aus Entwicklersicht alles bietet, entweder durch die Technologie des .NET Framework 3.5 selbst oder durch Open-Source-Projekte, was fr die Entwicklung anspruchsvoller Applikationen ntig ist. Das Entwicklungskonzept hinter dem Windows Phone 7 ist demzufolge eine sehr attraktive Plattform, die Softwareentwicklern sehr interessante Mglichkeiten bietet, Ideen sowohl mit funktionalen als auch mit imperativen Sprachelementen umzusetzen.
Ronny Schleicher
Seite 66 von 77
Literaturverzeichnis
[Blo10] Bloch, Olivier: http://blogs.msdn.com/b/obloch/. MSDN Blogs, 2010 [Fun] Functions, Curried: http://blog.efvincent.com/parsing-json-using-f [Mic09] Microsoft, MSDN: http://msdn.microsoft.com/de-de/magazine/ dd419663.aspx. MSDN Magazin, 2009 [Mic11a] Microsoft, MSDN: http://create.msdn.com/assetscms/images/quick starts/Navigation_FramePageNav.png. MSDN - App Hub, 2011 [Mic11b] Microsoft, MSDN: http://create.msdn.com/en-US/. MSDN Development for Windows Phone and XBOX 360, 2011 [Mic11c] Microsoft, MSDN: http://msdn.microsoft.com/de-de/fsharp/. MSDN - Microsoft F# Developer Center, 2011 [Mic11d] Microsoft, MSDN: http://msdn.microsoft.com/de-de/library/ bb386964.aspx. MSDN - LINQ to Entities, 2011 [Mic11e] Microsoft, MSDN: http://msdn.microsoft.com/de-de/library/ bb386977.asp. MSDN - LINQ to DataSet, 2011 [Mic11f] Microsoft, MSDN: http://msdn.microsoft.com/de-de/library/we86c 8x2.aspx#multilinelambda. MSDN - Visual Basic - Mehrzeilige LambdaAusdrcke und -Unterroutinen, 2011 [Mic11g] Microsoft, MSDN: http://msdn.microsoft.com/en-us/library/hh184843 (v=VS.92).aspx. MSDN - Application Certication Requirements for Windows Phone, 2011 [Mic11h] Microsoft, Silverlight: http://www.microsoft.com/germany/silverlight/ entwickler.aspx. Microsoft - Silverlight, 2011 [Sys07] Systems, OakLeaf: http://oakleafblog.blogspot.com/2007/03/third-partylinq-providers.html. OakLeaf Systems - Third-Party LINQ Providers, 2007 [Wil11] Wilcox, Je: http://www.je.wilcox.name/2011/03/metro-design-guidev1/. MSDN Blogs, 2011
Ronny Schleicher
67
A Anhang
A.1 Windows Phone 7 Spirit Applikation als Open-Source Projekt
Der komplette Quellcode der Windows Phone 7 Spirit Applikation ist in GitHub1 unter der URL https://github.com/spirit-fhs/wp7 verfgbar. Um den Quellcode zu bersetzen, ist ein Visual Studio 2010 und das aktuelle Windows Phone Developer Tools RTW 2 ntig. Das Projekt im GitHib beinhaltet alle verwendeten Assemblies und DLLs, die zu dem Projekt gehren. Eine Readme.txt-Datei im Projektverzeichnis enthlt die ntigen Informationen.
A.2 Installation
Die Applikation ist nicht im Marketplace verfgbar. Um die Windows Phone 7 Spirit Applikation auf einem Windows Phone 7 zu installieren muss, die Applikation mit dem Visual Studio 2010 bersetzt und auf ein Windows Phone 7 bertragen werden, das unsignierte Applikationen, siehe Kapitel 7.4 ausfhren kann.
A.2.1 Zertikate installieren

Ohne das gltige Zertikat der Fachhochschule Schmalkalden kann mit einem Windows Phone 7 keine Verbindung zum Rest-Service aufgebaut werden. Um das Zertikat zu installieren, muss es per E-Mail an eine E-Mail-Konto geschickt werden, auf dass das Windows Phone 7 zugreifen kann. Per Klick auf den Anhang der E-Mail wird das Zertikat installiert. Erhltlich ist das Zertikat beim Systemadministrator der Fakultt Informatik der Fachhochschule Schmalkalden.
A.3 Automatischen Test

Das Visual Studio 2010 bietet aktuell fr Windows Phone 7-Projekt noch keine Mglichkeit, automatische Tests zu implementieren, so wie es bei andern .NET Projekten blich ist.
1 2
http://de.wikipedia.org/wiki/GitHub http://www.microsoft.com/downloads/de-de/details.aspx?FamilyID=04704acf-a63a-4f97-952c8b51b34b00ce
Ronny Schleicher
68
A. Anhang
Es ist zwar mglich, mit Hilfe von zustzlichen Softwarepaketen anderer Anbieter diese Funktionalitt zu ergnzen, allerdings wurde aufgrund der bersichtlichkeit der Projektstruktur und der noch relative geringen Funktionalitt der prototypischen Implementierung darauf verzichtet.
A.4 Benutzerhandbuch
Nachfolgend wird eine Einfhrung in die Bedienung der Windows Phone 7 Spirit Applikation gegeben, die die implementierten Funktionen, die in dieser Arbeit entwickelt wurden, beschreibt.
A.5 Mainpage
Abbildung A.1: Mainpage der Windows Phone 7 Spirit Applikation. In der linken Abbildung ist die bersicht allen News mit dem Titel, den zugeordneten Gruppen, dem Erstellungsdatum, dem Ersteller und der Anzahl der Kommentare zu sehen. Mit einem Klick auf das blau hinterlegte i, fr Information, wird die Detailansicht zu den Nachrichten genet. Der mittlere Screenshot zeigt die Liste aller zur Verfgung stehenden Stundenplne, die ebenfalls mit Klick aus das blau hinterlegte i in die Detailansicht wechseln. Der rechte Screenshot zeigt die Einstellungen, in denen die Verbindungsdaten festgelegt werden. In der Combo-Box stehen zur Zeit prototypisch die untersttzten Anmeldenamen zur Auswahl.
Ronny Schleicher
69
A. Anhang
A.6 Detailansicht News

In der Detailansicht News, hier links zu sehen, ist die komplette Nachricht mit allen Kommentaren sichtbar. Zustzlich ist es mglich mit einem Klick auf + Kommentare hinzuzufgen oder mit x wieder auf die Hauptseite zurckzukehren.
Abbildung A.2: Detailansicht News in der Windows Phone 7 Spirit Applikation. Das Hinzufgen von Kommentaren ist mithilfe der integrierten Software-Tastatur mglich, wie im rechten Screenshot zu sehen. Mit den beiden Buttons am unteren Rand der Page kann der Kommentar gespeichert oder abgebrochen werden.
Ronny Schleicher
70
A. Anhang
A.7 Detailansicht Stundenplne

Die Detailansicht Stundenplne enthlt in dem gezeigten Prototyp der Windows Phone 7 Spirit Applikation lediglich einen Entwurf der Page, der im Wesentlichen einen Implementierungsvorschlag darstellt.
Abbildung A.3: Detailansicht Stundenplne in der Windows Phone 7 Spirit Applikation.
Ronny Schleicher
71
B Anhang
B.1 Eingesetzte Software
Fr diese Arbeit wurde fr die Implementierung das Visual Studio 2010 und Expression Blend 4 verwendet. Als externe Software kommt wird die Open-SourceBibliothek Json. NET von James Newton-King 1 eingesetzt. Diese Arbeit wurde mit Latex und der Software MiKTeX 2.8 2 erstellt. Die UMLDiagramme wurden mit Enterprise Architect 9.1 3 , GIMP4 und MS-Paint gezeichnet und bearbeitet.
1 2
http://james.newtonking.com/ http://miktex.org/2.8 3 http://www.sparxsystems.de/ 4 http://www.gimp.org
Ronny Schleicher
72
B. Anhang
B.2 JSON-Parser mit F#

Listing B.1: JSON Parser in F# [Fun] 1 type Token = 2 | OpenBracket | C l o s e B r a c k e t 3 | OpenArray | C l o s e A r r a y 4 | Colon | Comma 5 | S t r i n g of s t r i n g | Number of s t r i n g 6 7 let tokenize source = 8 l e t rec p a r s e S t r i n g a c c = f u n c t i o n 9 | \ \ : : " :: t -> parseString (acc + "\"" ) t 10 | " :: t -> acc , t 11 | c :: t -> parseString (acc + (c. ToString ())) t 12 | _ -> failwith " Malformed s t r i n g . " 13 14 let rec token acc = function 15 | () :: _) as t -> acc , t 16 | (: :: _) as t -> acc , t 17 | (, :: _) as t -> acc , t 18 | w :: t when Char. IsWhiteSpace (w) -> acc , t 19 | [] -> acc , [] 20 | c :: t -> token (acc + (c. ToString ())) t 21 22 let rec tokenize acc = function 23 | w :: t when Char. IsWhiteSpace (w) -> tokenize acc t 24 | { :: t -> tokenize ( OpenBracket :: acc) t 25 | } :: t -> tokenize ( CloseBracket :: acc) t 26 | [ :: t -> tokenize ( OpenArray :: acc) t 27 | ] :: t -> tokenize ( CloseArray :: acc) t 28 | : :: t -> tokenize (Colon :: acc) t 29 | , :: t -> tokenize (Comma :: acc) t 30 | " : : t > 31 l e t s , t = p a r s e S t r i n g "" t 32 t o k e n i z e ( Token . S t r i n g ( s ) : : a c c ) t 33 | : : d : : t when Char . I s D i g i t ( d ) > 34 l e t n , t = t o k e n ( "-" + d . T o S t r i n g ( ) ) t 35 t o k e n i z e ( Token . Number ( n ) : : a c c ) t 36 | + : : d : : t | d : : t when Char . I s D i g i t ( d ) > 37 l e t n , t = token (d . ToString () ) t 38 t o k e n i z e ( Token . Number ( n ) : : a c c ) t 39 | [ ] > L i s t . r e v a c c 40 | _ > f a i l w i t h " Tokinzation error" 41 42 tokenize [ ] source
Ronny Schleicher
73
Abbildungsverzeichnis
2.1 3.1 4.1 4.2 5.1 5.2 5.3 6.1 Komponentendiagramm mit den Schnittstellen der Systeme untereinander. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metro-Design auf dem Startbildschirm des Windows Phone 7. . . . . Sequenzdiagramm mit dem Ablauf wendung der Klasse WebClient. . . Sequenzdiagramm mit dem Ablauf wendung der Klasse WebRequest. . der . . der . . Kommunikation unter . . . . . . . . . . . . . Kommunikation unter . . . . . . . . . . . . . 5 7
Ver. . . . 24 Ver. . . . 26
Frame- and Page Model [Mic11a] des Windows Phone 7. . . . . . . . 32 Screenshot Windows Phone 7 Emulator mit dem erzeugten Button. . 38 Screenshot des Windows Phone 7 Emulator mit Messagebox. . . . . . 38 Komponentendiagramm der Windows Phone 7 Spirit Applikation mit den Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
A.1 Mainpage der Windows Phone 7 Spirit Applikation. . . . . . . . . . . 69 A.2 Detailansicht News in der Windows Phone 7 Spirit Applikation. . . . 70 A.3 Detailansicht Stundenplne in der Windows Phone 7 Spirit Applikation. 71
Ronny Schleicher
74
Tabellenverzeichnis
6.1 bersicht ber die Komponenten der Windows Phone 7 Spirit Applikation mit den verwendeten Technologien. . . . . . . . . . . . . . . . 42
Ronny Schleicher
75
Listings
4.1 4.2 4.3 5.1 5.2 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 7.1 Web-Request mit C# und der Klasse System.Net.WebClient . . . . . 23 Web-Request mit C# und der Klasse System.Net.HttpWebRequest . 25 Dispatcher.BeginInvoke unter Verwendung des Lambda Operators . . 27 Datei: Page.xaml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Inhalt des Code-Behind in C#. . . . . . . . . . . . . . . . . . . . . . 37 Ausschnitt aus der Datei: MainViewModelSampleData.xaml . . Festlegung der Delegaten im Konstruktor der Klasse MainPage . Ausschnitt aus einem Markup mit Datenbindung der View. . . . DataControlNews als Singleton ohne serialisierten Zugri. . . . . Methode requestAllNews() der Klasse DataControlNews. . . . . Methode ResponseCallback() der Klasse FHSDataControlNews. JSON-Daten mit stark vereinfachtem Inhalt. . . . . . . . . . . . Methode processJSONString() der Klasse DataControlNews. . . Hilfs-Methode atDegreeClasses() der Klasse DataControlNews. Modell der News in C# . . . . . . . . . . . . . . . . . . . . . . Methode requestAllNews() der Klasse DataControlNews. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 47 48 50 51 52 53 54 56 58 59
Nutzung des Trail-Modus in einer Methode. . . . . . . . . . . . . . . 63
B.1 JSON Parser in F# [Fun] . . . . . . . . . . . . . . . . . . . . . . . . 73
Ronny Schleicher
76
Eidesstattliche Erklrung
Ich versichere an Eides Statt durch meine eigenhndige Unterschrift, dass ich die vorliegende Arbeit selbststndig und ohne fremde Hilfe angefertigt habe. Alle Stellen, die wrtlich oder dem Sinn nach auf Publikationen oder Vortrgen anderer Autoren beruhen, sind als solche kenntlich gemacht. Ich versichere auerdem, dass ich keine andere als die angegebene Literatur verwendet habe. Diese Versicherung bezieht sich auch auf alle in der Arbeit enthaltenen Zeichnungen, Skizzen, bildlichen Darstellungen und dergleichen. Die Arbeit wurde bisher keiner anderen Prfungsbehrde vorgelegt und auch noch nicht verentlicht.
Rodorf, den 24. September 2011

Ort, Datum Ronny Schleicher
Ronny Schleicher
77

Entwicklung Einer Windows Phone 7 Applikation Unter Verwendung Moderner Imperativer Und Funktionaler Sprachelemente

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Entwicklung Einer Windows Phone 7 Applikation Unter Verwendung Moderner Imperativer Und Funktionaler Sprachelemente

Hochgeladen von

Copyright:

Verfügbare Formate

Masterarbeit

Fachhochschule Schmalkalden SS 2011 61 61 61 62 62 62 63

B Anhang 72 B.1 Eingesetzte Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 B.2 JSON-Parser mit F# . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Eidesstattliche Erklrung 77

Fachhochschule Schmalkalden SS 2011

2.1 Entwicklungsgeschichte des FHS-Spirit Teilprojektes

Fachhochschule Schmalkalden SS 2011

Fachhochschule Schmalkalden SS 2011

2.4 Anforderungsbeschreibung der mobilen Applikationen

3.1 Was ist ein Windows Phone 7?

Fachhochschule Schmalkalden SS 2011

3.1.2 Cloud-Computing und Cloud-Services

Fachhochschule Schmalkalden SS 2011

3.1.3 iPhone und Windows Phone 7

Fachhochschule Schmalkalden SS 2011

3.1.4 Android und Windows Phone 7

3.1.5 Windows Phone 7 Kernel

http://www.android.com/ Olivier Bloch: Technical Evangelist Microsoft Corp.

Fachhochschule Schmalkalden SS 2011

Fachhochschule Schmalkalden SS 2011

Fachhochschule Schmalkalden SS 2011

Fachhochschule Schmalkalden SS 2011

3.3 Technologien zum Entwickeln mit Windows Phone 7

Fachhochschule Schmalkalden SS 2011

3.3.3 Eingesetzte Technik fr die Spirit Applikation

3.4 Untersttzte Sprachen und Technologie

Fachhochschule Schmalkalden SS 2011

3.4.2 Visual Basic

Fachhochschule Schmalkalden SS 2011

Fachhochschule Schmalkalden SS 2011

3.4.5 Gemischtsprachige Programmierung

3.4.6 Eingesetzte Sprachen fr die Spirit Applikation

3.5 Verfgbare Entwicklungsumgebungen

3.5.1 Microsoft Visual Studio 2010

http://eclipse.org EFIGS-Sprachen: English, French, Italian, German, Spanish

Fachhochschule Schmalkalden SS 2011

3.5.2 Microsoft Expression Blend 4

Fachhochschule Schmalkalden SS 2011

3.5.3 Alternative Entwicklungsumgebungen

3.5.4 Verwendete Entwicklungsumgebungen fr die Spirit-Applikation

Fachhochschule Schmalkalden SS 2011

4 WP7 Spirit Applikation Backend

4.1 Netzwerkkommunikation - Datenformate und Protokolle

http://www.ics.uci.edu/ elding/pubs/dissertation/top.htm http://it-republik.de/jaxenter/artikel/RESTDer-bessere-Web-Service-2158.html 3 http://de.wikipedia.org/wiki/Representational_State_Transfer 4 http://de.wikipedia.org/wiki/JavaScript_Object_Notation

4. WP7 Spirit Applikation Backend

Fachhochschule Schmalkalden SS 2011

4.1.4 Verwendetes Datenformat in der Spirit Applikation

4.2 Mglichkeiten der Umsetzung der REST-Schnittstelle

4. WP7 Spirit Applikation Backend

Fachhochschule Schmalkalden SS 2011

4. WP7 Spirit Applikation Backend

Fachhochschule Schmalkalden SS 2011

4. WP7 Spirit Applikation Backend

Fachhochschule Schmalkalden SS 2011

4. WP7 Spirit Applikation Backend

Fachhochschule Schmalkalden SS 2011

4. WP7 Spirit Applikation Backend

Fachhochschule Schmalkalden SS 2011

4.2.3 Eingesetzte Technik in der Spirit Applikation

4. WP7 Spirit Applikation Backend

Fachhochschule Schmalkalden SS 2011

4.3 Verarbeitung der JSON Daten

4.3.1 Bibliotheken zur Verarbeitung von JSON

4. WP7 Spirit Applikation Backend