Entwickeln Sie Anwendungen für Nicht-PC-Systeme

Veröffentlicht: 18. Mrz 2003 | Aktualisiert: 11. Nov 2004

Von Alexander Wechsler

Der PC ist längst nicht mehr die einzige Anlaufstelle in der Gunst der Anwender, wenn es darum geht, geschäftliche und persönliche Daten, Email, Musik, Bilder etc. zu nutzen und zu verwalten. Eine Vielzahl neuer Geräte ist entstanden, die abgestimmt auf die jeweilige Verwendung als Pocket PC, Handy, SmartPhone oder Controller in der Industriellen Automation ihre Stärken gegenüber Desktop Systemen ausspielen. Mit Visual Studio .NET 2003 integriert Microsoft zum ersten Mal Technologien in seine Entwicklungsumgebung, die es dem Softwareentwickler ermöglichen auch für diese Endgeräte mit einem einheitlichen technischen Ansatz Anwendungen zu erstellen.

Auf dieser Seite

 Anforderungen mobiler/embedded Geräte
 Embedded Geräte mit Microsoft Betriebssystemen
 Integration von Geräten in Visual Studio .NET 2003
 Visual Studio .NET 2003 und mobile Webanwendungen
 Ein Beispiel für mobile Webanwendungen
 Test mit verschiedenen Geräten
 Zusammenfassung

Anforderungen mobiler/embedded Geräte

Embedded Geräte stellen aufgrund ihrer Bauform und den zur Verfügung stehenden Ressourcen Anforderungen an die für sie entwickelten Anwendungen, wie sie vom Desktop oder Server kaum bekannt sind.

Die Tatsache, dass in den aktuellen Consumer-Rechnern großer Handelsketten mehr Speicher und Prozessorleistung stecken als noch vor wenigen Jahren in Servern für Rechenzentren, hat dazu geführt, dass sich heute Entwickler kaum mehr Gedanken um den Speicherbedarf und Prozessorleistung machen müssen.
Auf embedded Geräten ist dies jedoch anders. Es steht kaum Speicher zur Verfügung, die Darstellungsmöglichkeiten sind aufgrund der Displaygröße und des Formfaktors eingeschränkt und mit dem Energiehaushalt muss besonders bei mobilen Geräten sehr schonend umgegangen werden. Um Strom zu sparen sind aus diesem Grund embedded Prozessoren wie der XScale in der Lage ihre Taktrate dem benötigten Leistungsbedarf dynamisch anzupassen.

Ein weiterer Aspekt ist, dass embedded Geräte nicht als geschlossenes System betrachtet werden können. Sie sind zumeist ein Teil der Gesamtlösung und haben es oft mit widrigen Umgebungsbedingungen im mobilen Einsatz (keine stabilen Netzwerkverbindungen) oder der industriellen Automation (Schmutz, physikalische Einwirkungen, Störfelder, Vibrationen, etc.) zu tun. Dieses Umfeld verlangt auch von den auf den Geräten laufenden Anwendungen ein höheres Maß an Robustheit, Fehlertoleranz und vorrausschauender Programmierung. Da embedded Geräte in diesen Einsatzbereichen oft auch die Steuerung von gefahrbehafteten Prozessen übernehmen, müssen garantierte Reaktionszeiten und entsprechende Sicherheitsmechanismen mit dem gebotenen Stellenwert in die Architektur des Gesamtsystems eingehen.

Für den Entwickler treten dabei Probleme mit dem Management von volatilen Zustandsdaten ebenso auf, wie die Anforderung Datenbestände zu replizieren und diese durch Lösen der auftretenden Replikationskonflikte konsistent zu halten. Besonders im mobilen Umfeld muss den dort vorhandenen Bandbreiten (GSM, etc.) Rechnung getragen werden: Daten müssen komprimiert und so versendet werden, dass abgebrochene Übertragungen an der Stelle des Abbruchs wieder aufgenommen werden können.

