PPC WMS = 2 * Euro

Mobile Entwicklung doppelt gemoppelt
Kommentare

Microsofts Windows Mobile-Smartphone-(WMS-)Plattform ist in der öffentlichen Wahrnehmung kaum präsent. Trotzdem verkaufen sich WMS-Programme laut diversen Analysen wie verrückt. Grund genug für Pocket-PC-(PPC-)Entwickler, den Kisten ein wenig mehr Aufmerksamkeit zu widmen.

Windows Mobile Smartphones, oder neuerdings Windows-Mobile-standardbasierte Geräte, unterscheiden sich von den omnipräsenten Windows Phones durch ein kleines, aber wesentliches Hardwarefeature: Statt eines Touchscreens haben sie zwei weitere Tasten. Die HOME-Taste mit dem kleinen Häuschen aktiviert den Programmstarter, während die BACK-Taste diverse andere Aufgaben erfüllt. Anders als bei Touchscreengeräten sind außerdem die beiden Softkeys immer als Hardware ausgeführt. Ein dedizierter 5way-Navigator ist immer vorhanden. Abbildung 1 zeigt das HTC Snap mit den relevanten Tasten, die im Bild klar ersichtlich sind.

Abb. 1: The four keys of WMS: Left, Right, Home, and Back
Abb. 1: The four keys of WMS: Left, Right, Home, and Back

Diese Veränderung des Bedienparadigmas hat zur Folge, dass touchscreenbasierte Anwendungen nicht oder nur sehr eingeschränkt lauffähig sind, selbst wenn man einen virtuellen Cursor verwendet (beispielsweise der unvergessene Hacker erofich für seine ROM-Upgrades), leidet die Usability stark. Deshalb ist ein neues User Interface das Gebot der Stunde. Dabei kommt uns die geschichtete Architektur von Windows CE zu Gute. Ursprünglich zur Flexibilisierung der Lizenzierung des Betriebssystems vorgesehen (der Hardwarehersteller muss nur für die Komponenten bezahlen, die er auch verwendet), ermöglicht sie die Weiterverwendung von nicht UI-bezogenen Komponenten (Abb. 2).

Die mehrschichtige Komponentenarchitektur - hier ist ihr Zweck offensichtlich
Die mehrschichtige Komponentenarchitektur – hier ist ihr Zweck offensichtlich

Im .NET Compact Framework werden diese „Differenzen“ noch mehr abgeschirmt. Ist die .NET-CF-Version identisch, verhalten sich die Runtimes gleich. Der Unterschied liegt primär in der Komponentenauswahl sowie im Verhalten einiger Steuerelemente.

Teile und Herrsche

An Universitäten wird seit jeher ein großer Wert auf die Aufteilung von GUI- und Engine-Code gelegt. Was meist nur lästigen Ballast darstellt, wird hier sinnvoll: Wieso soll Code, der die GUI-Schicht nicht berührt, nicht sowohl auf WM als auch auf WMS lauffähig sein? Als praktisches Beispiel sei hier der Entwurf einer Dateisuchsoftware für Windows Mobile vorgestellt. Die grundlegende Arbeit wird hier von einer rekursiv arbeitenden Dateisuch-Engine erbracht, die vom User Interface mit Befehlen gefüttert wird. Die Rückgabe der Ergebnisse erfolgt über eine weitere, statische und globale Klasse. Das ist übrigens nur ein Beispiel – es kommt natürlich nicht auf Multithreading etc. an. Die globale Klasse wird von der Engine mit Informationen über die gefundenen Dateien gefüttert. Diese werden nachher von der GUI gelesen und angezeigt. Asynchrone Mitteilungen zwischen GUI und Engine werden durch so genannte Delegaten ausgetauscht. Ein Delegat ist bekanntlich eine Art Funktionspointer, der in .NET implementiert ist. Auch er ist vollkommen unabhängig vom User Interface.

Das Quarantäneställchen

Die klassische Methode zur Aufteilung von GUI- und Engine-Code ist also das Klassenmodul. Leider ist ein Klassenmodul Teil der Projekthierarchie. Und wir benötigen eine etwas andere Struktur, die nicht Teil des GUI-Projekts wird. Aus diesem Grund wählt man ein separates Projekt aus. Dabei kann man ohne Weiteres auf ein Pocket-PC- oder WMS-Projekt zurückgreifen. Wichtig ist nur, dass es keinerlei Formulare enthält. Dort erstellt man dann eine oder mehrere .cs-Dateien mit den relevanten Klassen, die die artifizielle Intelligenz und Programmstruktur enthalten.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -