Neue Benutzeroberflächentechnologien

Seiten und Popups in Windows Phone 7

Charles Petzold

Beispielcode herunterladen.

Die Interaktionen zwischen Benutzern und Computeranwendungen finden normalerweise ohne Unterbrechung statt. Wir geben Texte in ein Textverarbeitungsprogramm, Zahlen und Formeln in eine Tabelle ein, und wir blättern Seiten in einem E-Book-Reader um. Es kommt aber gelegentlich vor, dass Anwendungen zusätzliche Informationen von den Benutzern benötigen, oder dass Benutzer Operationen initiieren, um Anwendungen mit weiteren Informationen zu versorgen.

Bei einer traditionellen Windows-Anwendung ist allgemein bekannt, was dann folgt: Ein Dialogfeld wird angezeigt. Füllen Sie es aus, und klicken Sie auf „OK“. Oder klicken Sie auf „Abbrechen“, wenn Sie Ihre Meinung geändert haben.

Wie sich eine Windows Phone 7-Anwendung verhält, ist jedoch nicht ganz klar. Weder in Silverlight für das Web noch in Silverlight für Windows Phone gibt es etwas wie ein „Dialogfeld“. Ich verwende diesen Begriff aber gerne, um Mechanismen zu beschreiben, mit denen Anwendungen Benutzer auffordern, Informationen bereitzustellen. Offensichtlich unterscheiden sich Dialogfelder von Silverlight jedoch ein wenig von den traditionellen.

Im Laufe der vergangenen Ausgaben dieser Rubrik habe ich nach und nach einen E-Book-Reader für Windows Phone 7 auf der Basis von Buchdateien in reiner Textform erstellt, die von der Project Gutenberg-Site heruntergeladen werden. Es ist an der Zeit, dieses Programm mit einer ganzen Reihe von Dialogfeldern zu erweitern.

Zwei Ansätze

Beim Implementieren von Dialogfeldern in eine Silverlight-Anwendung für Windows Phone 7 haben Sie zwei Möglichkeiten.

Ein sehr naheliegender Ansatz ist wahrscheinlich das Definieren von Dialogfeldern als separate Seiten. Leiten Sie eine neue Klasse von PhoneApplicationPage ab, und befüllen Sie sie mit einer Reihe Tasten, Textfeldern und so weiter. Dieses Dialogfeld wird dann von einer Seite aufgerufen, indem mithilfe des NavigationService-Objekts der Seite dorthin navigiert wird. Die Zurück-Taste (oder etwas anderes) beendet das Dialogfeld und kehrt zu der Seite zurück, von der es aufgerufen wurde.

Die zweite Möglichkeit besteht in dem, was ich als „Popup“-Ansatz bezeichne. Dieser Ansatz könnte die Popup-Klasse nutzen, doch das ist nicht erforderlich. (Ich werde den Unterschied gleich erläutern.) Diese Art des Dialogfelds wird in der Regel von UserControl abgeleitet. Es wird im oberen Bereich der Seite, von der es aufgerufen wird, sichtbar angezeigt und ausgeblendet, wenn Benutzer die Interaktion mit ihm beenden. Es ist keine Navigation nötig.

Dialogfelder, die als navigierbare Seiten implementiert werden, sind an sich modal. (Ein modales Dialogfeld blockiert die Interaktion mit dem aufrufenden Fenster oder der aufrufenden Seite bis das Dialogfeld geschlossen wird.) Mit dem Popup-Ansatz kann ein Dialogfeld entweder modal oder nicht modal sein. Um ein modales Popup zu implementieren, muss der Programmierer sicherstellen, dass Benutzer mit der zugrunde liegenden Seite nicht interagieren können, solange das Popup aktiv ist. Insofern ist es etwas leichter, ein nicht modales Popup zu implementieren. In der Regel ist es schwierig, zwischen der gleichzeitigen Eingabe über einen nicht modalen Dialog und eine zugrunde liegende Seite zu jonglieren.

Seit dem MiddlemarchReader-Programm, das ich in meiner Rubrik im Juli vorgestellt habe (msdn.microsoft.com/magazine/hh288085), verfügen meine E-Book-Reader über eine integrierte Option, mit der eine Liste der Kapitel in einer ListBox angezeigt wird. Sie können dann eines der Kapiteltitel auswählen und an den Anfang dieses Kapitels springen. Sie kann als Dialogfeld bezeichnet werden, und ich hatte mich entschlossen, sie als Popup zu implementieren, obwohl die Logik etwas unübersichtlich war: Die das Popup aufrufende ApplicationBar-Taste diente auch zum Schließen des Popups, und das erforderte ein anderes Bild für die Taste.

Im Nachhinein betrachtet hätte ich dieses Dialogfeld als separate Seite implementieren sollen. Genau das wird nun in dem HorrorReader-Programm umgesetzt, das ich in diesem Artikel beschreibe. Zur Feier von Oktober und Halloween können Sie mit HorrorReader vier Horrorklassiker lesen: „Frankenstein“, „Dracula“, „Dr. Jekyll and Mr. Hyde“ und „The Turn of the Screw“, wie in Abbildung 1 dargestellt. (Der E-Book-Reader wird im nächsten Monat die potenzielle Bibliothek endlich auf ca. 35.000 Bücher erweitern – versprochen!)

Abbildung 1: Die MainPage-Anzeige von HorrorReader

Als ich die ListBox des Kapitels von einem Popup in eine navigierbare Seite geändert habe, habe ich mich gefragt, warum ich Windows Phone 7-Dialogfelder als Popups implementieren wollte. Ich habe eine überraschende Motivation gefunden: Angst.

Navigationsangst

Wenn Sie überhaupt schon einmal Windows Phone 7 programmiert haben, kennen Sie sich möglicherweise mit Tombstoning aus: Unter bestimmten Umständen kann eine aktive Anwendung beendet und aus dem Speicher entfernt werden. Dies geschieht, wenn Benutzer die Taste „Start“ auf dem Telefon drücken, um den Startbildschirm anzuzeigen. Da das Telefon eine Zeit lang keine Eingaben erhalten hat, wird die Anzeige ausgeschaltet und gesperrt, oder die Benutzer schalten den Bildschirm manuell aus.

Die Anwendung wird erneut gestartet, wenn die Benutzer den Bildschirm entsperren oder die Zurück-Taste drücken, um zurück zum Programm zu navigieren. Das Windows Phone 7-Betriebssystem zeigt die letzte aktive Seite in der Anwendung an, doch für die Herstellung aller anderen Informationen ist lediglich der Programmierer verantwortlich. In der Regel verwendet eine Seite das State-Wörterbuch von PhoneApplicationPage zum Speichern kurzlebiger, mit der Seite verknüpfter Informationen, während das App-Objekt das State-Wörterbuch von PhoneApplicationService zum Speichern kurzlebiger Anwendungsdaten verwendet und permanente Daten isoliert speichert.

Beim Programmieren für das Tombstoning wird die OnNavigatedFrom-Methode in der Seite zum Speichern von Seiteninformationen sowie die OnNavigatedTo-Methode zum Wiederherstellen dieser Informationen überschrieben. Das ist in Ordnung, wenn ein Tombstoning des Programms erfolgt oder das Programm nach erfolgtem Tombstoning wieder aktiviert wird. Wenn sich die Seite jedoch einfach in dem Prozess befindet, zu einer anderen Seite zu navigieren oder von dort zurückzukehren, ist das Speichern und Wiederherstellen von Seiteninformationen unnötig. Je nachdem, wie viele Informationen hierbei involviert sind, könnte diese zusätzliche Aktivität die Seitennavigation beträchtlich verlangsamen.

Diese zusätzliche Aktivität kann z. B. dadurch vermieden werden, dass die Anwendung schlicht auf eine Seite beschränkt und Dialogfelder mit Popups implementiert werden. Genau das habe ich in den vorhergehenden Versionen des E-Book-Readers umgesetzt. Ich habe die Seitennavigation umgangen, weil ich eine Verlangsamung durch den Tombstoning-Code befürchtete.

Das ist aber unsinnig. Es ist wirklich nur dann ein Problem, wenn Tombstoning in den Ansatz implementiert wird, den ich nun als „dummen Ansatz“ betrachte! Eine Seite sollte nicht viele Statusinformationen speichern, es sei denn, für die Anwendung erfolgt tatsächlich ein Tombstoning. Sie sollte zudem nicht versuchen, diese Informationen wiederherzustellen, es sei denn, sie werden aus einem Tombstone-Status heraus wieder aktiviert. In Windows Phone 7.1 werden die Navigationsüberschreibungen mit zusätzlichen Informationen zum intelligenteren Implementieren dieser Methoden bereitgestellt. In der Zwischenzeit können Sie die Schwerarbeit an die App-Klasse verweisen, die in erster Linie für die Behandlung der von PhoneApplicationService implementierten Ereignisse zuständig ist. Diese Ereignisse geben genau an, ob für eine Anwendung ein Tombstoning erfolgt oder ob sie wieder aktiviert wird.

Es ist in der Regel vorteilhaft, auch die OnNavigatedTo-Überschreibung zu straffen. Diese Logik kann ziemlich einfach sein: Wenn ein bestimmtes Feld Null ist, muss es erneut generiert werden; wenn es nicht Null ist, ist das Objekt dasselbe, das es vor der Navigation war, da für die Anwendung kein Tombstoning erfolgte.

Die Struktur von HorrorReader

Die App-Datei in HorrorReader hat zwei öffentliche Eigenschaften, mit denen die im isolierten Speicher gespeicherten Objekte referenziert werden. Mit der ersten Eigenschaft AppSettings werden Anwendungseinstellungen gespeichert, die für alle Bücher gelten. Dazu gehören die Schriftfamilie, Schriftgröße und der Stil für die Seitenübergänge. Die zweite Eigenschaft, die CurrentBook-Eigenschaft von App, ist ein Objekt vom Typ BookInfo, das alle einzelnen Eigenschaften enthält, die das Buch betreffen. Dazu gehören der Dateiname des aktuellen Buchs, das aktuelle Kapitel und die aktuelle Seite, die Sammlung von Paginierungsdaten speichernden ChapterInfo-Objekten sowie Sammlungen von Lesezeichen und Anmerkungen, die in dieser Version neu sind. Für jedes einzelne der vier Bücher in der Bibliothek wurde ein eigenes BookInfo-Objekt im isolierten Speicher gespeichert. Dieses BookInfo-Objekt wird allerdings erst beim ersten Lesen des Buches erstellt.

HorrorReader hat sechs von PhoneApplicationPage abgeleitete Klassen. Diese Klassen sind alle Teil des HorrorReader-Projekts und können leicht anhand des Wortes „Page“ in den jeweiligen Namen identifiziert werden. Abgesehen von App befinden sich alle anderen Klassen in der Petzold.Phone.EbookReader-DLL (Dynamic Link Library).

Wie in Abbildung 1 dargestellt, verfügt MainPage über vier Tasten, mit denen Sie eines der vier verfügbaren Bücher auswählen können. (Diese Seite wird in der Programmversion des nächsten Monats ausgetauscht.) Wenn Benutzer eine dieser Tasten betätigen, navigiert MainPage zu BookViewerPage, die in erster Linie für das Hosten des BookViewer-Steuerelements und die Implementierung verschiedener Popups zuständig ist.

BookViewerPage verfügt über vier ApplicationBar-Tasten. Die ersten drei bewirken die Navigation zu anderen Seiten: ChaptersPage, BookmarksPage und AnnotationsPage. Ein Bookmark oder Lesezeichen ist einfach ein benutzerseitig gekennzeichneter Verweis auf eine bestimmte Buchseite. Eine Annotation oder Anmerkung ist eine Textauswahl, die mit einem optionalen Hinweis ergänzt wird. Jede dieser drei Seiten enthält eine ListBox, und jede einzelne veranlasst die BookViewerPage, zu einer neuen Seite in dem Buch zu springen.

Das ApplicationBar-Menü in BookViewerPage enthält drei Elemente: „smaller text“, „larger text“ und „settings“. Die ersten beiden wirken sich auf die Schriftgröße in Inkrementschritten von 10 Prozent aus, und „settings“ navigiert zu SettingsPage, die ein Pivot-Steuerelement für die Auswahl der Schriftarten und gewünschten Seitenübergänge, wie in Abbildung 2 dargestellt, ausführt. Der Text im unteren Bereich der Seite ist eine Vorschau der ausgewählten Schriftart.

Abbildung 2: Das Pivot mit den Einstellungen für die Schriftartauswahl

Bei der Bearbeitung dieser Seite stieß ich auf einen offensichtlichen Konflikt mit dem Schieberegler und der GestureListener-Klasse aus dem Windows Phone Toolkit. Ich musste meinen eigenen Schieberegler implementieren und habe ihn so bearbeitet, dass er nur in Inkrementschritten von 10 Prozent springt.

Ich bin nicht ganz glücklich mit dem Einsatz von PhoneApplicationPage-Ableitungen als Dialogfelder. Ich ziehe strukturiertere Maßnahmen vor, um Informationen an ein Dialogfeld weiterzugeben und zurückzuerhalten. Diese Art Datentransfer ist in einer Navigationsstruktur häufig ziemlich umständlich. Ich hätte es z. B. vorgezogen, dass BookViewerPage eine Referenz des aktuellen Buches an ChaptersPage weitergibt und ChaptersPage das vom Benutzer ausgewählte Kapitel an BookViewerPage zurückgibt. Anders ausgedrückt möchte ich, dass ChaptersPage eher wie eine Funktion ohne Nebeneffekte arbeitet. Vielleicht werde ich eines Tages einen Wrapper um PhoneApplicationPage entwickeln, der mir das bietet. Bis dahin habe ich es für den HorrorReader so gelöst, dass alle Seiten einfach Daten gemeinsam verwenden, indem sie auf dieselbe CurrentBook-Eigenschaft in der App-Klasse verweisen.

Einblendung oder Popup?

Obwohl ich PhoneApplicationPage-Ableitungen für die Kapitel-, Lesezeichen- und Anmerkungsliste sowie für die Einstellungen eingesetzt habe, brauchte ich immer noch verschiedene Popups.

Es gibt im Grunde zwei Möglichkeiten, ein Popup in Silverlight für Windows Phone zu implementieren. In dem einen Ansatz wird einfach ein Steuerelement (oder häufiger eine UserControl-Ableitung) direkt in die visuelle Struktur der Seite eingefügt. Dieses Steuerelement ist das oberste Element, doch seine Visibility-Eigenschaft wird mit „Collapsed“ initialisiert. Wenn das Popup eingeblendet werden soll, legen Sie die Visibility-Eigenschaft auf „Visible“ fest.

Hinsichtlich eines modalen Popups möchten Sie wahrscheinlich alle anderen Elemente auf der Seite deaktivieren. Legen Sie hierfür die IsEnabled-Eigenschaft des zugrunde liegenden Steuerelements oder alternativ die IsHitTestVisible-Eigenschaft auf „False“ fest. Diese beiden Eigenschaften sind ähnlich. IsEnabled ist jedoch auf Steuerelemente beschränkt, während IsHitTestEnabled auch mit FrameworkElement-Ableitungen, wie z. B. Bereiche, verwendet werden kann. Mit der IsEnabled-Eigenschaft werden auch einige Steuerelemente abgeblendet. Eine andere Möglichkeit besteht darin, das Popup bildschirmfüllend und mit einem durchscheinenden Hintergrund zu gestalten, der die Toucheingabe blockiert. Unabhängig von der verwendeten Technik werden Sie wahrscheinlich auch die ApplicationBar deaktivieren müssen. (Auf dieses Problem wird in Kürze näher eingegangen.)

Alternativ kann das Popup-Element verwendet werden. Das Popup-Element verfügt über eine Child-Eigenschaft, die Sie wahrscheinlich auf eine UserControl-Ableitung festlegen. (Ich wünschte, ich könnte vom Popup-Element ableiten, aber es ist versiegelt.) Standardmäßig ist die IsOpen-Eigenschaft von Popup auf „False“ festgelegt. Sie legen sie auf „True“ fest, damit das untergeordnete Element von Popup sichtbar wird. Popup verfügt zudem über die praktischen Eigenschaften HorizontalOffset und VerticalOffset, mit denen Sie das untergeordnete Element positionieren können.

Ein interessanter Aspekt von Popup besteht darin, dass es kein übergeordnetes Element erfordert. Anders ausgedrückt muss es nicht Teil der visuellen Struktur sein. Sie können einfach ein Popup-Objekt im Code erstellen, die Child-Eigenschaft festlegen und die IsOpen-Eigenschaft auf „True“ festlegen, und es wird als oberstes Element sichtbar angezeigt.

Seien Sie trotzdem vorsichtig. Wenn Popup kein übergeordnetes Element hat, sind die Eigenschaften HorizontalOffset und VerticalOffset relativ zur oberen linken Ecke des PhoneApplicationFrame-Objekts, das allen PhoneApplicationPage-Objekten konzeptionell zugrunde liegt. Der Frame umfasst die Taskleiste oben auf dem Bildschirm, das Popup wird aber nicht oben auf der Taskleiste angezeigt. Wenn die Taskleiste sichtbar ist, wird das untergeordnete Popup-Element oben abgeschnitten. Nur der die PhoneApplicationPage überlagernde Teil ist dann sichtbar. Legen Sie die VerticalOffset-Eigenschaft möglichst auf einen Wert ungleich Null fest, um die Taskleiste anzupassen.

Ein Popup ohne übergeordnetes Element hat den Vorteil, dass es einfach modal gemacht werden kann. Sie legen einfach die IsEnabled-Eigenschaft der PhoneApplicationPage-Ableitung auf „False“ fest und deaktivieren im Endeffekt alle anderen Bestandteile der Seite mit einem Schlag.

Donnerwetter, das wäre doch nett. In Wirklichkeit geschieht das aber nicht, da die ApplicationBar nicht Teil der visuellen Struktur der Seite ist. Sie müssen die ApplicationBar separat deaktivieren. Sie verfügt über eine praktische IsMenuEnabled-Eigenschaft, weist aber keine gesonderte Eigenschaft zum Deaktivieren der Tasten auf. Sie müssen diese Tasten einzeln bearbeiten.

Ich wollte zwei der benötigten Popups an verschiedene Stellen relativ zur Seite bewegen. Das ist einfach, wenn das Dialogfeld ein untergeordnetes Element von Popup ist. Andernfalls benötigen Sie ein TranslateTransform für das Steuerelement des Dialogfelds. Zum Vereinfachen des Tombstoning habe ich mich für Einheitlichkeit entschieden und verwende das Popup-Element für alle meine Popups. Zudem habe ich entschieden, jedes Popup und untergeordnete Element in der visuellen Struktur der Seite zu definieren. Somit sind die Eigenschaften HorizontalOffset und VerticalOffset eher relativ zur Seite als zum Frame.

Eines dieser Popups ist eine in BookViewerPage.xaml definierte ListBox namens textSelectionMenu. Dies ist das Menü, das angezeigt wird, wenn Sie eine Textauswahl treffen, wie in meiner Rubrik im September beschrieben (msdn.microsoft.com/magazine/hh394142). Eine der Optionen ist „note“, die ein anderes, von einer UserControl-Ableitung definiertes Popup namens AnnotationDialog aufruft. Hiermit können Benutzer Hinweise wie in Abbildung 3 dargestellt eingeben.

Abbildung 3: Das Popup AnnotationDialog

Sie können ein neues Lesezeichen definieren, indem Sie mit Ihrem Finger die Seite herauf- oder herunterstreichen. Mithilfe von BookmarkDialog können Sie eine Beschriftung eingeben.

BookmarkDialog bzw. AnnotationDialog können auch auf BookmarksPage und AnnotationsPage zum Bearbeiten eines vorhandenen Elements angezeigt werden. Sie können auch ein Lesezeichen oder einen Hinweis auf diesen Seiten löschen. Das ruft ein weiteres Popup namens OkCancelDialog auf. Es ist der standardmäßigen MessageBox von Windows Phone 7 ähnlich, außer dass es keine Geräusche macht, wenn es angezeigt wird.

Das letzte Popup ist FindDialog, das von der vierten ApplicationBar-Taste aufgerufen wird, siehe Abbildung 4. Hiermit können Sie anhand von vertrauten Optionen nach Text in dem Buch suchen. Bei jeder gefundenen Übereinstimmung wird der Text hervorgehoben, und FindDialog springt an den Anfang oder ans Ende der Seite, damit der hervorgehobene Text sichtbar wird.

Abbildung 4: Das Popup FindDialog

Tombstoning von Popups

Sollten Popups Tombstoning berücksichtigen? Folgendes Szenario stellte ich mir vor: Angenommen, ich suche nach Text in einem Buch und verwende dafür das Popup-Dialogfeld aus Abbildung 4. Dann lege ich das Telefon auf den Tisch. Einige Minuten später nehme ich das Telefon wieder auf, und der Bildschirm ist gesperrt. Ich drücke die Einschalttaste und lösche das Hintergrundbild. Sollte FindDialog immer noch in dem Status, in dem ich es verlassen habe, angezeigt werden?

Meine widerstrebende Antwort lautete: natürlich. Ich musste einräumen, dass es das ist, was die Benutzer erwarten und was geschehen sollte. Das bedeutete, dass ein Tombstoning für Popups erfolgen musste.

Also habe ich für jede Seite, die ein Popup hostet, ein Feld vom Typ „Popup“ namens activePopup definiert, das gesetzt wird, wenn das Popup sichtbar ist. Wird dieses Feld während eines Aufrufs von OnNavigationFrom gesetzt, kann das nur bedeuten, dass für das Programm ein Tombstoning erfolgt, da alles andere deaktiviert wird, während das Popup sichtbar ist. In diesem Fall speichert die Seite den Namen des Popups im State-Wörterbuch der Seite. Sie prüft zudem, ob das untergeordnete Element des Popups die ITombstonable-Schnittstelle implementiert, die ich mit zwei Methoden definiert habe: SaveState und RestoreState. Sie geben an, wie die Dialogfeld-Popups AnnotationDialog, BookmarkDialog, OkCancelDialog und FindDialog den jeweiligen aktuellen Status während des Tombstoning speichern und wiederherstellen.

Überschreibungen der Zurück-Taste

Ich habe ein ganzes Buch über die Windows Phone 7-Programmierung geschrieben, und ich habe noch nicht einmal ein Beispiel für die von PhoneApplicationPage definierte Überschreibung der OnBackKeyPress-Methode aufgenommen. Wie töricht. Die in dieser Methode referenzierte Zurück-Taste befindet sich von den drei Hardwaretasten des Telefons ganz links. Standardmäßig navigiert die Zurück-Taste von einer Seite zurück zu der Seite, die sie aufgerufen hat. Wenn sich eine Anwendung auf ihrer Hauptseite befindet, beendet die Zurück-Taste das Programm.

Beim Implementieren der verschiedenen Dialogfelder in Form von Popups wurde mir klar, dass ich das Verhalten der Zurück-Taste recht häufig überschreiben musste. Die allgemeine Regel lautet folgendermaßen: Immer wenn absehbar ist, dass Benutzer die Zurück-Taste drücken, ohne dass sie von der Seite weg navigieren oder eine Anwendung beenden möchten, sollten Sie OnBackKeyPress überschreiben.

Jede Seite, die ein Popup hosten kann (in meinem Fall waren das BookViewerPage, AnnotationsPage und BookmarksPage), sollte die Zurück-Taste zum Schließen des Popups überschreiben, ähnlich wie beim Klicken auf die Schaltfläche zum Schließen des Fensters in einem traditionellen Dialogfeld. Das Argument für die OnBackKeyPress-Methode ist eine Instanz von CancelEventArgs. Legen Sie die Eigenschaft „Cancel“ auf „True“ fest, um zu verhindern, dass die Zurück-Taste ihre normale Navigationsfunktion ausführt.

Wenn ein Popup aktiv ist und ein TextBox-Element im Popup den Eingabefokus besitzt, wird eine Bildschirmtastatur angezeigt. Durch Drücken der Zurück-Taste zu diesem Zeitpunkt wird die Tastatur automatisch geschlossen. Durch erneutes Drücken der Zurück-Taste wird das Popup geschlossen. Drücken Sie erneut auf die Zurück-Taste, und Sie kehren zur vorherigen Seite zurück. In jedem Fall verändert sich die visuelle Anzeige drastisch und gibt den Benutzern das gute Feedback, dass das Drücken der Zurück-Taste tatsächlich etwas bewirkt.

Seien Sie beim Überschreiben der OnBackKeyPress-Methode vorsichtig. Es sollte niemals möglich sein, dass Benutzer in einer Schleife gefangen sind, in der das wiederholte Drücken der Zurück-Taste die Anwendung nicht beendet! Sie werden das Programm niemals in den Windows Phone 7-Marketplace bekommen, wenn das der Fall ist.

Bereit für das Front-End

Beim Programmieren besteht häufig ein großer Unterschied darin, eine Instanz einer Entität oder mehr als eine Instanz zu unterstützen. Neben den verschiedenen Seiten und Popups in HorrorReader hat das Programm gegenüber meinen vorherigen E-Book-Readern einen großen Fortschritt gemacht, da Sie nun vier Bücher anstatt nur eines lesen können. Jedes Buch verfügt über ein eigenes BookInfo-Objekt, das im isolierten Speicher gespeichert wird. Somit ist jedes Buch von den anderen unabhängig.

Nun müssen Sie nur noch MainPage durch ein neues Front-End ersetzen, mit dem Sie die Bücher von der Project Gutenberg-Site herunterladen können. Weitere Änderungen sind nicht erforderlich. Das dürfte doch einfach sein.

Charles Petzold* schreibt seit langem redaktionelle Beiträge für das* MSDN Magazine*. Sein neues Buch „Programming in Windows Phone 7“ (Microsoft Press 2010) ist als kostenloser Download unter bit.ly/cpebookpdf verfügbar. In diesem Monat feiert Petzold den 25. Jahrestag seiner Beiträge zum* MSDN Magazine und zu seinem Vorläufer, dem Microsoft Systems Journal*.*

Unser Dank gilt dem folgenden technischen Experten für die Durchsicht dieses Artikels: Richard Bailey