Da oft kein Keyboard und keine Maus als Eingebegeräte zur Verfügung stehen, sollten embedded Anwendungen für die dem Gerät eigenen Eingabemedien optimiert sein. Dies gilt für Touchscreens, Scrollräder, Funktionstasten und Wippschalter, die dem Benutzer je nach Anwendungsfall besonders einfache und komfortable Bedienmöglichkeiten zur Verfügung stellen müssen. Häufig sind in der industriellen Automation auch am Gerät selbst gar keine Eingabemöglichkeiten vorhanden und die gesamte Konfiguration und Wartung muss mit Hilfe anderer Technologien wie z.B. Terminal Services, Web-Interface oder Telnet durchgeführt werden. Bevor man sich in die Applikationsentwicklung auf embedded Geräten stürzt lohnt es sich die verschiedenen von Microsoft angebotenen Systeme zu vergleichen.

 

Embedded Geräte mit Microsoft Betriebssystemen

Microsoft hat für die embedded Welt zwei Arten von Betriebssystemen anzubieten. Das erste ist XP embedded, eine modulare, aber binärkompatible Variante des Desktopbetriebssystems XP Professional, welche noch um einige spezielle Features für den Embedded Markt ergänzt wurde. XP embedded kann von jedem Gerätehersteller mittels eines Bau- und Werkzeugkastensystems, dem Windows Embedded Studio, für seine Zwecke angepasst werden.

Mit Windows CE, hat Microsoft ein Echtzeitbetriebssystem, welches auf möglichst geringen Ressourcenbedarf optimiert wurde. Mit Hilfe der Entwicklungsumgebung Platform-Builder wird dieses Betriebssystem eng und im Source Code auf die darunter liegende Hardware abgestimmt.

Die Unterschiede zwischen beiden Systemen sind sehr deutlich:

Windows XP:

• Modulares Desktop Betriebssystem - binärkompatibel mit XP Professional

• Nur für Intel X86 32 Bit Plattformen verfügbar

• Relativ hoher Ressourcenbedarf

• Feste Stromversorgung meistens erforderlich

• Große Bandbreite an Anwendungen und Treibern verfügbar (Win32 API)

• Bootbar von CD und Compact Flash

• Keine Produktaktivierung notwendig

• Volle Unterstützung für die .NET Entwicklungs-Infrastruktur

• Integration in bestehende IT-Infrastruktur (Active Directory, etc.)

• Target Designer kombiniert fertige Binaries zu einem Image

Windows CE:

• Breite Prozessorunterstützung (StrongArm, Xscale, Hitachi SHx, Mips,X86)

• Optimierter Ressourcen Bedarf (Speicher, Prozessor)

• Ideal für Batteriebetrieb

• Erfüllt harte Echtzeitanforderungen

• Bootbar von Disk und Compact Flash

• Sehr hardwarenahe Entwicklung

• Viel Source Code (>60%) verfügbar

• Unterstützt ausgewählte Bereiche der .NET Entwicklungs-Infrastruktur

• Platform-Builder kompiliert Code in ein binäres Image (nk.bin)

Ja, wird sich mancher denken und dann gibt es da noch den Pocket PC und das SmartPhone OS. Doch Halt! Dies ist leider ein weit verbreiteter Irrglaube, denn die Basis dieser beiden Geräte-Plattformen ist Windows CE. Microsoft hat sich der Bausteinen aus dem Windows CE Baukasten bedient, um diese Geräteklassen zusammen mit einigen Hardware-Herstellern zu definieren und umzusetzen. Natürlich wurde in beiden Fällen zu einem gewissen Teil auch spezifischer Code entwickelt, vor allem für die jeweilige Shell und geräteabhängigen Anwendungen z.B. um mit dem SmartPhone auch telefonieren zu können.

 

Integration von Geräten in Visual Studio .NET 2003

Windows XP embedded
Bei Geräten die mit Windows XP embedded (XPe) arbeiten, hat man es als Anwendungsentwickler einfach. Natürlich ist XPe kompatibel zu Visual Studio.NET und dem .NET Framework 1.1. Man muss nur darauf achten, dass im vom Hersteller oder Ihnen selbst zusammengestellten Betriebssystem-Image die notwendige .NET-Infrastruktur enthalten ist. Dies geschieht durch Hinzufügen des .NET Frameworks und/oder ASP.NET im Target Designer.

Bild 1 .NET Komponenten im XPe Target Designer

Beide Pakete sind im Komponentenbaum des Target Designers unter Software|System Services|Other zu finden und vergrößern das Betriebssystem unkomprimiert um ca. 35 MB beim Framework und 1,5 MB bei ASP.NET.

Zudem ist es natürlich auch möglich das Framework auf bereits im Einsatz befindliche Maschinen per Softwareverteilung oder Setup-Programm zu installieren.
Trotz der weitgehenden Übereinstimmungen mit XP Professional sollten Anwendungen, die für XP embedded geschrieben werden, intensiv auf dem für den Einsatz vorgesehenen Betriebssystem Image getestet werden. XPe Images sind immer ein für den Anwendungszweck des Gerätes optimiertes Subset der XP Professional Funktionalität. Diese können von Fall zu Fall sehr unterschiedlich sein und das Testen auf dem Zielsystem vermeidet böse Überraschungen.

Windows CE
Für auf Windows CE basierte Geräte hat Microsoft eine Teilmenge des .NET Frameworks zur Verfügung gestellt, die Smart Device Extensions, auch bekannt unter dem Namen .NET Compact Framework. Obwohl die Verwendung des kleineren Bruders in der Vorgehensweise der Programmierung für den Entwickler weitgehend identisch mit dem Desktop Framework ist, wurden diese Klassen jedoch vollkommen neu unter embedded Gesichtspunkten erstellt.

Das .NET Compact Framework wird ähnlich dem .NET Framework entweder vom Gerätehersteller mittels Platform-Builder in das CE.NET Image aufgenommen oder mittels Setup-Programm installiert. Beim Programmieren mit Visual Studio sorgt die IDE automatisch dafür, dass eventuell fehlende Dateien mit auf das Gerät / in den Emulator geladen werden. Das .NET Compact Framework und die Common Language Runtime für CE.NET vergrößern den Betriebssystem Footprint um ca. 1,5 MB.

VS.NET 2003 bietet Software Development Kits (SDKs) für zwei Windows CE Plattformen: den Pocket PC und einen generischen Windows CE Standard SDK, welcher die gängigsten im CE Baukasten zur Verfügung stehenden Funktionalitäten bereitstellt. Zugriff auf beide SDKs erhält man durch Anlegen eines neuen Projektes für eine "SmartDeviceApplication".

Bild 2 Anlegen eines Projektes für Windows CE Plattformen

Im nächsten Schritt öffnet sich der Smart Device Application Assistent und bietet dem Benutzer die auf dem Entwicklungs-PC installierten Plattform SDKs für Windows CE an. Wie schon erwähnt sind normalerweise der Pocket PC und der CE Standard SDK vorhanden. Der Anwender wählt nun noch zusätzlich den Anwendungstyp aus den er erstellen möchte (Windows Application, Class Library,…). Auf der rechten Seite des Assistenten Fenster werden zusätzlich die aus VS.NET verfügbaren Geräte und Emulator Typen angezeigt welche zum Testen der Anwendung genutzt werden können.

Bild 3 Smart Device Application Wizard

Was kann man tun wenn man für ein Gerät entwickeln möchte, für das sich hier kein SDK wieder findet? Nun, zu allererst kann man mit dem Standard SDK beginnen, jedoch die Ungewissheit, ob die Anwendung letztendlich auch auf der Zielplattform läuft, macht dies zu keiner befriedigenden Lösung.

