Mobile Entwicklung doppelt gemoppelt (Teil 2)
Kommentare

Der Futterknecht
Ist diese Engine fertig, ist die halbe Miete bezahlt. Denn nun erstellt man in derselben Projektmappe zwei plattformspezifische Projekte, die das User Interface enthalten. Dabei empfiehlt

Der Futterknecht

Ist diese Engine fertig, ist die halbe Miete bezahlt. Denn nun erstellt man in derselben Projektmappe zwei plattformspezifische Projekte, die das User Interface enthalten. Dabei empfiehlt sich die Verwendung von Geräteanwendungen. Die eine basiert auf der Vorlage für Windows Mobile 5.0 Pocket PC, die andere auf der Vorlage für Windows Mobile 5.0 Smartphone. Wenn Visual Studio diese Option nicht anbietet, fehlt entweder das Windows Mobile Smartphone oder Pocket-PC-SDK. Beide können kostenlos von Microsoft bezogen werden – die einzigen dabei anfallenden Kosten sind jene für den Download von rund 300 MB. In diesen Anwendungen wird sodann das User Interface wie gewohnt erstellt. Die Entwicklung von Benutzerschnittstellen für touchscreenlose Geräte erfordert allerdings einige Kniffe und viel Erfahrung – mehr dazu in einem anderen Artikel.

Verdrahtungen zur Belustigung

Die bis jetzt erbrachte Arbeit mag zwar possierlich sein, bringt jedoch wenig, denn die beiden Module kennen einander noch nicht. Der erste Weg ist deshalb, die beiden miteinander bekannt zu machen. Das geschieht ganz einfach durch einen Rechtsklick auf den Projektheader eines der beiden GUI-Projekte. Dann klickt man auf „Verweis hinzufügen“ und wählt im darauf erscheinenden Dialog die Option Projekte. Danach wählt man das Engine-Projekt aus und klickt auf OK. Dieser Prozess wird später noch für das andere GUI-Projekt wiederholt. Nun „kennen“ die beiden Projekte einander. Das heißt, dass sie aus dem GUI-Projekt auf den Namespace des Engine-Projekts zugreifen können, alle dort befindlichen globalen Klassen stehen ihnen jetzt also zur Verfügung. Im Rahmen der Verdrahtung ist die Verwendung der oben genannten Delegaten (Delegates) ratsam. In der Regel werden Delegaten in der Engine erstellt, z. B. so:

//DELEGATES public delegate void doneSearchingDlg(); public static doneSearchingDlg doneSearching;

Falls sich jetzt jemand wundert, warum der Delegat „zweistufig“ erstellt wird: Keine Ahnung, ich weiß es auch nicht. Es geht jedoch nur so. Die GUI-Klasse muss diesen Delegaten nun „beleben“. Dabei wird zuerst eine Methode mit passender Signatur erstellt. Diese wird dann der Delegatvariablen, wie in Listing 1 zu sehen, zugewiesen.

        public void doneSearching()
        {
            foreach (FileInfo file in FindEngine.foundFiles)
            {
                //XYZ
            }
        }
        private void ResultList_Load(object sender, EventArgs e)
        {
            FindEngine.doneSearching = doneSearching;
            //ABC
    }
  

Die Engine kann über die Delegatvariablen eine oder mehrere Funktionen, die mit der Delegatvariablen verdrahtet ist/sind, aufrufen:

if (initial) {//we are done, so fire the other delegate doneSearching(); }

Damit ist das Produkt „verdrahtet“: Engine und GUI können nun miteinander kommunizieren.

Testen, verpacken und liefern

Hiermit ist die Entwicklungstätigkeit abgeschlossen, und der Test der beiden GUI-Projekte kann, wie von Smart Device Projects gewohnt, beginnen. Will man die Probeläufe auf realer Hardware durchführen, benötigt man einen Pocket PC und ein WMS. Dabei ist eigentlich nur zu beachten, dass ActiveSync immer nur ein Gerät unterstützt – man kann sich also auf kleinere Umsteckorgien gefasst machen. Wenn die Testphase überstanden ist, muss das Programm nur mehr in ein CAB-Archiv verpackt werden. Die Erstellung derartiger Archive wurde bereits in einem Artikel des dot.NET Magazins [1] detailliert beschrieben – hier sei nur mehr darauf hingewiesen, dass zwei CAB-Projekte erforderlich sind. Eines der beiden erstellt das CAB-Archiv für WM, das andere für WMS. Jedes der beiden enthält jeweils die Engine sowie das für die jeweilige Plattform vorgesehene GUI-Projekt. Sofern eine Setup-DLL verwendet wird, muss diese selbstverständlich auch in zwei Versionen vorliegen.

Fazit

Die Entwicklung der Geschäftslogik von Anwendungen für WM und WMS ist schwierig genug. Durch kluges Entwickeln kann man diese allerdings wiederverwenden, wodurch sich sowohl WM- als auch WMS-kompatible Software bauen lässt. Manche Entwickler berichten von einer Umsatzverdoppelung durch „Verbreiterung“ der Plattformen – es rentiert sich also wirklich.

Tam Hanna befasst sich seit der Zeit des Palm IIIc mit Programmierung und Anwendung von Handcomputern. Er entwickelt Programme für diverse Plattformen und betreibt außerdem mehrere populäre Onlinenewsdienste zum Thema.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -