Seite 4: Auslesen der Daten und Fazit

Inhaltsverzeichnis

Auslesen der Daten

Anhand der bisher beschriebenen Schritte lassen sich Elemente nun in die Datenbank einpflegen. Das ist zweifellos ein großer Erfolg, aber nur die halbe Miete, denn in der Praxis muss man die Daten auch wieder aus der Datenbank auslesen. Im Beispiel geschieht das über den Button "Lese Status", dem Debugger präsentieren sich die Informationen in einem Array:

private void CmdReadStatii_Click(object sender, RoutedEventArgs e)
{
    myDb = new MyDataContext("Data Source=isostore:/DB.sdf");
    var r = from p in myDb.Statii
            select p;

    myStatiiEditingList = new List<Statii>();
    foreach (var D in r)
    {
        myStatiiEditingList.Add(D);
    }
    //BP hier
    myStatiiEditingList = myStatiiEditingList;
}

Im Quellcode sitzt die eigentliche Intelligenz in den beiden Zeilen, die mit var r beginnen. Dort wird ein so genannter LINQ-String erstellt, über den sich die Daten aus dem DataContext ziehen lassen. Die darauf folgende Verarbeitung ist in Standard-C# umgesetzt. Am Resultat ist der Umstand interessant, dass die Status ihre Kunden gleich als "Unterelemente" mitbekommen. Das ist der Effekt der zuvor besprochenen relationalen Bindung. Übrigens dienen Statements nach dem Schema a=a schon seit .NET CF 1.0 am PocketPC als weitgehend nebenwirkungsfreie Andockposition für Breakpoints.

Änderungen in einer Instanz einer Datenklasse wandern beim nächsten Aufruf der SubmitChanges-Methode des DataContext in die Datenbank. Im Beispiel zeigt das der Button "Benenne Status um", der mit folgender Logik verdrahtet ist:

private void CmdRenameStatii_Click(object sender, RoutedEventArgs e)
{
    foreach (Statii s in myStatiiEditingList)
    {
        if (s.myName == "Silver")
        {
            s.myName = "OW Ruby";
            myDb.SubmitChanges();
        }
    }
}

Mit einem Klick auf "Lese Statii" greift man hier auf den eingelesenen Silberstatus zu und ändert die Information aus dessen Namensfeld auf den neuen, von der Vielfliegerallianz vorgegebenen Namen. Danach wird der DataContext angewiesen, die Änderungen in die Datenbank zurückzuschreiben. Damit ist nun der Sinn der Normalisierung bewiesen. Hätte man den Status nicht "ausgelagert", hätten man alle Kundeneinträge einzeln aktualisieren müssen.

Manchmal soll eine Anwendung nur einige, durch bestimmte Kriterien definierte Datensätze verarbeiten. Zwar lassen sich in diesem Fall theoretisch alle Elemente auslesen und im Anschluss sortieren, LINQ to SQL bietet hierzu, wie eine echte Datenbank auch, passende Funktionen. Im Beispiel macht der Button "Lese Silber" von ihnen Gebrauch:

private void CmdFindSilver_Click(object sender, RoutedEventArgs e)
{
    Statii silverStatus=null;
    myDb = new MyDataContext("Data Source=isostore:/DB.sdf");
    
    foreach(Statii s in myStatiiEditingList)
    {
        if(s.myName=="Silver" || s.myName=="OW Ruby")
            silverStatus=s;
    }

    var r = from p in myDb.Kunden
            where p.myStatus==silverStatus.myStatusId
            select p;

    List<Kunden> myReadingList = new List<Kunden>();
    foreach (var D in r)
    {
        myReadingList.Add(D);
    }
    //BP hier
    myReadingList = myReadingList;
}

Im ersten Schritt findet die Routine die Klasse, die den Silberstatus enthält. Beim Test empfiehlt es sich daher, zunächst auf "Lese Statii" zu klicken, bevor man CmdFindSilver aufruft. Das erweitert den bekannten LINQ-String um ein where-Statement. Wie in klassischem SQL legt es auch in LINQ to SQL fest, dass die auszulesenden Datensätze eine bestimmte Bedingung erfüllen müssen.

An verbotene Orte schreiben

Obwohl das Isolated-Storage-Konzept für viele Nutzer keine Probleme aufwirft, stellt es Entwickler vor teils ärgerliche Hürden. Zwar kann man – Socketsupport sei Dank – am Windows Phone 7 einen FTP-Client realisieren, doch was macht man, wenn man eine .doc- oder .xls-Datei vom Server herunterlädt und in Mobile Office übertragen möchte? Microsofts Lösung ist in Abbildung 3 skizziert, ein aus Entwicklersicht suboptimaler Vorschlag: Die heruntergeladenen Binärdateien müssen an einen externen, vom Entwickler betriebenen Server übertragen werden. Dieser packt die Daten anschließend in eine E-Mail und schickt sie dem Benutzer an seinen mit dem Windows Phone 7 verbundenen E-Mail-Account. Von dort aus müsste man sie dann mit Mobile Office öffnen – komplexer geht es kaum.

Nach einem etwas simpleren Schema erfolgt der (partielle) Zugriff auf die Medienbibliothek. Das von der Xbox bekannte XNA-Framework enthält spezielle Medienklassen, die der Entwickler auch in Silverlight-Anwendungen integrieren kann. Man muss jedoch mit der Einschränkung leben, dass man nicht auf alle Ordner der Bibliothek zugreifen kann.

Fazit

Microsofts Windows Phone 7 bietet eine Vielzahl an Möglichkeiten zur Persistierung von Daten. Je nach vorliegender Datenart ist eine andere Vorgehensweise sinnvoll. So empfehlen sich Isolated Settings für klassische Konfigurationseinstellungen, während komplexe und hierarchisch strukturierte Daten in einer SQL-Datenbank besser aufgehoben sind. Zu einigen der beschränkten APIs von Windows Phone 7 gibt es Kniffe, welche die zum Teil ärgerlichen Limitationen umschiffen. LINQ to SQL erlaubt hier mitunter illustre Verfahren, die aus Platzgründen nicht näher beschrieben sind. Wer sich mit dem Windows Phone befasst, sollte definitiv etwas Zeit für das Einarbeiten in das System investieren.

Tam Hanna
befasst sich seit der Zeit des Palm IIIc mit Programmierung und Anwendung von Handheldcomputern. Er entwickelt Programme für diverse Plattformen, betreibt Onlinenews-Dienste zum Thema und steht unter tamhan@tamoggemon.com für Fragen, Trainings und Vorträge gern zur Verfügung. (rl)