Der beste Weg ist, sich an den Hersteller zu wenden und ihn zu bitten einen CE .NET SDK für sein Gerät zur Verfügung zu stellen. Zu beachten ist dabei, dass zwei Arten von SDKs erhältlich sind, einer für embedded Visual C++ 4.0 und einer für Visual Studio .NET 2003 bzw. das .NET Compact Framework.

Als Geräte-Hersteller ist man in der glücklichen Lage, sich einen solchen SDK selbst erstellen zu können. Hierzu öffnet man im Platform-Builder das Projekt der Windows CE Zielplattform und startetet den SDK Export-Assistenten unter Platform|Configure SDK. Zur Auswahl stehen dann Namen und Ort der Erstellung sowie die Art des SDK's (eVC++ 4.0 oder .NET CF). Am Ende des Assistenten hat man die Möglichkeit die Gesamtkonfiguration zu überprüfen.

Bild 4 Auswahl der Sprachunterstützung im SDK

Das wirklich Innovative an der Exportfunktion von Windows CE.NET 4.1 ist die Option auch ein Image des eigenen Betriebssystems für den Emulator zu exportieren, was die Anwendungsentwicklung erheblich erleichtert. Damit haben Entwickler die Möglichkeit bereits für das embedded Gerät Software zu schreiben, selbst wenn dieses noch nicht als Prototyp verfügbar ist. Das langwierige Downloaden und Debuggen der erstellten Programme über die serielle Schnittstelle oder Ethernet kann durch den Emulator abgelöst bzw. beschleunigt werden.

Die durch den Einsatz des Emulators mögliche Parallelisierung von Hard- und Softwareentwicklung verkürzt Projektzeiten enorm. Der Emulator simuliert eine x86 Hardware-Referenzplattform und kann daher nur in gewissen Grenzen für andere Prozessortypen eingesetzt werden.

Vor allem was die Performance und das Echtzeitverhalten anbelangt, kommt man um einen Test mit der wirklichen Hardware nicht umhin, wenn man realistische Ergebnisse erreichen möchte.

Bild 5 SDK Exportdaten für den Emulator

Der Anwendungsentwickler installiert sich nach dem Export des SDKs das resultierenden .msi File auf seiner Entwicklungsmaschine. Er findet danach im Smart Device Application Assistenten von Visual Studio .NET 2003 die exportierte, eigene Plattform zur Auswahl vor und kann bei den Gerätetypen auf das eigene Gerät bzw. den zugehörigen Emulator zurückgreifen.

Hat man seine Plattform gewählt, ist alles bereit, um mit der Entwicklung der Anwendung zu beginnen. Da bereits seit den ersten Beta-Versionen viel über das .NET Compact Framework und verwandte Technologien wie den SQL Server für Windows CE geschrieben wurde, möchte ich an dieser Stelle auf einige interessante Artikel [1],[2] und [3] zu diesen Themen verwiesen.

 

Visual Studio .NET 2003 und mobile Webanwendungen

In den vorangegangen Abschnitten haben wir die Integration der auf Microsoft Betriebssystemen basierenden embedded Geräte in Visual Studio .NET 2003 kennen gelernt. Ist man als Entwickler nun auf die Plattformen beschränkt?

Nein, Visual Studio .NET 2003 bietet eine weitere Technologie an, mit der viele mobile und embedded Geräte in zukünftige oder bereits bestehende Lösungen eingebunden werden können: die ASP.NET Mobile WebApplication.

Für die Erstellung einer mobilen Webanwendung stellt Visual Studio .NET 2003 einen eigenen Projekttyp zur Verfügung. Wählt man diesen aus, so wird auf dem gewünschten Webserver ein entsprechendes Entwicklungsprojekt angelegt.
Mobile Webanwendungen lösen das Darstellungsproblem, welches sich für Internetanwendungen auf mobilen/embedded Geräten ergibt. Aufgrund der verschiedenen Displayformen und auch Darstellungsmöglichkeiten sind Webentwickler nur schwer in der Lage, für jedes Gerät den Inhalt einer Internetseite passend zu präsentieren. Dies ist zudem ein sehr aufwendiger Vorgang, welcher viel Zeit und Geld kostet. Bisherige Techniken verwenden entweder eigene Seiten für jeden Gerätetyp oder aufwendige XML/XSLT Transformation um Inhalte und Layout zu optimieren.
Auf der Geräteseite findet man alle gängigen Internet-Darstellungs-Formate vom kompletten DHTML, scriptfähigen Browser über HTML 3.2 (statisch), cHTML (i-mode) und dem im Handy Sektor verbreiteten WML (WAP).

Um dem Anwender die Möglichkeit zu geben, seine Inhalte nur einmal zu erstellen und trotzdem zielgerichtet das richtige Format an das Endgerät zu senden, verwenden mobile Webanwendungen so genannte Gerätefilter. Diese Gerätefilter sorgen für die Anpassung der Dateninhalte an die vorliegenden Geräteeigenschaften. Der Vorteil gegenüber XSLT-Transformationen liegt darin, dass diese Filter fast alle Inhalte generisch konvertieren, während XSLT Style Sheets zumindest für jede Anwendung, wenn nicht sogar Seite neu erstellt werden müssen. Da die gesamte Erkennung und Konvertierung serverseitig erfolgt, wird das mobile Endgerät mit diesen Aufgaben nicht weiter belastet. Es ist zudem keine Installation oder Wartung von Software auf dem Gerät notwendig da für die Anzeige nur auf die standardmäßig vorhandene Infrastruktur zugegriffen wird.

 

Ein Beispiel für mobile Webanwendungen

Am Besten lässt sich die Verwendung von mobilen Webapplikationen an einem kleinen Beispiel erklären. Vorraussetzungen sind dabei Visual Studio .NET 2003 auf Windows XP oder Windows 2000. Der Internet Information Server (IIS) darf natürlich für eine Webanwendung auch nicht fehlen.

Bild 6 Anlegen einer mobilen Webapplikation

Das Programmieren einer mobilen Webanwendung ist vom Prinzip her nichts anderes als die Erstellung einer normalen ASP.NET Webanwendung in C#. Jedoch sind in einigen Bereichen Besonderheiten zu beachten.

Wir legen ein Projekt auf unserem IIS an und nennen es MobileWebApplication_MSDN. Visual Studio kümmert sich nun um den Aufbau der Projektstruktur und öffnet die erste ASP.NET Seite. Auf ihr befindet sich schon ein Mobile Form Control.
An dieser Stelle zeigt sich schon der erste Unterschied zu ASP.NET. In einer mobilen Webanwendung ist eine .aspx-Seite nicht notwendigerweise mit einem Formular gleichzusetzen. Im Gegenteil, es können sich mehrere mobile Form Controls als Container für weitere Kontrollelemente auf einer Seite befinden.
Schaltet man aus der Design- in die HTML-Ansicht um, so sind zwei Dinge schnell zu erkennen. Zum Einen nutzen mobile Kontrollelemente nicht "asp:" sondern "mobile:" als Präfix für das Steuerelement.

<body Xmlns:mobile="<A href="https://schemas.microsoft.com/Mobile/WebForm">https://schemas.microsoft.com/Mobile/WebForm</A>"> 
 <mobile:Form id=Form1 runat="server"></mobile:Form> 
</body>

Zum anderen wird dieser Präfix mittels einer Register-Anweisung in ASP.NET als Erweiterung registriert. Dabei nutzt Microsoft den in ASP.NET vorhandenen Standardweg, das Framework mit Custom-Controls zu erweitern zu eigenen Zwecken.

<%@ Register TagPrefix="mobile"  
 Namespace="System.Web.UI.MobileControls" Assembly="System.Web.Mobile" %>

Zusätzlich werden in einer mobilen Webapplikation den in ASP.NET üblichen Namensräumen noch System.Web.Mobile und System.Web.UI.MobileControls zur Seite gestellt. Sie schaffen die Referenzen auf die notwendigen Objektklassen.
Ein bisschen unterschiedlich ist auch die web.config. In ihr sind für die Anwendung zur Verfügung stehenden Device Filter sowie zusätzliche Konfigurationseinstellungen hinterlegt.

 <mobileControls cookielessDataDictionaryType="System.Web.Mobile.CookielessData" /> 
 <deviceFilters> 
 <filter name="isJPhone" compare="Type" argument="J-Phone" /> 
 <filter name="isHTML32" compare="PreferredRenderingType" argument="html32" /> 
 <filter name="isWML11" compare="PreferredRenderingType" argument="wml11" /> 
 <filter name="isCHTML10" compare="PreferredRenderingType" argument="chtml10" /> 
 <filter name="isGoAmerica" compare="Browser" argument="Go.Web" /> 
 <filter name="isMME" compare="Browser" argument="Microsoft Mobile Explorer" /> 
 <filter name="isMyPalm" compare="Browser" argument="MyPalm" /> 
 <filter name="isPocketIE" compare="Browser" argument="Pocket IE" /> 
 <filter name="isUP3x" compare="Type" argument="Phone.com 3.x Browser" /> 
 <filter name="isUP4x" compare="Type" argument="Phone.com 4.x Browser" /> 
 <filter name="isEricssonR380" compare="Type" argument="Ericsson R380" /> 
 <filter name="isNokia7110" compare="Type" argument="Nokia 7110" /> 
 <filter name="prefersGIF" compare="PreferredImageMIME" argument="image/gif" /> 
 <filter name="prefersWBMP" compare="PreferredImageMIME" argument="image/vnd.wap.wbmp" /> 
 <filter name="supportsColor" compare="IsColor" argument="true" /> 
 <filter name="supportsCookies" compare="Cookies" argument="true" /> 
 <filter name="supportsJavaScript" compare="Javascript" argument="true" /> 
 <filter name="supportsVoiceCalls" compare="CanInitiateVoiceCall" argument="true" /> 
 </deviceFilters>

Kommen neue Device Filter von Microsoft oder 3rd Party Herstellern auf den Markt oder hat man selbst einen für ein bestimmtes Gerät erstellt, so können diese hier der Anwendung zur Verfügung gestellt werden.

Codebeispiel Doch nun zu unserem Beispiel. Es installiert sich am Besten indem man den Zip-File (Download von www.msdnonline.de/download/MobileWebApplication_MSDN.zip) im Inetpub|wwwroot Verzeichnis des IIS entpackt. Es wird dabei das Verzeichnis MobileWebApplication_MSDN angelegt. Danach muss man noch ein korrespondierendes virtuelles Verzeichnis im IIS einrichten (z.B. über Sharing and Security im Kontextmenü des Verzeichnisses). Danach ist das Projekt über die URL http://[Servername]/MobileWebApplication_MSDN zu öffnen.

Die fiktive Firma Wetter Jetzt! bietet einen ortsbezogenen Service an. Mit Hilfe eines mobilen Gerätes (WML, cHTML) oder einem Webbrowser (HTML, DHTML) kann man über die Webanwendung der Firma sich das im Moment passende Wetter auswählen. Unrealistisch? Nun ja, manchmal hilft der Glaube und uns geht es nur um die Beschreibung der Funktionalität unserer Applikation.

Bild 7 Wetter Jetzt! Homepage

Die Anwendung besteht aus 5 Formularen, die alle auf einer einzigen .aspx-Seite Platz finden. Auf der Homepage hat der Benutzer die Möglichkeit den gewünschten Wetter-Grundtyp auszuwählen (Sonne, Regen oder Schnee).

Bild 8 Wetterdetails auswählen

Je nach Auswahl des Grundtyps ist er dann in der Lage, die Stärke dieses Wettertyps festzulegen und sich eine passende Temperatur auszusuchen. Die Daten werden dann in Variablen des Session-Objektes von ASP.NET zwischengespeichert.

#region EventHandler für die Wetterauswahl 
private void cmd_SoSend_Click(object sender, System.EventArgs e) 
{ 
 //Speichern des gewünschten Wetters 
 Session["Wetter"] = this.list_Sonnenstaerke.Selection.Value.ToString() + "-Sonne"; 
 Session["Temperatur"] = this.txt_Temp.Text; 
 //Ergebnisformular einblenden 
 this.ActiveForm=Ergebnis; 
} 
…

Da alle Controls und Elemente auf einer .aspx-Seite liegen; kann über das this-Keyword und Intellisense in VS .NET 2003 bequem und Formular-übergreifend auf alle Objekte zugegriffen werden. Das Ergebnisformular liest die Werte aus den Session-Variablen wieder aus und präsentiert sie dem User in einem List Control.

Bild 9 Wetter Jetzt! – Ergebnisseite

Die einzelnen Zeilen werden bei Ausgabe der Collection des List Controls hinzugefügt.

//Ausgabe des Ergebnisses 
private void Ergebnis_Activate(object sender, System.EventArgs e) 
 { 
 //Liste initialisieren 
 TList_Result.Items.Clear(); 
 //Datenausgabe 
 TList_Result.Items.Add((string)Session["Wetter"]); 
 TList_Result.Items.Add("Bei einer Temperatur von:"); 
 TList_Result.Items.Add((string)Session["Temperatur"]+ " Grad Celsius"); 
 }

Besonders auffallend am Beispiel für mobile Webanwendungen ist der sehr moderate Einsatz von gestalterischen Elementen oder gar das Fehlen von Grafiken. Das liegt nicht an den beschränkten Design-Fähigkeiten von Anwendungsentwicklern. Gerade Grafiken werden, wenn es geht, vermieden, um die Bandbreiten in den mobilen Netzen zu schonen.

Auch in der Benutzerführung muss man sich als Designer mobiler Anwendungen gegenüber normalen Internetanwendungen etwas umstellen. Die Navigation steht anfangs für die Anwendung zentral im Vordergrund und erst am Ende der Navigationskette werden Inhalte präsentiert.

Dies ist ein großer Unterschied zu den mit visuellen Elementen überladenen Homepages für normale Browser, es ist aber für die Bedienbarkeit der Anwendung auf einem WAP-Handy mit sehr kleinem Bildschirm ein Muss.

Aus diesem Grund werden auch die im Formular vorhandenen Controls nicht nebeneinander zu einem komplexen Layout angeordnet, sondern seriell in Reihe aneinandergefügt. Damit sind sie auch für das einfachste mobile Gerät mit hoher Wahrscheinlichkeit darzustellen. Mobile Form Kontrollelemente sind auch nicht wie ihre Pendants bei den Web Forms in der Größe zu verändern, sie passen sich automatisch der Anzahl der eingefügten Steuerelemente an.

Mit diesen Einschränkungen wird schnell erkennbar, dass für mobile Anwendungen derzeit noch die Funktion und weniger die Präsentation im Vordergrund steht.
Zunächst ist es auch verwunderlich, dass nicht sofort alle Formulare bei Aufruf der Seite im Internet Explorer angezeigt werden, wie man es bei einer normalen Webseite erwartet hätte. Hier greifen die Mechanismen der mobilen Webanwendung im ASP.NET Framework und nur das erste Formular wird angezeigt. Um auf die anderen Formulare zu gelangen, benutzt man ein Link Control und setzt dessen NavigateURL-Eigenschaft auf den Wert "#[Formularname]" oder man setzt via Code die ActiveForm Eigenschaft des MobilePage Objektes auf den gewünschten Formularnamen. Für mobile Formulare steht kein Load-Event, wie man es von z.B. Windows Forms her kennt, zur Verfügung. Sie benutzen z.B. das Activate-Event um Initialisierungen beim Laden durchzuführen.

 

