es ist nun ca. 13 Monate her, dass ich mir mein HTC Touch Diamond mit Windows Mobile 6.1 zugelegt habe. In diesen 13 Monaten hab ich durchaus Vorzüge festgestellt, gegenüber meinen vorherigen Handys, die keine Smart Phones darstellten. Das betrifft zum Beispiel die bessere Terminkoordination und -darstellung im Wochenüberblick, sowie die detaillierteren Kontaktprofile. Doch ebenso habe ich auch viele störende Eigenschaften an diesem Betriebssystem festgestellt. Auch unabhängig von dem einen Hard-Reset der nach 7 Monaten nötig war, da keinerlei Dateien mehr bearbeitet, umbenannt, kopiert usw. werden konnten.

Die Bedienung von WM 6.1 ist an vielen Stellen einfach nur extrem mühsam, wenn man nicht ständig zum Stylus greifen möchte. Ich erinnere da nur an die Weckzeit-Übersicht oder die Aufgabenverwaltungsliste mit ihren Mini-Checkboxen, die man nur mit sehr viel Übung und einer kleinen Portion Glück zielsicher mit dem Finger trifft. Weitere Problemstellen sind die Kontakteingabe, die man irgendwann freiwillig auf dem Notebook im Outlook macht und dann synchronisiert, sowie die mitunter langsame Reaktion des Systems. Letzteres kann natürlich auch zu einem gewissen Anteil am Branding des Netzanbieters liegen.

Aus diesem Grund war natürlich die Hoffnung da, dass mit dem Nachfolger, Windows Mobile 6.5, alles besser würde. Zumal dieses System neben neuen IE-Mobile-Technologien als “optimiert für Touchscreenbedienung” beworben war und dafür eine fingerfreundlichere Oberfläche versprach. Einige Screenshots zeigten eben dieses neue Bedienkonzept, was durchaus Grund zur Hoffnung gab.

Heute-Ansicht bei WM 6.5

Nun sind die ersten Modelle mit Windows Mobile 6.5 verfügbar und schon zeigen Testberichte, dass die beworbene Optimierung nur oberflächlich durchgeführt wurde. So zum Beispiel bei der neuen Heute-Ansicht (siehe Bild). Kaum geht man etwas tiefer in die Menüpunkte hinein, landet man wieder im gewohnten WM 6.1-Layout mit Bedienelementen, die ohne Stylus nur schwer zu bedienen sind. Somit kommt auch dieser Testbericht von Spiegel Online zu dem Schluss, dass sich das Warten auf das neuste mobile Betriebssystem aus Redmond nicht gelohnt hat und man nur hoffen kann, dass mit der Version 7.0, sofern sie denn 2010 kommt, nun wirklich der Anschluss an die Branchenkonkurrenz geschafft wird.

Ich jedenfalls muss mich im September 2010 entscheiden, ob ich mir wieder ein neues Gerät zulege. Ich kann nur hoffen, dass sich bis dahin in Redmond einiges tut, ansonsten könnt ich mich doch in Zukunft eher mal bei den Konkurrenzsystemen umschauen…

Soviel von meiner Seite,

euer Maddin

Nein, ich habe keineswegs die Absicht den Werbeslogan eines gewissen Online-

Windows Mobile Logo

Auktionshauses zu kopieren. Der Titel hat rein praktische Bedeutung und bezieht sich auf meine neueste Spielerei mit dem Windows Mobile 6 Professional SDK.

Es handelt sich dabei um einen kleinen Timer. Bevor jetzt einige vor Erstaunen gleich vom Bürostuhl fallen, möchte ich doch kurz die Hintergründe erläutern.

Mein HTC Touch Diamond besitzt alle möglichen Spielereien und Tools, die das mobile Leben leichter machen sollen. Jedoch ein simpler Timer, z.B. um mich zu erinnern, wann der Tee fertig gezogen ist oder ein Teig genügend geruht hat, den gibt es nicht. Natürlich brauch man nur die entsprechenden Schlagworte bei Google eintippen und findet entsprechende Timer kostenlos zum Download. Aber zum Einen dachte ich mir: “Hey, so schwer kann das net sein!” und zum Anderen stellte es genau die richtige Schwierigkeitsstufe für einen weiteren Schritt beim Erkunden der Windows Mobile Programmierung dar. Ein dritter Grund ist der, dass der einfache Timer nur die Grundlage für ein recht nützliches Tool sein soll, das schonmal alle wichtigen Schlüsseltechniken besitzt.

So, was hab ich nun getan? Zunächst einmal galt es eine einfache und übersichtliche GUI zu erstellen. Mit Microsoft Visual Studio 2008 war auch gar kein Problem. Die grundlegenden Eventhandlings für die einzelnen Menüpunkte stellte auch keine große Schwierigkeit dar. Der Timer bietet die Möglichkeit eine Zeit einzustellen, auszuwählen, ob man nach deren Ablauf per Vibration oder Klingeln erinnert werden möchte, sowie eine Resetfunktion.

