Nous voici arrivé à la fin de ce cycle de quatre articles sur le Shell, il y en aura d’autres assurément, mais les bases sont jetées et vous pouvez utilisez cette nouvelle possibilité en toute tranquillité car maintenant vous savez ! Mais il reste une chose à connaître dans les bases indispensables, le passage de données d’une page à une autre lors de la navigation… Suivez-moi et bouclons ensemble ce tour d’horizon…
Résumé
La partie 1 a abordé la présentation du Shell et les premiers rudiments de son utilisation.
La partie 2 nous a permis d’en savoir plus sur le menu Flyout et les onglets secondaires.
La partie 3 nous a présenté la notion de Routes et comment s’en servir, même à savoir naviguer hors des chemins battus !
Mais il nous reste un point assez important à voir : comment passer des données d’une page à l’autre lors de la navigation ?
Le Besoin
Je ne vais pas m’étendre des heures sur le besoin vous le connaissez certainement déjà : lorsqu’on navigue d’une page “maître” (liste par exemple) vers une page “détail” (fiche complète de l’objet concerné) il faut par exemple que la page Détail puisse récupérer l’objet Maître, ou sa clé pour aller le chercher dans une base de données locale ou distante. C’est un cas cas classique. Mais il en existe bien d’autres où échanger des données lors d’une navigation est essentiel. Ne piétinons donc pas sur cette route bien connue de tous et avançons vers la solution…
Un cadre simplifié
Pour l’instant nous allons rester dans le cadre simplifié d’une App n’utilisant pas MVVM. C’est suffisant rare pour le noter car même mes plus simples exemples utilisent MVVM, pour le principe et vous habituer à cette stratégie. Mais le Shell peut comporter des difficultés propres qu’il est préférable d’aborder de la façon la plus directe en simplifiant à l’extrême le code “d’emballage” de la démo.
Mais vous n’y coupera pas ! Cette série en 4 articles n’est qu’une “capsule” de base. Il y aura à coup sûr un 5ème article pour présenter la mise en œuvre de tous les concepts vus ici dans le cadre plus professionnel de MVVM.
Le passage des données fait partie de ces choses où l’ajout de MVVM complique un peu le dessin, je réserve donc cela pour plus tard. De même que nous n’avons pas fait le tour de toutes les possibilités du Shell, aussi bien dans sa définition XAML que dans les façons de l’embellir visuellement (présence de boutons ou autres dans le Flyout, entête, etc…).
Bref il y a encore de la place pour de nouveaux articles plus pointus qui ne reviendront pas sur les bases expliquées ici et dans les articles précédents.
Passer des données
Avant de passer des données, passons-nous le mot : il est préférable d’avoir lu les articles précédents pour comprendre où nous en sommes… Car ici je ne vais qu’améliorer le programme déjà écrit et ses diverses modifications ajoutée au fil du temps. Il est encore temps d’aller jeter un œil aux partie 1, 2 et 3 (lien en haut de cette page).
Pour faire simple et ne pas partir en digression qui vont vous égarer il n’y a donc pas de MVVM pour l’instant, de même il n’y aura pas de liste ni de base de données… La donnée que nous allons passer d’une page à une autre sera une simple chaîne de caractères que l’utilisateur pourra taper sur la page principale.
je ne veux pas vous faire injure en vous montrant un simple Entry… mais disons que cela permet de fixer le décor alors voici le code XAML de la MainPage :
On notera que l’absence de MVVM oblige à faire des choses affreuses comme donner un x:Name au Entry. Pouah ! Mais c’est pour la bonne cause de la simplification de l’exemple…
Le bouton qui se trouve en dessous avait déjà été placé dans un article précédent, nous allons conserver cette navigation là et recevrons donc “TheData” dans la page visée…qui se trouve être sur la route "//Utilitaires/Suppléments/Note3" sachant que Note3 dans notre schéma paresseux est un repiquage de la même Vue secondaire “SecondaryPage.xaml”. Dans la réalité il s’agira bien entendu d’une page ayant plus de sens, tout comme la donnée passée et son exploitation…
Passons la donnée
Pour l’instant le handler du click du bouton de la MainPage ressemble à cela :
Nous n’allons pas changer grand chose au final mais il faut bien passer la chaîne…
La syntaxe adoptée par Xamarin est classique désormais, on la retrouve dans des frameworks MVVM d’ailleurs, c’est la syntaxe “web”. Voici comment je vais passer le contenu du Entry s’appelant TheData :
Dans cette logique pour transférer plusieurs paramètres il suffit d’ajouter un “&” suivi du nom du nouveau paramètres et sa valeur, etc, comme une URL donc.
Tout ce qui sera tapé dans le Entry sera désormais passé à la page réceptrice. Simple et efficace.
Le nom du paramètre ? Ici je n’ai pas fait preuve de grande imagination mais notre App n’a pas de contexte précis, c’est une démo, alors oui le paramètre s’appelle Entry mais sans que cela n’ait le moindre rapport avec la classe Entry. Juste pas d’imagination c’est tout 
Recevoir la donnée
Alors je parle au singulier dans ce titrage comme dans le précédent car ici on passe une seule donnée, mais si vous passez plusieurs données vous recevrez “des données” et pas “la donnée”… Soyons clair jusqu’au bout !
Bien entendu dans tous ces systèmes de passage de données la tambouille s’opère entre pages… entre Vues donc. Nous savons tous que cela ne peut pas se faire ainsi en MVVM. Mais nous allons continuer à utiliser le code behind malgré tout dans cet exemple. Ce sont les mécanismes de Shell qui compte. Comme exprimé déjà plus haut tout cela me laisse pressentir la nécessité d’un 5ème article (voire une vidéo Dot.Vlog) où l’ensemble sera décliné en MVVM, mais pour l’instant continuons de gérer tout cela de la façon la plus simple.
Donc dans le code behind de la Vue qui va être atteinte (SecondaryPage) je vais ajouter une propriété string mais aussi un Label dans le visuel afin de vérifier que le texte passé par la MainPage est bien arrivé de l’autre côté de la route !
Définir une propriété dans du code behind qui accède directement à un Label n’est vraiment pas le truc le plus propre… ne le faites pas chez vous, seul un professionnel entraîné peut prendre ce genre de risque !
C’est vrai que c’est “crade” mais c’est plus simple donc :
TheData est le nom du Label posé sur la fiche. L’astuce de l’Uri.UnescapeDataString est une habitude en mode web de supprimer les caractère d’échappement éventuellement passés en paramètre. Ici le texte étant tapé par l’utilisateur il n’est pas idiot de se protéger. S’il s’agit de paramètres passés de code à code, il est alors préférable de ne pas dénaturer ce qui est passé et de vérifier qu’on ne passe pas n’importe quoi et comment on se sert de la donnée récupérée.
Cool non ?
Quoi ? Un problème ?
Mais non… Où ça ?
Ah oui…. Vous vous demandez bien comment la donnée passée dans la chaîne de navigation peut atterrir par magie dans notre propriété Data…
Je comprends votre surprise.
Et bien c’est déconcertant mais ça ressemble un peu à MEF – ce qui ne causera qu’aux vieux de la vieille sous WPF donc excusez ce private joke – c’est à dire que ça va se remplir tout seul !
Enfin presque.
Car il faut tout de même ajouter un Attribut à la classe de notre Vue pour qu’elle sache comment décomposer les paramètres de l’URI de navigation et découper tout ça puis ranger les valeurs dans les bonnes propriétés. Ici cela est réglé de la façon suivante :
L’attribut est “QueryProperty”. Le premier paramètre est le nom de al propriété réceptrice de la donnée (“Data”) quant au second paramètre c’est le nom du paramètre dans l’URI. Rappelez vous on passe la donnée par un “….?Entry={xxxx}”. Entry est le nom du paramètre.
On utilise autant d’attributs qu’il faut pour capturer toutes les valeurs transmises.
Visuellement cela donne :
L’image ci-dessus montre la MainPage et sa zone de saisie en cours de frappe. Le clavier de l’émulateur étant resté en Qwerty je n’ai pas mis les accents…
On distingue sous le clavier le bouton noir de navigation. Quand on clique dessus on arrive sur la page secondaire et son label dont le contenu a été rempli automatiquement par le biais de l’attribut :
Et voilà le tour est joué !
Conclusion
Il est clair que tout n’a pas été dit dans cette série de quatre articles dédiés au nouveau Shell des Xamarin.Forms. Notamment ce qui me gêne le plus c’est de vous laisser en plan avec de belles explications mais hors contexte MVVM… Il manque donc un petit bout pour terminer cette série, une mise en application dans une App utilisant MVVM. Ce sera fait prochainement. Promis !
D’ici là surtout :
Stay Tuned !