Auf der #MIX10 hat Microsoft virtuell die Hosen runtergelassen und viele, viele Details zu Windows Phone 7 Series veröffentlicht. Dabei waren Dinge, die für viele Entwickler, die bisher für Windows Mobile entwickelt haben, unverständlich sind und echte Showstopper darstellen, etwa der Verzicht auf C++, das Nicht-Vorhandensein einer Datenbank, die Einschränkungen hinsichtlich Ressourcen-Zugriff.

Allgemein gibt es im Moment ein gewaltiges Aufheulen in der Community, erste Petitionen werden gestartet, das große Jammern setzt ein. Dabei wird gerne übersehen, dass es zwei ganz gewaltige Unterschiede zwischen Windows Phone und Windows Mobile gibt:

1. Windows Phone ist ein kompletter Neustart. Neu, neu, neu – alte Zöpfe wurden abgeschnitten, neue Ansätze ausgelotet. Das System ist darüber hinaus ein klassisches 1er Release, d.h. derzeit fehlende APIs und Funktionalitäten werden ziemlich sicher zukünftig nachgereicht.
2. Die Zielgruppe ist eine komplett andere: Bisher waren es Geschäftskunden in verschiedenen Ausprägungen (klingt irgendwie… krank), jetzt sind es Privatleute. Menschen, die ganz andere Dinge, als beim bisherigen System erwarten. Und damit ändern sich auch die zur Verfügung gestellten Funktionalitäten und die Schwerpunkte der Plattform.

Beide Dinge sollte man verstehen, bevor man anfängt, sich über die Plattform aufzuregen.

Das .NET Compact Framework – der kleine Bruder des "normalen" .NET-Frameworks – verfügt leider nicht über eine WebClient-Klasse. Stattdessen müssen Sie sich mit den auch vom WebClient verwendeten Klassen HttpWebRequest und HttpWebResponse "herumschlagen". Wobei dies im Grunde sehr einfach ist.

Angenommen, sie wollen das Versenden eines Formulars nachstellen, dann würden Sie folgenden Code verwenden können:

// Parameter werden als Name-Wert-Parameter übertragen
string parameters = "name=wert&name2=wert2";

// Request erzeugen
HttpWebRequest request = (HttpWebRequest) WebRequest.Create("http://...");

// Pufferung aktivieren (.NETCF-spezifisch)
request.AllowWriteStreamBuffering = true;

// Zugriffsmethode definieren
request.Method = "POST";

// Inhaltslänge übertragen
request.ContentLength = parameters.Length;

Nachdem Sie so den WebRequest konfiguriert haben, müssen Sie die Daten übertragen. Sie können dies mit Hilfe der Stream-Implementierung erledigen, die Sie über die GetRequestStream()-Methode der WebRequest-Implementierung referenzieren können. Selbst und direkt in den Stream zu schreiben, wäre zwar möglich, aber wozu sich die Finger schmutzig machen, wenn Sie im System.IO-Namensraum bereits eine StreamWriter-Klasse haben, die die ganze Arbeit übernimmt?

// StreamWriter zum Schreiben verwenden
StreamWriter sw = new StreamWriter(request.GetRequestStream());

// Informationen übertragen
sw.Write(parameters);

// Daten senden
sw.Flush();

// StreamWriter schließen
sw.Close();

Wichtig ist in diesem Kontext, das Sie per .Flush() und .Close() das Senden der Daten und das Schließen des StreamWriters explizit vornehmen, da Ihnen ansonsten beim Abrufen der Daten eine ProtocolViolationException um die Ohren fliegt.

Nun können die Daten abgerufen werden. Dies geschieht mit Hilfe einer WebResponse-Implementierung, die sie über die Methode GetResponse() des WebRequests erreichen können. Diese WebResponse-Implementierung verfügt über eine Methode GetResponseStream(), die eine Stream-Implementierung zurück gibt, die es erlaubt, die Rückgabe des Servers abzurufen. Auch hier haben Sie die Wahl: Entweder das Rad neu erfinden, oder einen StreamReader verwenden:

// WebResponse-Implementierung abrufen
HttpWebResponse response = (HttpWebResponse) request.GetResponse();

// StreamReader zum Einlesen des HTMLs
StreamReader sr = new StreamReader(response.GetResponseStream());

// Rückgabe abrufen
string result = sr.ReadToEnd();

// Fertig
sr.Close();

Fertig. So richtig schwer war es eigentlich nicht. Um den Code noch besser nutzbar zu machen, empfiehlt es sich, ihn in einem Try-Catch-Block zu kapseln und die ggf. auftretenden Ausnahmen (keine Verbindung, falsche URL, sonstige Fehler) entsprechend abfangen zu lassen.

Entweder bin ich nicht in der Lage, mit dem Webbrowser-Control vom .NET CompactFramework umzugehen, oder es gibt da tatsächlich sowas wie einen Bug, wenn man es mit dem IE6 Mobile nutzen muss (was ja nicht in der Hand des Entwicklers liegt). Folgendes Szenario funktioniert bei mir schlicht nicht, wenn ich es mit einem IE6 Mobile im Emulator oder auch auf real existierenden Geräten (HTC Touch Pro2 beispielsweise) benutze:

Gegeben sei ein Formular mit einem darauf befindlichen Webbrowser-Control namens webBrowser1. Es gibt einen Eventhandler, der an das Navigating-Ereignis gebunden ist und nichts anderes machen soll, als die anzuspringende Adresse auszugeben:

private void webBrowser1_Navigating(object sender, WebBrowserNavigatingEventArgs e)
{
   MessageBox.Show(e.Url.ToString());
}

Beim Load-Ereignis des Formulars wird dem Webbrowser-Control über dessen .DocumentText-Eigenschaft ein einfacher HTML-Code zugewiesen:

private void Form1_Load(object sender, EventArgs e)
{
   string html =
      "<html><head><title>Sample</title></head><body><a href=\"http://www.microsoft.de\">Microsoft.de</a></body></html>";
   webBrowser1.DocumentText = html;
}

Auf einem Gerät mit dem (alten) IE4 gibt es zwei Anzeigen der MessageBox:

Wenn man es mit dem IE6 Mobile (etwa im Windows Mobile 6.5-Emulator) versucht, geschieht dies nicht – es wird nur die initiale MessageBox angezeigt:

Auch ein erneutes Binden des Ereignishandlers funktioniert nicht. Dabei – und das ist interessant – werden JavaScripts beispielsweise innerhalb der Webseite ausgeführt. Aber der Klick auf den Link führt zu keiner Reaktion – noch nicht einmal die referenzierte Webseite wird aufgerufen.

Bisher habe ich keinen Workaround darum gefunden. Ich weiß, dass das OpenCFFramework da was anbietet, aber ich sehe – wenn ich ehrlich bin – nicht wirklich ein, auf ein anderes Framework zu wechseln, wenn es sich doch um eine bereits in der Vergangenheit funktionierende Funktionalität handelt.

Nix da, ich nenne das einen Bug.