Doch betrachten wir mal die Kernfunktion. Die eingestellte Zeit soll sekundenweise herunterzählen, bis man bei 00:00:00 angelangt ist. Demnach benötigt man ein Ereignis, das im Intervall von einer Sekunde auftritt. Das .NET-Framework bietet dazu die Klasse System.Windows.Forms.Timer, deren Instanzen mit einer Intervalllänge konfiguriert werden können. Sobald eine Timer-Instanz in den Zustand “Enabled” gesetzt wurde, wird immer im konfigurierten Intervall ein entsprechendes Event gefeuert. Den Eventhandler, der dieses Ereignis behandeln soll, kann man bei der Konfiguration angeben.

Zeiteinstellung beim Timer

Damit ist schonmal das erste Grundproblem gelöst, denn nun kann man den eingegebenen Wert in eine Menge von Sekunden umrechnen und diesen im Eventhandler der Timer-Instanz dekrementieren. Wenn er den Wert 0 erreicht, soll dann eine Vibration oder ein Sound ausgelöst werden. Doch da ergibt sich das nächste Problem: Wie?

Das Thema Sound hatte sich relativ schnell erübrigt, da es passende Beispiele im Internet gibt. Ich habe eine separate Sound-Klasse nach diesem Beispiel erstellt. Diese greift direkt über DLL-Import auf die CoreDLL zu. Nach außen (zu meinem SimpleTimer) bietet sie eine einfache Schnittstelle, der man den Dateinamen übergeben kann. Schwieriger war die Handhabung der Vibration. Hierbei kam ich nach einem Studium entsprechender Blogeinträge zu dem Schluss, dass ich mich eines zusätzlichen SDKs bedienen sollte.

Das OpenNETCF SDK bietet für derartige Bedürfnisse eine weitere umfangreiche Klassenbibliothek. Die entsprechende Bibliothek muss in Visual Studio verständlicherweise in die References hinzugefügt werden, damit die entsprechenden dll-Dateien beim Release mit in den Ordner gepackt werden. Allerdings hatte ich nun das Problem, dass ich verschiedene Beispiele fand. Zum Einen benutzte man die Vibrate-Klasse unter OpenNETCF.WindowsMobile. Dies probierte ich auch zunächst aus. Der Erfolg blieb aus. Ein anderes Beispiel nutze eine virtuelle Notification-LED. In Klassen ausgedrückt heißt das: OpenNETCF.WindowsCE.Notification.Led

Mit einer Instanz dieser Klasse konnte ich über vier simple Zeilen meine Vibration auslösen und stoppen.

OpenNETCF.WindowsCE.Notification.Led vibra = new OpenNETCF.WindowsCE.Notification.Led();
vibra.SetLedStatus(1, OpenNETCF.WindowsCE.Notification.Led.LedState.Blink);
System.Threading.Thread.Sleep(1000);
vibra.SetLedStatus(1, OpenNETCF.WindowsCE.Notification.Led.LedState.Off);

Hierbei sei angemerkt, dass die 1 die ID der LED darstellt. Gegebenenfalls muss man etwas probieren, bis man die richtige LED ermittelt hat.

Menüstruktur des Timers

Mit diesem  scheinbar fertigen Timer machte ich nun einen Praxistest. Ich habe Nudeln gekocht und die angegebene Kochzeit eingestellt. Als mein Handy noch ca. 5 verbleibende Minuten (von ursprünglich 10) anzeigte, war meine Pasta aber schon Al-Dente. Das machte mich etwas stutzig. Eingehende Tests (natürlich nach dem Essen) brachten die Erkenntnis: sobald sich das Handydisplay ausschaltet, wechselt das Handy in eine Art Ruhezustand, die Berechnung des Timers stoppt.

Am Abend des selben Tages habe ich mich nun eingehend mit den System Power States unter Windows Mobile 6 Professional beschäftigt. Dank der MSDN Library fand ich auch die passenden Informationen. Der Übeltäter nannte sich “Suspended State”. Ein Systemzustand, in dem keine Threads laufen. Dank der übersichtlichen Zustandstabelle fand ich dann auch den Zustand, den ich brauchte: “Unattended State”. Dieser ist für Threads die Berechnungen durchführen, die keine direkte Userinteraktion erfordern. Ähnlich der Sound-Klasse hab ich mir eine PowerManager Klasse geschrieben, die mir die nötige Schnittstelle in die CoreDLL bietet. Dies funktionierte auch ganz gut, wenn nicht dann trotzdem irgendwann das Handy im Suspended State gelandet wäre. Ich schaute nun nochmal in die “State Transition”-Tabelle. Der SystemIdle Timeout war schuld, dass mein Timer dennoch stoppte. Doch eine Zeile darunter war die Lösung auf dem Silbertablett: Mittels SystemIdleTimerReset kann man diesen Timeout verhindern.