Test mit verschiedenen Geräten

Im nächsten Schritt muss man seine Applikation natürlich auf einigen mobilen Geräten testen, um die gewünschte Funktionalität zu gewährleisten. Man sollte deshalb aber nicht gleich in einen Laden gehen und diese Geräte erstehen. Im Internet steht eine Vielzahl verschiedener Geräte-Emulatoren zum Download zur Verfügung, mit denen ein Test ohne Probleme möglich ist. Einige Links befinden sich hierzu auch in der Liste am Ende des Artikels.

Wie man selbst im Falle dieser sehr einfachen Beispielanwendung auf einem WAP Handy feststellen muss, ist die Bedienung doch erheblich umständlicher als im gewohnten Browser. WML teilt selbst einfache Funktionen wie die Auswahl aus einer Radio-Button Liste in mehrere Schritte auf und die Handhabung der zwei Bedienknöpfe muss einem erst geläufig werden.

Bild 10 Die "Wetter Jetzt!" Anwendung auf einem WAP Handy

Wie man sieht hat der für unser Testgerät passende Device Filter die mobile Webanwendung ohne Zutun des Entwicklers in pures WML konvertiert und der auf dem Handy befindliche WAP Browser hat keine Mühe, die Anwendung und Ihre Funktionen abzubilden.

Lediglich das notwendige Scrollen im Display und die kompliziertere Bedienung machen den Umgang für verwöhnte Browser Nutzer etwas gewöhnungsbedürftig.

 

Zusammenfassung

Visual Studio .NET 2003 bietet eine breite Palette an .NET-Technologien an, um für embedded Geräte Anwendungen zu entwickeln. Für .NET Entwickler am einfachsten umzusetzen, sind hierbei sicherlich Applikationen für Geräte mit XP embedded, für die mit dem Desktop Framework entwickelt werden kann. Für diese muss jedoch die notwendige .NET Infrastruktur mit in das Betriebssystem-Image aufgenommen werden. Für kleinere Geräte, deren Eigenschaften noch spezialisierter auf einen bestimmten Anwendungszweck ausgerichtet sind, empfiehlt sich die Verwendung der Kombination aus Windows CE und den Smart Device Extensions. Letztere bieten eine auf die Ressourcenverhältnisse in diesen Geräten abgestimmte Teilmenge des .NET Frameworks sowie eine sehr gute Integration durch Software Development Kits in die Visual Studio .NET 2003 Entwicklungsumgebung. Mit Hilfe der CE.NET Emulationstechnologie können Anwendungsentwickler Hardwareunabhängig und schnell ihre Anwendungen erstellen.

Steht die maximale Geräte-Reichweite einer Applikation über viele Formfaktoren und Hersteller mobiler Geräte im Vordergrund, so sollte man sich die Technologie der ASP.NET mobilen Webanwendungen näher betrachten. Obwohl man für die mit den Mobile Controls erstellten Seiten keine Webdesign-Preise gewinnen wird, bieten sie einen sehr effizienter Ansatz auch mobile Geräte zuverlässig in Gesamtlösungen einzubinden.

Links
Artikel zum .NET Compact Framework
[1] Erste Schritte mit dem .NET Compact Framework (Electronic Embedded Systeme -Alexander Wechsler)
[2] .NET CF und SQL Server für Windows CE (MSDN - USA - Alexander Wechsler)
[3] Erste Schritte mit dem .NET Compact Framework (MSDN - Markus Wischy)

WAP Emulatoren
[4] Openwave: http://developer.openwave.com/download/index.html
[5] Deck-It: http://www.pyweb.com/

Microsoft embedded Betriebssysteme
[6] Produktinformation: www.microsoft.com/embedded
[7] Entwicklerinformation: msdn.microsoft.com/embedded