Windows Phone neu aufgelegt (Teil 3)
Kommentare

Das Metro-Prinzip
Die Hubs sowie der Startbildschirm zeigen bereits, dass Windows Phone 7 alles anderes ist, als eine neue Version von Windows Mobile. Es ist schöner, animiert und wirkt lebendig. Vorbei

Das Metro-Prinzip

Die Hubs sowie der Startbildschirm zeigen bereits, dass Windows Phone 7 alles anderes ist, als eine neue Version von Windows Mobile. Es ist schöner, animiert und wirkt lebendig. Vorbei die Zeiten der grauen oder weißen Windows Forms.

Man war lange der Meinung, dass „Metro“ der Codename der neuen Oberfläche von Windows Phone 7 sei. Das ist jedoch falsch. Metro ist eine Philosophie, die beim Design angewendet wurde. Die Idee hinter Metro ist nicht neu, jedoch wurde sie als ein solches Konzept (endlich) zusammengefasst. So steht hinter Metro folgendes Prinzip: Es gilt nicht, wie man Funktionen bündelt und in einer Anwendung zur Verfügung stellt, sondern viel mehr, wie der Benutzer eine Anwendung als Erlebnis erwarten würde.

Hinter dem Satz verbirgt sich weit mehr, als nur eine Philosophie zum UI-Design. Es geht um „Natürlichkeit“. Schauen Sie sich einen Benutzer heute an, wenn dieser ein mobiles Gerät verwendet. Er erwartet, dass er mit dem Finger auf einer Oberfläche natürlich agieren kann. Navigation über Hardwaretasten ist (in bestimmten Bereichen) unnatürlich. Auch erwartet ein Benutzer heute eher, Fotos zu vergrößern, indem er auf dem Bildschirm zwei Finger gleichzeitig auseinander zieht oder es im umgekehrten Weg verkleinert. Dabei muss das live passieren. Ein Stottern der Animationen ist undenkbar. Gleiches gilt für das Vergrößern der Ansicht von Webseiten.

Es wird auch (in den meisten Fällen) erwartet, dass, wenn ein Benutzer sein Gerät dreht, sich der Bildschirminhalt mitdreht. Darüber hinaus gibt es viele weitere Beispiele, die das Prinzip beschreiben. Es bleibt jedoch eine Essenz dessen übrig: Es geht nicht darum, wie ich Technologie einsetzen kann, um Daten dem Benutzer zu präsentieren. Es ist genau das Gegenteil: Was erwartet der Benutzer von einer Anwendung? Was ist für ihn natürlich? Wie kann Technologie hier helfen? So ist es auch kein Wunder, dass Animationen in Hubs Verwendung finden. Ein Hin- und Herschalten von zwei Dialogen ist nicht (mehr) natürlich. Animationen dagegen nehmen den Benutzer mit, führen ihn von einem Dialog zum nächsten.

Warum ist beispielsweise eine Listbox animiert, wenn der Benutzer mit dem Finger weitere Einträge sehen möchte? Auch das ist natürlich – im realen Leben sehen wir das auch. Wenn ein Rad angeschoben wird oder ein Ständer mit Postkarten bewegt wird, so ist auch dort „eine Animation“ zu sehen.

Angenommen, es soll eine Anwendung erstellt werden, die Töne von sich geben soll. Dafür gibt es zwei Ansätze: Entweder es wird eine Anwendung erstellt, die Buttons mit dem jeweiligen Ton darstellt, oder es wird ein Musikinstrument dargestellt, das Töne von sich gibt, wenn der Benutzer eine Saite berührt. Der erste Ansatz ist für einen Benutzer befremdlich. Er muss erst lernen, wie die Anwendung funktioniert. Der zweite Ansatz ist quasi selbsterklärend, da der Benutzer höchstwahrscheinlich aus dem realen Leben weiß, wie Musikinstrumente zu nutzen sind. Eine Tagebuchanwendung mit Textboxen und Schaltflächen wäre ebenfalls weniger geeignet. Eine Anwendung, die einem Buch nachgeahmt ist, macht mehr Sinn. Allerdings ist auch Konsistenz wichtig. Wenn alle Anwendungen einen schwarzen Hintergrund mit weißer Schrift in einem bestimmten Font verwenden, sollte das auch für die entwickelte App gelten. Ausnahmen gibt es aber auch hier, wie mit dem eben beschriebenen Tagebuch.

Mehr zum Metro-Prinzip erfahren Sie auf dem Windows Blog. Schauen Sie sich auch den letzten Teil der Keynote des zweiten Tags der MIX an.

Warum wurde jedoch an dieser Stelle auf das Metro-Prinzip eingegangen? Im Folgenden geht es um die Hard- und Software von Windows Phone 7. Da man die Entwicklung diesem Prinzip unterworfen hat, mag der eine oder andere Beobachter vielleicht so manche Funktion missen oder bestimmte Entscheidungen nicht ganz nachvollziehen. Behält man das Metro-Prinzip im Hinterkopf, so ist an vielen Stellen jedoch einfacher verständlich, warum es so ist, wie es ist.

Unter der Haube

Alle Windows-Phone-7-Geräte sollten mindestens über eine DirectX-9-fähige GPU verfügen. Erstmals wurden Hardwareherstellern derartige Vorgaben gemacht. Ziel ist auch hier wieder der Benutzer: Ganz gleich, welches Gerät er verwendet, es soll sich gleich „anfühlen“, was Geschwindigkeit und Animationen angeht. Durch eine derartige GPU, die es in früheren Geräten unter Windows Mobile eher selten gab, ergeben sich ganz neue Möglichkeiten. So sind grafische Berechnungen nicht mehr auf die CPU angewiesen, sondern können auf für derlei optimierte Anforderungen spezialisierte GPUs ausgelagert werden. Somit wundert es auch nicht, dass Windows Phone 7 auf ganz andere Technologien setzt als Windows Mobile: Silverlight und XNA. Somit werden auch hier alte Zöpfe abgeschnitten: Anwendungen, die für Windows Mobile erstellt wurden sind u. a. aus diesem Grund unter Windows Phone 7 nicht lauffähig, da Windows Forms nicht mehr unterstützt werden.

Auch haben es native Entwickler nicht einfacher: Silverlight und XNA lassen sich nur verwaltet entwickeln. Silverlight in C# und VB.NET (CTP nur C#); XNA nur in C#. Eine Unterstützung von C++ ist aktuell nicht vorgesehen. Der Grund hierfür ist nicht, dass man native Entwickler außen vor lassen möchte – es geht eher darum, dass verwalteter Code sich wesentlich einfacher aus Sicht des Betriebssystems kontrollieren lässt.

Etwas klarer wird das Ganze, wenn man sich Anwendungen für Windows Phone 7 genauer anschaut. So läuft jede Anwendung in einer Art Sandbox. Jede Anwendung besitzt ihr eigenes Isolated Storage, der als Speicherplatz dient. Ein Zugriff auf das generelle Dateisystem und die Betriebssystemfunktionen ist per se nicht erlaubt. Der einzige Weg, Anwendungen auf das Gerät zu bekommen, ist Marketplace. Durch einen Verifizierungsvorgang seitens Microsoft ist sichergestellt, dass sowohl Anwendungen auf das Gerät kommen, die signiert sind, als auch Anwendungen, die den Ansprüchen des Benutzers genügen und das Gerät nicht überlasten. Einzige Ausnahme: unsignierte sind Anwendungen auszuführen, wenn es sich um Entwicklergeräte handelt. Hier kann ein Entwickler seine Geräte-ID bei Microsoft einreichen, das dann Over-The-Air von dieser Beschränkung befreit wird.

Beim auf Windows Phone 7 eingesetzten Silverlight handelt es sich um ein „Super-Set“ vom bekannten Silverlight 3. Somit steht fast der ganze Funktionsumfang von Silverlight 3 zu Verfügung. Dabei wurden insbesondere beim Thema „Performance“ einige Anpassungen vorgenommen, die Sie bei MSDN nachlesen können. Darüber hinaus gibt es einige weitere Funktionen, die man in Silverlight 3 selbst nicht findet.

Erlaubt ist beispielsweise, die Sandbox durch zusätzliche Funktionen und Klassen kontrolliert zu verlassen. Durch so genannte Chooser ist es beispielsweise möglich, dem Benutzer einen Dialog zu bieten, in dem er einen Kontakt oder ein Foto aussucht, was in der eigenen Anwendung weiter verwendet werden kann. Auch gibt es die Möglichkeit, den Benutzer aus der Anwendung heraus z. B. ein Foto machen oder eine SMS versenden zu lassen. Bei diesen zusätzlichen Funktionalitäten ist jedoch stets gewährleistet, dass diese vom Benutzer gesteuert werden. Dieser ist hierfür verantwortlich – ein Kontrollieren des Dialogs durch eigenen Code ist nicht möglich, da hierdurch ein Ausbrechen aus der Sandbox unter Umständen möglich wäre.

Auch ist es möglich, auf im Gerät vorhandene Hardware und Sensoren kontrolliert zu zugreifen. So lässt sich beispielweise der Lagesensor nutzen. Auch lässt sich abfragen, ob beispielsweise ein Netzwerk zur Verfügung steht und welche Geschwindigkeiten angeboten werden. Eine vollständige Übersicht über die Zusatzklassen gibt es beim MSDN.

Die gleichen Zusatzklassen sind ebenfalls für unter XNA entwickelte Spiele und Anwendungen verfügbar. Umgekehrt besitzt das XNA Framework einige weitere Klassen, die u. a. einen Zugriff auf Xbox Live (das Onlinesystem der Xbox) ermöglichen. Welche Änderungen es für XNA 4.0 hinsichtlich Windows Phone 7 Unterstützung gibt, ist u. a. auf dem MSDN-Blog von Shawn Hargreaves zu sehen.

Es sollte nun langsam deutlich werden, warum es nötig ist, Anwendungen in einer Sandbox laufen zu lassen. Sicherheit ist nur ein Aspekt. Weitaus wichtiger ist, dass auch hier der Benutzer im Vordergrund steht. Würde beispielsweise ein volles Multitasking unterstützt, so würde bei mehreren laufenden Silverlight-Anwendungen die Performance der einzelnen Anwendung leiden. Das heißt jedoch nicht, dass jede Anwendung automatisch durch das Starten einer anderen Anwendung beendet wird.

Vielmehr wird eine Anwendung geparkt. Je nachdem, wie viel Speicher diese verwendet, darf sie weiter im Speicher verweilen. Ist nicht mehr genug Speicher verfügbar, so wird die geparkte Anwendung beendet, um zusätzlichen Speicher zu erhalten. Damit das auch für die Anwendung selbst nicht unkontrolliert passiert, werden diese über den jeweiligen Zustandswechsel informiert. So ist beispielsweise ein Speichern aktueller Dateien möglich, sodass bei einem späteren Aufruf die Anwendung an der Stelle fortgesetzt werden kann, an welcher diese beendet wurde.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -