Zusammenfassung von Kapitel 24. Seitennavigation
Das Beispiel herunterladenHinweis
Dieses Buch wurde im Frühjahr 2016 veröffentlicht und seitdem nicht aktualisiert. Wenngleich ein großer Teil des Buchs weiterhin relevante Informationen liefert, sind einige Abschnitte veraltet, und einige Themen sind nicht mehr korrekt oder vollständig.
Viele Anwendungen bestehen aus mehreren Seiten, zwischen denen der Benutzer navigiert. Die Anwendung verfügt immer über eine Hauptseite oder Startseite, von der aus der Benutzer zu anderen Seiten navigiert, die in einem Stapel verwaltet werden, um zu ihnen zurückkehren zu können. Zusätzliche Navigationsoptionen werden in Kapitel 25, „Seitenvarianten“, behandelt.
Modale Seiten und Seiten ohne Modus
VisualElement definiert eine Navigation-Eigenschaft vom Typ INavigation, die die folgenden zwei Methoden zum Navigieren zu einer neuen Seite enthält:
Beide Methoden akzeptieren eine Page-Instanz als Argument und geben ein Task-Objekt zurück. Mit den folgenden zwei Methoden wird zur vorherigen Seite zurücknavigiert:
Wenn die Benutzeroberfläche über eine eigene Schaltfläche Zurück verfügt (wie bei Android- und Windows Phone-Telefonen), muss die Anwendung diese Methoden nicht aufrufen.
Obwohl diese Methoden über jedes VisualElement verfügbar sind, werden Sie in der Regel von der Navigation-Eigenschaft der aktuellen Page-Instanz aufgerufen.
Anwendungen verwenden generell modale Seiten, wenn der Benutzer vor der Rückkehr zur vorherigen Seite Informationen auf der Seite angeben muss. Seiten ohne Modus werden manchmal auch als „nicht modal“ oder hierarchisch bezeichnet. Nichts auf einer Seite mach sie selbst als modal oder nicht modal kenntlich. Dies wird stattdessen von der Methode gesteuert, die für die Navigation zu der Seite verwendet wird. Um auf allen Plattformen zu funktionieren, muss eine modale Seite ihre eigene Benutzeroberfläche für die Rückkehr zur vorherigen Seite bereitstellen.
Mit dem ModelessAndModal-Beispiel können Sie den Unterschied zwischen Seiten ohne Modus und modalen Seiten untersuchen. Jede Anwendung, die Seitennavigation verwendet, muss ihre Startseite an den NavigationPage-Konstruktor übergeben, in der Regel in der App-Klasse des Programms. Ein Vorteil besteht darin, dass Sie kein Padding mehr auf der Seite für iOS festlegen müssen.
Sie werden feststellen, dass die Title-Eigenschaft der Seite für Seiten ohne Modus angezeigt wird. Die Tablet- und Desktopplattformen iOS, Android und Windows stellen alle ein Benutzeroberflächenelement bereit, um zur vorherigen Seite zurückzukehren. Natürlich verfügen Android- und Windows Phone-Geräte über eine Standardschaltfläche Zurück, um zurückzuwechseln.
Bei modalen Seiten wird der Title der Seite nicht angezeigt, und es wird kein Benutzeroberflächenelement bereitgestellt, um zur vorherigen Seite zurückzukehren. Obwohl Sie die Standardschaltfläche Zurück von Android und Windows Phone verwenden können, um zur vorherigen Seite zurückzukehren, muss die modale Seite auf den anderen Plattformen ihren eigenen Mechanismus für die Rückkehr bereitstellen.
Animierte Seitenübergänge
Alternative Versionen der verschiedenen Navigationsmethoden werden mit einem zweiten booleschen Argument bereitgestellt, das Sie auf true festlegen, wenn der Seitenübergang eine Animation beinhalten soll:
Die Standardmethoden für die Seitennavigation enthalten die Animation jedoch standardmäßig, sodass diese nur für die Navigation zu einer bestimmten Seite beim Start (wie am Ende dieses Kapitels erläutert) oder bei der Bereitstellung Ihrer eigenen Eingangsanimation (wie in Kapitel 22, „Animation“, erläutert) nützlich sind.
Visuelle und funktionelle Variationen
NavigationPage umfasst zwei Eigenschaften, die Sie festlegen können, wenn Sie die Klasse in Ihrer App-Methode instanziieren:
NavigationPage umfasst außerdem vier angefügte bindbare Eigenschaften, die sich auf die spezifische Seite auswirken, für die sie festgelegt wurden:
SetHasBackButtonundGetHasBackButtonSetHasNavigationBarundGetHasNavigationBarSetBackButtonTitleundGetBackButtonTitlefunktionieren nur unter iOSSetTitleIconundGetTitleIconfunktionieren nur unter iOS und Android
Untersuchen der Mechanismen
Die Methoden für die Seitennavigation sind alle asynchron und sollten mit await verwendet werden. Der Abschluss zeigt nicht an, dass die Seitennavigation abgeschlossen wurde, sondern nur, dass es sicher ist, den Seitennavigationsstapel zu untersuchen.
Wenn von einer Seite zu einer anderen navigiert wird, erhält die erste Seite in der Regel einen Aufruf ihrer OnDisappearing-Methode, und die zweite Seite erhält einen Aufruf ihrer OnAppearing-Methode. Ähnlich erhält, wenn von einer Seite zu einer anderen Seite zurückgewechselt wird, die erste Seite einen Aufruf ihrer OnDisappearing-Methode, und die zweite Seite erhält in der Regel einen Aufruf ihrer OnAppearing-Methode. Die Reihenfolge dieser Aufrufe (und der Abschluss der asynchronen Methoden, die die Navigation aufruft) ist plattformabhängig. Die Verwendung des Worts „in der Regel“ in den beiden voranstehenden Aussagen ist der modalen Seitennavigation von Android geschuldet, wo es diese Methodenaufrufe nicht gibt.
Auch weisen Aufrufe der Methoden OnAppearing und OnDisappearing nicht notwendigerweise auf Seitennavigation hin.
Die INavigation-Schnittstelle umfasst zwei Sammlungseigenschaften, die es Ihnen gestatten, den Navigationsstapel zu untersuchen:
NavigationStackvom TypIReadOnlyList<Page>für den Stapel ohne Modus.ModalStackvom TypIReadOnlyList<Page>für den modalen Stapel.
Am sichersten ist es, aus der Navigation-Eigenschaft der NavigationPage auf diese Stapel zuzugreifen (bei der es sich um die MainPage-Eigenschaft der App-Klasse handelt sollte). Diese Stapel lassen sich nur sicher untersuchen, nachdem die asynchronen Methoden für die Seitennavigation abgeschlossen wurden. Die CurrentPage-Eigenschaft der NavigationPage gibt nicht die aktuelle Seite an, wenn die aktuelle Seite eine modale Seite ist, gibt aber stattdessen die letzte Seite ohne Modus an.
Im SinglePageNavigation-Beispiel können Sie die Seitennavigation und die Stapel sowie die gültigen Typen von Seitennavigation untersuchen:
- Eine Seite ohne Modus kann zu einer anderen Seite ohne Modus oder einen modalen Seite navigieren.
- Eine modale Seite kann nur zu einer anderen modalen Seite navigieren.
Erzwingen der Modalität
Eine Anwendung verwendet eine modale Seite, wenn es notwendig ist, Informationen vom Benutzer zu erhalten. Der Benutzer sollte daran gehindert werden, zur vorherigen Seite zurückzukehren, bis diese Informationen bereitgestellt wurden. Unter iOS ist es einfach, eine Schaltfläche Zurück bereitzustellen und diese nur zu aktivieren, wenn der Benutzer mit der Seite fertig ist. Bei Android- und Windows Phone-Geräten sollte die Anwendung jedoch die OnBackButtonPressed -Methode überschreiben und zurückgeben true , wenn das Programm die Schaltfläche "Zurück " selbst verarbeitet hat, wie im ModalEnforcement-Beispiel veranschaulicht.
Im MvvmEnforcement-Beispiel wird veranschaulicht, wie dies in einem MVVM-Szenario funktioniert.
Navigationsvariationen
Wenn man mehrmals zu einer bestimmten modalen Seite navigieren kann, sollte sie die Informationen behalten, damit der Benutzer die Informationen bearbeiten kann, anstatt sie erneut eingeben zu müssen. Dies können Sie erzielen, indem Sie die spezifische Instanz der modalen Seite beibehalten, doch ein besserer Ansatz (insbesondere unter iOS) besteht in der Erhaltung der Informationen in einem Ansichtsmodell.
Erstellen eines Navigationsmenüs
Das ViewGalleryType-Beispiel veranschaulicht die Verwendung einer TableView zum Auflisten von Menüelementen. Jedes Element ist einem Type-Objekt für eine bestimmte Seite zugeordnet. Wenn dieses Element ausgewählt wird, instanziiert das Programm die Seite und navigiert dorthin.
Das ViewGalleryInst-Beispiel unterscheidet sich geringfügig dahingehend, dass das Menü anstelle von Typen Instanzen jeder Seite enthält. Dies hilft dabei, die Informationen von jeder Seite zu erhalten, aber alle Seiten müssen beim Programmstart instanziiert werden.
Bearbeiten des Navigationsstapels
StackManipulation veranschaulicht mehrere Funktionen, die von INavigation definiert werden, mit denen Sie den Navigationsstapel auf strukturierte Weise bearbeiten können:
RemovePageInsertPageBeforePopToRootAsyncundPopToRootAsyncmit optionaler Animation.
Dynamische Seitengenerierung
Das BuildAPage-Beispiel veranschaulicht das Erstellen einer Seite zur Laufzeit, basierend auf Benutzereingaben.
Datenübertragungsmuster
Es ist häufig erforderlich, Daten zwischen Seiten gemeinsam zu nutzen, um Daten auf eine navigierte Seite zu übertragen und für eine Seite Daten an die Seite zurückzugeben, die sie aufgerufen hat. Es gibt mehrere Methoden, um dies zu erreichen.
Konstruktorargumente
Beim Navigieren zu einer neuen Seite ist es möglich, die Seitenklasse (Page) mit einem Konstruktorargument zu instanziieren, das es der Seite ermöglicht, sich selbst zu initialisieren. Dies wird im Beispiel SchoolAndStudents-Beispiel veranschaulicht. Es ist auch möglich, den BindingContext der navigierten Seite den von der Seite festlegen zu lassen, von der aus die Navigation erfolgt ist.
Eigenschaften und Methodenaufrufe
Die verbleibenden Datenübertragungsbeispiele untersuchen das Problem der Übergabe von Informationen zwischen Seiten, wenn eine Seite zu einer anderen Seite navigiert und zurück. In diesen Erläuterungen wird von der Startseite zur Infoseite navigiert, und es müssen initialisierte Informationen an die Infoseite übertragen werden. Die Infoseite ruft zusätzliche Informationen vom Benutzer ab und überträgt die Informationen an die Startseite.
Die Startseite kann problemlos auf öffentliche Methoden und Eigenschaften auf der Infoseite zugreifen, sobald sie diese Seite instanziiert hat. Die Infoseite kann auch auf öffentliche Methoden und Eigenschaften auf der Startseite zugreifen, doch die Auswahl eines geeigneten Zeitpunkts dafür kann schwierig sein. Das DateTransfer1-Beispiel führt dies in seiner OnDisappearing-Außerkraftsetzung aus. Ein Nachteil ist, dass die Infoseite den Typ der Startseite kennen muss.
MessagingCenter
Die Xamarin.FormsMessagingCenter -Klasse bietet eine weitere Möglichkeit für zwei Seiten, miteinander zu kommunizieren. Nachrichten werden durch eine Textzeichenfolge identifiziert und können von einem beliebigen Objekt begleitet werden.
Ein Programm, das Nachrichten eines bestimmten Typs empfangen möchte, muss sie mithilfe von MessagingCenter.Subscribe abonnieren und eine Rückruffunktion angeben. Später kann es das Abonnement durch Aufrufen von MessagingCenter.Unsubscribe kündigen. Die Rückruffunktion empfängt alle gesendeten Nachrichten des angegebenen Typs mit dem angegebenen Namen, die über die Send-Methode gesendet werden.
Das DateTransfer2-Programm veranschaulicht, wie Daten mithilfe des Messaging Centers übertragen werden, aber auch dies setzt voraus, dass die Infoseite den Typ der Startseite kennt.
Ereignisse
Das Ereignis ist ein herkömmlicher Ansatz für eine Klasse, um Informationen an eine andere Klasse zu senden, ohne den Typ der Klasse zu kennen. Im DateTransfer3-Beispiel definiert die Info-Klasse ein Ereignis, das sie auslöst, wenn die Informationen bereit sind. Es gibt jedoch keinen geeigneten Ort für die Startseite, um den Ereignishandler zu trennen.
Der App-Klassenvermittler
Das DateTransfer4-Beispiel zeigt, wie Sie auf Eigenschaften zugreifen, die in der App-Klasse sowohl von der Startseite als auch von der Infoseite definiert sind. Dies ist eine gute Lösung, aber im nächsten Abschnitt wird etwas besseres beschrieben.
Wechseln zu einem ViewModel
Wenn Sie ein ViewModel für die Informationen verwenden, können die Startseite und die Infoseite die Instanz der Informationsklasse gemeinsam nutzen. Dies wird im DateTransfer5-Beispiel demonstriert.
Speichern und Wiederherstellen des Seitenzustands
Der App-Klassenvermittler oder der ViewModel-Ansatz sind ideal, wenn die Anwendung Informationen speichern muss, wenn das Programm in den Standbymodus wechselt, während die Infoseite aktiv ist. Dies wird im DateTransfer6-Beispiel veranschaulicht.
Speichern und Wiederherstellen des Navigationsstapels
Im Allgemeinen sollte ein mehrseitiges Programm, das in den Standbymodus wechselt, zur selben Seite navigieren, wenn es wiederhergestellt wird. Dies bedeutet, dass ein solches Programm den Inhalt des Navigationsstapels speichern sollte. In diesem Abschnitt wird gezeigt, wie sich dieser Prozess in einer zu diesem Zweck entworfenen Klasse automatisieren lässt. Diese Klasse ruft auch die einzelnen Seiten auf, damit diese Ihren Seitenzustand speichern und wiederherstellen können.
Die Bibliothek Xamarin.FormsBook.Toolkit definiert eine Schnittstelle namens IPersistantPage, die Klassen implementieren können, um Elemente im Wörterbuch Properties zu speichern und wiederherzustellen.
Die MultiPageRestorableApp-Klasse in der Bibliothek Xamarin.FormsBook.Toolkit ist von Application abgeleitet. Sie können dann Ihre App-Klasse von MultiPageRestorableApp ableiten und einige Verwaltungsaufgaben ausführen.
Das StackRestoreDemo-Beispiel veranschaulicht die Verwendung von MultiPageRestorableApp.
Fast schon eine realitätsnahe App
Das Notetaker-Beispiel verwendet auch MultiPageRestorableApp und ermöglicht die Eingabe und Bearbeitung von Notizen, die im Properties-Wörterbuch gespeichert werden.