Résumé du chapitre 24. Navigation dans les pages
Remarque
Ce livre a été publié au printemps 2016 et n’a pas été mis à jour depuis. Il y a beaucoup dans le livre qui reste précieux, mais certains documents sont obsolètes, et certains sujets ne sont plus entièrement corrects ou complets.
De nombreuses applications se composent de plusieurs pages parmi lesquelles l’utilisateur navigue. L’application dispose toujours d’une page principale ou d’une page d’accueil, et à partir de là, l’utilisateur accède à d’autres pages, qui sont conservées dans une pile pour la navigation vers l’arrière. Des options de navigation supplémentaires sont abordées dans le chapitre 25. Variétés de pages.
Pages modales et pages sans mode
VisualElement définit une Navigation propriété de type INavigation, qui inclut les deux méthodes suivantes pour accéder à une nouvelle page :
Les deux méthodes acceptent une Page instance en tant qu’argument et retournent un Task objet. Les deux méthodes suivantes remontent à la page précédente :
Si l’interface utilisateur a son propre bouton Précédent (comme les téléphones Android et Windows le font), il n’est pas nécessaire que l’application appelle ces méthodes.
Bien que ces méthodes soient disponibles à partir de n’importe quel VisualElement, elles sont généralement appelées à partir de la Navigation propriété de l’instance actuelle Page .
Les applications utilisent généralement des pages modales lorsque l’utilisateur est tenu de fournir des informations sur la page avant de revenir à la page précédente. Les pages qui ne sont pas modales sont parfois appelées sans mode ou hiérarchique. Rien dans la page elle-même la distingue comme modale ou sans mode ; elle est régie à la place par la méthode utilisée pour y accéder. Pour travailler sur toutes les plateformes, une page modale doit fournir sa propre interface utilisateur pour revenir à la page précédente.
L’exemple ModelessAndModal vous permet d’explorer la différence entre les pages sans mode et modales. Toute application qui utilise la navigation de page doit passer sa page d’accueil au NavigationPage constructeur, généralement dans la classe du App programme. Un bonus est que vous n’avez plus besoin de définir une Padding sur la page pour iOS.
Vous découvrirez que pour les pages sans mode, la propriété de la Title page s’affiche. Les plateformes iOS, Android et Windows tablet et desktop fournissent tous un élément d’interface utilisateur pour revenir à la page précédente. Bien sûr, les appareils Android et Windows Phone ont un bouton Précédent standard pour revenir en arrière.
Pour les pages modales, la page Title n’est pas affichée et aucun élément d’interface utilisateur n’est fourni pour revenir à la page précédente. Bien que vous puissiez utiliser le bouton Précédent standard Android et Windows Phone pour revenir à la page précédente, la page modale sur les autres plateformes doit fournir son propre mécanisme pour revenir en arrière.
Transitions de page animées
Les autres versions des différentes méthodes de navigation sont fournies avec un deuxième argument booléen que vous définissez true si vous souhaitez que la transition de page inclue une animation :
Toutefois, les méthodes de navigation de page standard incluent l’animation par défaut. Elles ne sont donc utiles que pour accéder à une page particulière au démarrage (comme indiqué vers la fin de ce chapitre) ou lors de la fourniture de votre propre animation d’entrée (comme indiqué dans chapitre22). Animation).
Variations visuelles et fonctionnelles
NavigationPage inclut deux propriétés que vous pouvez définir lorsque vous instanciez la classe dans votre App méthode :
NavigationPage inclut également quatre propriétés pouvant être liées qui affectent la page particulière sur laquelle elles sont définies :
SetHasBackButtonetGetHasBackButtonSetHasNavigationBaretGetHasNavigationBarSetBackButtonTitleetGetBackButtonTitlefonctionnent uniquement sur iOSSetTitleIconetGetTitleIcontravailler sur iOS et Android uniquement
Exploration de la mécanique
Les méthodes de navigation de page sont toutes asynchrones et doivent être utilisées avec await. La saisie semi-automatique n’indique pas que la navigation de page est terminée, mais uniquement qu’il est sûr d’examiner la pile de navigation de page.
Lorsqu’une page accède à une autre, la première page obtient généralement un appel à sa OnDisappearing méthode et la deuxième page obtient un appel à sa OnAppearing méthode. De même, lorsqu’une page revient à une autre, la première page obtient un appel à sa OnDisappearing méthode et la deuxième page obtient généralement un appel à sa OnAppearing méthode. L’ordre de ces appels (et l’achèvement des méthodes asynchrones qui appellent la navigation) dépend de la plateforme. L’utilisation du mot « généralement » dans les deux instructions précédentes est due à la navigation de page modale Android, dans laquelle ces appels de méthode ne se produisent pas.
En outre, les appels aux méthodes et OnDisappearing aux OnAppearing méthodes n’indiquent pas nécessairement la navigation de page.
L’interface INavigation inclut deux propriétés de collection qui vous permettent d’examiner la pile de navigation :
NavigationStackde typeIReadOnlyList<Page>pour la pile sans modeModalStackde typeIReadOnlyList<Page>pour la pile modale
Il est plus sûr d’accéder à ces piles à partir de la Navigation propriété du NavigationPage (qui doit être la propriété de MainPage la App classe). Il n’est sûr d’examiner ces piles qu’une fois les méthodes de navigation de page asynchrones terminées. La CurrentPage propriété du fichier NavigationPage n’indique pas la page active si la page active est une page modale, mais indique à la place la dernière page sans mode.
L’exemple SinglePageNavigation vous permet d’explorer la navigation de page et les piles, ainsi que les types juridiques de navigation de page :
- Une page sans mode peut accéder à une autre page sans mode ou à une page modale
- Une page modale ne peut accéder qu’à une autre page modale
Application de la modalité
Une application utilise une page modale lorsqu’il est nécessaire d’obtenir des informations de l’utilisateur. L’utilisateur doit être interdit de revenir à la page précédente jusqu’à ce que ces informations soient fournies. Sur iOS, il est facile de fournir un bouton Précédent et de l’activer uniquement lorsque l’utilisateur a terminé avec la page. Toutefois, pour les appareils Android et Windows Phone, l’application doit remplacer la OnBackButtonPressed méthode et retourner true si le programme a géré le bouton Précédent lui-même, comme illustré dans l’exemple ModalEnforcement .
L’exemple MvvmEnforcement montre comment cela fonctionne dans un scénario MVVM.
Variantes de navigation
Si une page modale particulière peut être parcourue plusieurs fois, elle doit conserver des informations afin que l’utilisateur puisse modifier les informations plutôt que de le taper à nouveau. Vous pouvez gérer cela en conservant l’instance particulière de la page modale, mais une meilleure approche (en particulier sur iOS) préserve les informations dans un modèle d’affichage.
Création d’un menu de navigation
L’exemple ViewGalleryType illustre l’utilisation d’éléments TableView de menu de liste. Chaque élément est associé à un Type objet pour une page particulière. Lorsque cet élément est sélectionné, le programme instancie la page et y accède.
L’exemple ViewGalleryInst est un peu différent dans le fait que le menu contient des instances de chaque page plutôt que des types. Cela permet de conserver les informations de chaque page, mais toutes les pages doivent être instanciées au démarrage du programme.
Manipulation de la pile de navigation
StackManipulation illustre plusieurs fonctions définies par INavigation ce qui vous permettent de manipuler la pile de navigation de manière structurée :
RemovePageInsertPageBeforePopToRootAsyncetPopToRootAsyncavec animation facultative
Génération de page dynamique
L’exemple BuildAPage illustre la construction d’une page au moment de l’exécution en fonction de l’entrée utilisateur.
Modèles de transfert de données
Il est souvent nécessaire de partager des données entre les pages pour transférer des données vers une page parcourue et pour qu’une page retourne des données à la page qui l’a appelée. Il existe plusieurs techniques pour ce faire.
Arguments du constructeur
Lorsque vous accédez à une nouvelle page, il est possible d’instancier la classe de page avec un argument de constructeur qui permet à la page d’initialiser elle-même. L’exemple SchoolAndStudents illustre cela. Il est également possible que la page de navigation soit définie BindingContext par la page qui y accède.
Appels de propriétés et de méthode
Les exemples de transfert de données restants explorent le problème de transmission d’informations entre les pages lorsqu’une page accède à une autre page et à un autre. Dans ces discussions, la page d’accueil accède à la page d’informations et doit transférer des informations initialisées vers la page d’informations. La page d’informations obtient des informations supplémentaires auprès de l’utilisateur et transfère les informations à la page d’accueil.
La page d’accueil peut facilement accéder aux méthodes et propriétés publiques dans la page d’informations dès qu’elle instancie cette page. La page d’informations peut également accéder aux méthodes et propriétés publiques dans la page d’accueil , mais le choix d’un bon moment pour cela peut être difficile. L’exemple DateTransfer1 effectue cette opération dans son OnDisappearing remplacement. L’un des inconvénients est que la page d’informations doit connaître le type de la page d’accueil .
MessagingCenter
La Xamarin.FormsMessagingCenter classe fournit un autre moyen pour que deux pages communiquent entre elles. Les messages sont identifiés par une chaîne de texte et peuvent être accompagnés par n’importe quel objet.
Un programme qui souhaite recevoir des messages d’un type particulier doit s’abonner à eux à l’aide MessagingCenter.Subscribe et spécifier une fonction de rappel. Plus tard, il peut se désabonner en appelant MessagingCenter.Unsubscribe. La fonction de rappel reçoit tout message envoyé à partir du type spécifié avec le nom spécifié envoyé par le biais de la Send méthode.
Le programme DateTransfer2 montre comment transférer des données à l’aide du centre de messagerie, mais là encore, cela nécessite que la page d’informations connaisse le type de la page d’accueil .
Événements
L’événement est une approche chronologique pour une classe pour envoyer des informations à une autre classe sans connaître le type de cette classe. Dans l’exemple DateTransfer3, la classe d’informations définit un événement qu’il déclenche lorsque les informations sont prêtes. Toutefois, il n’existe aucun endroit pratique pour la page d’accueil pour détacher le gestionnaire d’événements.
Intermédiaire de classe App
L’exemple DateTransfer4 montre comment accéder aux propriétés définies dans la App classe par la page d’accueil et la page d’informations. Il s’agit d’une bonne solution, mais la section suivante décrit quelque chose de mieux.
Passage à un ViewModel
L’utilisation d’un ViewModel pour les informations permet à la page d’accueil et à la page d’informations de partager l’instance de la classe d’informations. Ceci est illustré dans l’exemple DateTransfer5 .
Enregistrement et restauration de l’état de la page
L’intermédiaire App de classe ou l’approche ViewModel est idéale lorsque l’application doit enregistrer des informations si le programme est en veille pendant que la page d’informations est active. L’exemple DateTransfer6 illustre cela.
Enregistrement et restauration de la pile de navigation
Dans le cas général, un programme multipage qui passe en veille doit accéder à la même page lorsqu’il est restauré. Cela signifie qu’un tel programme doit enregistrer le contenu de la pile de navigation. Cette section montre comment automatiser ce processus dans une classe conçue à cet effet. Cette classe appelle également les pages individuelles pour leur permettre d’enregistrer et de restaurer leur état de page.
La Xamarin.Formsbibliothèque Book.Toolkit définit une interface nommée IPersistantPage que les classes peuvent implémenter pour enregistrer et restaurer des éléments dans le Properties dictionnaire.
La MultiPageRestorableApp classe de la Xamarin.Formsbibliothèque Book.Toolkit dérive de Application. Vous pouvez ensuite dériver votre App classe et MultiPageRestorableApp effectuer un entretien ménager.
StackRestoreDemo illustre l’utilisation de MultiPageRestorableApp.
Quelque chose comme une application réelle
L’exemple NoteTaker utilise MultiPageRestorableApp également et autorise l’entrée et la modification de notes enregistrées dans le Properties dictionnaire.