Somit habe ich in meinen PowerManager eine weitere Funktion eingefügt, die diesen Reset ausführt. Diese Funktion wird von meinem EventHandler der Timer-Instanz alle 30 Sekunden aufgerufen. Nun läuft der Timer problemlos auf 0 herunter. Das Display schaltet sich dabei aber auch nicht mehr vollständig ab, sondern reduziert nur das Backlight auf ein Minimum.

Nun gibt’s hier im Blog eine Software-Sektion ähnlich dieser einfüge, wo ihr euch dann auch direkt den Timer als Quellcode herunterladen könnt. Oben am rechten Rand findet ihr den Link “Software“.

Windows Mobile Logo

Ich bin seit Mitte September im Besitz eines T-Mobile MDA Compact IV (HTC Touch Diamond), welches bekanntlich Windows Mobile 6.1 als Betriebssystem verwendet. Damit bietet das Smart Phone (bitte nehmt es mir nicht übel, aber ich sag trotzdem Handy) natürlich viel mehr Möglichkeiten, um eigene Programme für das Handy zu schreiben, als es ein normales Handy bot. Dort musste man auf JavaME zurückgreifen. Windows Mobile 6 bietet dagegen ein eigenes auf .NET basierendes SDK und vereinfacht so die Software Entwicklung.

Zudem fand ich Berichte, dass bereits findige Entwickler, die aus der HTCSensorSDK.dll die entsprechende API über Reverse Engineering verfügbar gemacht haben. Der Gedanke, mit diesen Möglichkeiten mal zumindest etwas herumzuspielen, sodass vielleicht auch später brauchbare Dinge dabei herauskommen, war schnell geboren. Allerdings hinderte dann diverse zeitliche und technische Probleme mich daran, diesen Gedanken umzusetzen.

Gestern habe ich nun endlich mit der Umsetzung begonnen und das Windows Mobile 6 Professional SDK installiert. Als Entwicklungsumgebung nutze ich Microsoft Visual Studio 2008 und schreibe meine Programme in C#. Das SDK bringt eine umfangreiche Dokumentation und Beispielprogramme mit, um jedem einen guten Einstieg zu ermöglichen. Grundkenntnisse der Programmierung in C# sind natürlich empfehlenswert. Ein für das Debugging der geschriebenen Software unerlässliches Feature ist der Windows Mobile 6 Device Emulator.

Windows Mobile 6 Emulator

Auf dieser Emulation des tatsächlichen Smartphones kann man die geschriebene Software deployen und ausführen. In Verbindung mit Visual Studio 2008 ist auch das gewohnte Step-by-Step Debugging möglich, sodass sich Fehler einfach identifizieren lassen sollten. Zudem verhindert der Emulator, dass man eine fehlerhafte Software auf seinem Handy ausführt und so gegebenfalls Daten vernichtet oder andere Schäden am System verursacht werden.Für meinen ersten Versuch ein lauffähiges Programm zu schreiben, habe ich mich erstmal vom oben genannten SensorSDK ferngehalten. Erstmal sollen ja die Basics stehen.

Jeder, der schon einmal ein Lehrbuch zum Erlernen einer neuen Programmiersprache in der Hand gehabt hat, weiß, wie das erste Programm in aller Regel ausschaut: “Hello World!”. Da für mich die Sprache C# an sich nicht neu ist, sondern nur die Umgebung, auf der die Software läuft, war ich so frei, diesen Standardsatz in “Hello mobile World!” zu modifizieren. Ich wollte es aber auch nicht bei einer banalen Ausgabe belassen, sondern ein ganz klein wenig Funktion sollte schon da sein. Deshalb wird bei Start des Programms neben der Weltbegrüßung noch “Application started at <date/time>” ausgegeben. Am unteren Bildschirmrand erscheinen 2 Menüeinträge: “Change Color”, “Quit”. Während ich sicher niemandem erzählen muss, welchen Zweck der Quit-Button erfüllt, ist auch der andere Button selbsterklärend. Bei Betätigung wird die unten dargestellte Farbänderung vorgenommen und anstatt “Application started…” wird “Colors changed at <date/time>” ausgegeben.

Hello World Application

Das sind Screenshots vom Emulator, als mein Hello World Programm lief. Aber ich habe es auch schon auf meinem Handy getestet und auch da funktioniert es. Ein erster Erfolg, wenn gleich das Programm nix besonderes ist.

Ich hoffe mal, dass ich baldigst mit weiteren Berichten dazu aufwarten kann, dann hoffentlich auch mit funktional umfangreicheren Programmen.

Zusammenfassend lässt sich jedoch sagen, dass das SDK sich gut handhaben lässt und C# natürlich auch eine sehr bequeme Sprache für die Entwicklung ist.

Maddin

]]> http://endedesinter.net/2009/i-say-hello-mobile-world-53/feed/ 23