Le Shell permet de passer des paramètres lors de la navigation comme je l’ai déjà présenté, mais il existe une seconde méthode plus intéressante pour récupérer ces paramètres…
Le Shell, tout un roman
Le Shell est simple mais complet, la navigation est un besoin simple mais avec tellement de variantes que cela en devient un sujet complexe. Pour vous aider à y voir clair j’ai déjà écrit plusieurs articles et une vidéo sur ce sujet, je vous invite à les lire si d’aventure ce n’est pas déjà fait :
Une fois que vous aurez absorbé toute cette saine et édifiante littérature je pense que le Shell n’aura plus beaucoup de secrets pour vous…
Et pourtant !
Les paramètres de navigation
Il restera au moins une chose qui n’a pas été présentée dans la liste ci-dessus, une chose qui facilite la vie lors du passage des paramètres de navigation. Cette astuce concerne la réception des données transmises.
Dans la Partie 4 (voir liste ci-dessus) j’ai abordé le passage de paramètres de navigation, des données si vous préférez (le code d’un article, d’un client, le numéro d’une facture…). Cela se fait durant l’appel à la navigation par l’utilisation de paramètres comme on le fait pour une URI standard. Et pour recevoir les données il suffit dans l;a page réceptrice de marquer avec l’attribut QueryProperty les éléments qu’on s’attend à recevoir puis de les décoder.
Cette façon de faire marche parfaitement bien mais elle oblige à marquer chaque paramètre avec l’attribut indiqué. Personnellement j’aime beaucoup ce côté verbeux et surtout déclaratif. La page s’attend à recevoir le paramètre “Id”, le paramètre “Value” et puis c’est tout (simple exemple). On le voit en lisant le code. Si demain on veut envoyer un paramètre de plus ou de moins on verra immédiatement ce qui est en trop ou en moins dans cette partie déclarative.
Donc je suis plutôt pour cette approche déclarative qui rend les intentions visibles.
Mais j’avoue que ce n’est pas ultra pratique.
Chez Microsoft on y a pensé aussi. Sans remettre en question le mécanisme en place, un autre procédé a été ajouté…
L’interface IQueryAttributable
IQueryAttributable est une interface Xamarin.Forms qui spécifie qu'une classe d'implémentation doit implémenter une méthode nommée ApplyQueryAttributes . Cette méthode a un argument de requête , de type IDictionary <string, string> , qui contient toutes les données transmises pendant la navigation. Chaque clé du dictionnaire est un identifiant de paramètre de requête, sa valeur étant la valeur du paramètre de requête.
Par exemple, le code suivant montre une classe ViewModel qui implémente IQueryAttributable :
public class MyViewModel : IQueryAttributable
{
public void ApplyQueryAttributes(IDictionary query)
{
var name = HttpUtility.UrlDecode(query["name"]);
...
}
...
}
Dans cet exemple, la méthode ApplyQueryAttributes récupère la valeur du paramètre de requête de nom à partir de l'URI dans l' appel de méthode GoToAsync . Ensuite, toute logique personnalisée peut être exécutée. Notez que les valeurs des paramètres de requête reçues via l' interface IQueryAttributable ne sont pas automatiquement décodées (il faut utiliser un décodeur comme HttpUtility.UrlDecode).
Il est également possible de traiter plusieurs éléments de données de navigation à la fois :
public class MyViewModel : IQueryAttributable
{
public void ApplyQueryAttributes(IDictionary query)
{
var name = HttpUtility.UrlDecode(query["name"]);
var location = HttpUtility.UrlDecode(query["location"]);
...
}
...
}
Dans cet exemple, la méthode ApplyQueryAttributes récupère la valeur des paramètres de requête (“name” et “location”) à partir de l'URI créée dans l'appel de la méthode GoToAsync .
L'avantage d'utiliser cette approche est que les données de navigation peuvent être traitées à l'aide d'une seule méthode, ce qui peut être utile lorsque vous avez plusieurs éléments de données de navigation qui nécessitent un traitement dans leur ensemble. Comparez cela à l' approche QueryPropertyAttribute , selon les cas de figure cette façon de faire peut s’avérer plus élégante il est vrai, voire indispensable (traitement d’un ensemble de paramètres comme un tout). Choisir la visibilité des intentions ou la centralisation du traitement, à chacun de voir en fonction du contexte !
Conclusion
Le Shell est un élément central dans une App, parce que la navigation est un sujet central. Il est normal qu’un Shell complet devienne un peu complexe car il doit se plier à maintes contraintes pour satisfaire tout le monde. L’équipe Xamarin.Forms a réussi à faire en sorte que malgré tout le Shell ne soit pas trop ardu, trop difficile à comprendre et à mettre en place. Mais il y a des choses à savoir… Et l’astuce du jour en fait partie !
Ainsi, je ne jure pas qu’il n’y aura pas encore, un jour, un autre papier sur le Shell…
Stay Tuned !