indispensables pour adapter les bindings, les convertisseurs sont des outils de base de XAML depuis son invention dans WPF. Et aujourd’hui avec MAUI qu’en est-il ?
Convertisseurs et bindings
Les liaisons de données transfèrent généralement des données d'une propriété source vers une propriété de destination et, dans certains cas, de la propriété de destination vers la propriété source. Ce transfert est facile lorsque les propriétés source et destination sont du même type, ou lorsqu'un type peut être converti en l'autre type par une conversion implicite, comme un int vers un string par exemple. Lorsque ce n'est pas le cas, un convertisseur doit être affecté au Binding. Il joue alors le rôle d’adaptateur pour les données qui transitent dans un sens comme dans l’autre par le Binding.
Supposons qu’on veuille définir un binding dans lequel la propriété source est de type entier (int) et que la propriété de destination soit booléenne (bool). Ici il n’existe pas de conversion implicite, .NET ne sait pas comment passer de l’un à l’autre. On pourrait supposer qu’il puisse le faire dans un sens (zéro = false, autre chose = true) mais ce serait déjà s’immiscer dans la logique métier de votre application qui a peut-être (et même certainement) des besoins plus spécifiques. Toutefois pour l’exemple nous resterons sur une conversion ultra simple, à savoir que le Binding produise un valeur fausse (false) lorsque l'entier source est égal à zéro et vrai (true) dans les autres cas. Dans la réalité de vos apps il est évident que vous pourrez mettre en place des conversions plus sophistiquées correspondant aux besoins de l’app.
Implémentation
L’implémentation d’un convertisseur est très simple, on peut le faire avec une classe qui implémente l'interface IValueConverter .
Je renvoie le lecteur intéressé à la petite dizaine d’articles que j’ai déjà publiés et qui parlent directement ou indirectement de cette interface (voir IValueConverter sur Dot.Blog).
Comme presque tous les autres concepts Xamarin.Forms, les convertisseurs peuvent être réutilisés dans .NET MAUI sans nécessiter de modification de code.
Voici le code Xamarin.Forms pour notre convertisseur example :
using System;
using System.Globalization;
using Xamarin.Forms;
namespace Converters
{
public class IntToBoolConverter : IValueConverter
{
public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
{
return (int)value != 0;
}
public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
{
return (bool)value ? 1 : 0;
}
}
}
On voit que ce code est “complet” puisqu’il définit les deux sens de la conversion. Très souvent on ne définit que le Convert() car les convertisseurs servent à adapter des données du ViewModel pour la Vue. Mais lorsque la Vue peut interagir à son tour il convient de fournir la conversion inverse. Imaginons un check button qui fonctionne avec une propriété “checked” de type bool, et un ViewModel offrant une valeur 0 ou 1, il faudra convertir le numérique en bool dans le sens ViewModel vers Vue, et quand l’utilisateur cliquera le check button il faudra convertir le bool en entier 0 ou 1.
Si les conversions inverses sont rarement codées c’est aussi parce que les mécanismes ne sont pas toujours réversibles. Même dans notre exemple ultra simple si la conversion 0 = false, autre = true semble très pertinente, la conversion inverse peut poser des problèmes. En effet si le ViewModel expose une valeur entière c’est certainement qu’elle peut prendre d’autres valeurs que 0 ou 1. En interprétant 0 comme false et autre chose comme true, on ne prend guère de risques. Mais en forçant 1 pour true dans l’autre sens on écrase toutes les subtilités qu’un entier peut contenir. Cela marque soit une limite du convertisseur qui ne peut marcher avec fiabilité que dans un sens, c’est souvent le cas pour l’adaptation de données vers l’affichage, soit une mauvaise conception du ViewModel (qui devrait proposer directement une valeur de type bool plutôt qu’un entier par exemple).
Bref le sujet des convertisseurs n’est pas aussi simple qu’il y parait et cela peut demander un peu de réflexion. On peut aussi se poser la question de savoir si aujourd’hui les convertisseurs sont réellement utiles alors qu’en travaillant en MVVM on matérialise une classe spéciale, le ViewModel, dont le but est justement d’adapter les données du Model pour la Vue ! Dans un tel cadre les convertisseurs semblent moins essentiels qu’aux premiers jours de WPF… Mais cela dépend des cas, et il vous faudra vous demander quand adapter une donnée dans le ViewModel et quand l’adapter via un convertisseur…
Néanmoins, ces interrogations quasi métaphysiques ne doivent pas nous faire oublier le but de l’article que vous lisez : le passage des convertisseurs Xamarin.Forms vers MAUI.
Et si je me suis permis ces digressions c’est comme d’habitude parce que la solution est évidente, le code reste rigoureusement le même sous MAUI ! Sauf les espaces de noms comme vous pouvez le constater avec l’extrait suivant (en MAUI) :
using Microsoft.Maui.Controls;
using System;
using System.Globalization;
namespace Converters
{
public class IntToBoolConverter : IValueConverter
{
public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
{
return (int)value != 0;
}
public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
{
return (bool)value ? 1 : 0;
}
}
}
Au lieu d’un using Xamarin.Forms ont trouvera plus naturellement un using Microsoft.Maui.Controls. C’est tout… Intellisense ou Resharper vous le proposerons si vous l’oubliez…
Conclusion
J’aborderai d’autres passages plus ou moins évidents entre l’écriture Xamarin.Forms et MAUI dans des papiers à venir. Mais comme on peut le constater, les noms changent, tout évolue, mais C#/XAML restent eux-mêmes et le passage de .NET Framework à .NET Core ne pose pas de problème insurmontables… Plus moderne que MAUI et .NET Core c’est dur à trouver. Et pourtant à la différence des langages pour midinettes qui n’arrêtent pas de changer, nous, nous thésaurisons depuis des années notre savoir-faire C#/XAML/.NET … Cela donne à réfléchir. Car tout ce temps que nous ne perdons pas à réapprendre des langages et des environnements nouveaux (qui n’apportent pas grand chose) nous pouvons le passer à concevoir de belles apps ou aller faire du ski (ou de la luge pour les moins téméraires !) 
Stay Tuned !