AntMe-Logo
(Quelle: microsoft.com)

Hallo werte Leserschaft,

in den letzten Tagen habt ihr leider vergeblich auf Neuigkeiten vom Ende des Internets gewartet. Ich war 4 Tage lang vom Internet abgeschnitten und das diesmal sogar ganz freiwillig. Warum und wie ich das überlebt habe? Nun ganz einfach. Seit Montag (6.4.) läuft mein letztes Semester an der DHBW Ravensburg, Campus Friedrichshafen. Und diesmal begann das Semester auf besondere Weise: mit einer Lehrveranstaltung im österreichischen Mellau. Diese stand im Zeichen der Ameise.

Zunächst einmal jedoch zum Veranstaltungsort. Die DHBW Ravensburg, Campus Friedrichhafen nutzt eine Hütte in Mellau als Seminarhaus und Veranstaltungsort für mehrtägige Lehrveranstaltungen. Dort hat man durch die Abgeschiedenheit die Möglichkeit unbeeinflusst von äußeren Einflüssen zu arbeiten und das Teamgefühl zu stärken. Das waren optimale Voraussetzungen für unser Vorhaben.

Größere Kartenansicht

Nun, was haben wir gemacht? Der Anlass des Workshops war das TFS-Experiment in Kooperation mit AntMe!. Ziel war es mit unserem Team von 28 Studenten nach den Methoden der agilen Software-Entwicklung mit Scrum die Software eines Server-Prototypen zu entwickeln, auf dem die AntMe!-Spieler künftig ihre Völker gegeneinander antreten lassen können. Entwickelt wurde in C# mit Visual Studio 2008 Team Suite, die Source-Code-Verwaltung und Aufgabenmanagement etc. wurden über den  Team Foundation Server (TFS) gemacht.

Nach der Anreise am Montag Nachmittag wurden einige organisatorische Angelegenheiten erledigt. Darunter auch: Aufteilung der Rollen von Entwicklern, Testern, Projekt-Managern (PM) und Group-Project-Managern (GPM). Wie es das Schicksal und die GPM wollten, wurde ich PM für die Geschäftslogik-Komponente und durfte gleich aktiv über die Zusammensetzung meines Entwickler-/Testerteams entscheiden. Nachdem das Briefing der GPM und PM durch die Vertreter von AntMe! dann gegen 23 Uhr am Montag abgeschlossen und alle Studenten auf die verschiedenen Stellen verteilt waren, konnte man in den gemütlichen Teil des Abends übergehen, um gegen halb 2 im Bett zu landen.

Die Nacht war kurz, denn am nächsten Morgen stand die Einführung in den TFS und die Bestimmung der Work-Items an. Um möglichst früh mit den Entwicklern und Testern starten zu können, fand diese Einführung morgens um 6:30 Uhr statt! Bis zum Frühstück um 9 war soweit alles geklärt und alle dachten noch, dass es nach Plan laufen würde. Doch dann machte die Technik Probleme. Der WLAN-Router verkraftete die Anzahl an Client-Geräten nicht, sodass es immer wieder zu Verbindungszusammenbrüchen kam. Das brachte den Zeitplan etwas ins wanken. Zusätzlich dazu kamen Missverständnisse und Unklarheiten über die Software-Architektur. Die Folge: Erst am Nachmittag konnten die Tester und Entwickler effektiv mit der Arbeit beginnen. Bis dahin war auch ein zweiter WLAN-Router beschafft, sodass man nun auch endlich eine stabile Verbindung hatte. Dank des unermüdlichen Arbeitseinsatzes der Studenten, konnten dann aber zum abendlichen Review gegen 22 Uhr doch erste Erfolge vorgezeigt werden. Auch wenn man nicht an das eigentliche Ziel des Tages herangekommen war, ließen wir den Tag gemütlich mit Musik, Spiel und Spaß ausklingen.

Am Mittwoch starteten die GPM und PM, sowie Tom, Patric und Dominik von AntMe “erst” um 7 Uhr. Es wurde darüber gesprochen, was man nach dieser starken Verzögerung am Vortag noch vom eigentlichen Vorhaben schaffen könne und erneut WorkItems festgelegt. Eine weitere Entscheidung dieses Morgens: Patric hat seine Rolle als Lead-PM an mich übertragen, da die Geschäftslogik einer der wichtigsten Bereiche ist und um mir die Möglichkeit zu geben, hinsichtlich der Kommunikation mit den anderen PM und GPM aktiver zu werden. Das bedeutete natürlich nochmal eine zusätzliche Herausforderung für mich. Wie schon am Vortag arbeiteten unsere Studenten-Entwickler extrem engagiert, sodass am Ende des Tages ein enormer Fortschritt präsentiert werden konnte. Diesmal beendeten wir den Arbeitstag auch schon um 20 Uhr, um den letzten Abend auf der Hütte nochmal gebührend zu feiern. Am Mittwoch wurden wir zudem von Uwe Baumann von Microsoft besucht.

Der Donnerstag war dann der Tag der Feedback-Runden, Reviews und natürlich auch der Abreise. Wir haben in der kurzen Zeit einiges geschafft, aber leider nicht soviel, wie es ohne technische und Kommunikationsprobleme möglich gewesen wäre. Aber der Lernertrag war auf jeden Fall sehr groß. Wir haben neue Erfahrungen bei der Umsetzung von Projekten dieser Größe gewonnen.  Zudem haben wir erstmals mit dem TFS gearbeitet und nach Scrum entwickelt. Besonders für die GPM und PM kamen die Erfahrungen in Bereichen des Projektmanagements dazu. Und ich denke, dass alle ihre Arbeit gut gemacht haben, auch wenn nicht alles perfekt lief. Denn der beste Gewinn war doch die Erkenntnis, wie man etwas besser machen bzw. sich selbst verbessern kann. Und auch die Organisatoren wissen jetzt, dass dieser Workshop ein vorbereitendes Event gebraucht hätte. Dann hätte man schneller einsteigen und einige Probleme wären vll. nicht aufgetreten.

Was bleibt ist dennoch die Erinnerung an 4 coole Tage zusammen mit dem Kurs und den 3 Herrschaften von AntMe. Mir hats jedenfalls Spaß gemacht. Und ungeachtet aller Probleme muss man auch hervorheben, dass es in einem Bereich problemlos lief: Unser Special-Operations-Team Flocki und Thorsten in der Küche hat eine perfekte Arbeit abgeliefert! Sie haben uns 4 Tage lang mit leckerem Essen und frischem Kaffee versorgt. Das war einfach spitze! Auch die Mengenkalkulation war im Vorfeld sehr gut. Vielleicht kann ich ja demnächst nochmal eine kleine Liste nachreichen, von welchen Mengen hier gesprochen wird, um die Leistung nochmals hervorzuheben. Denn 31 Leute zu versorgen, da gehört was dazu.

Was ich auch noch nachreichen möchte: Einige Fotos von diesen 4 Tagen. Zudem haben Tom, Patric und Dominik Interviews und andere Dinge auf Video aufgezeichnet. Sobald ich die Links habe, werd ich mich nochmal melden.

So, nun genieß ich mal das Osterwochenende hier unten am Bodensee. Das Wetter ist traumhaft.

Viele Grüße

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/ 9