Dévelopement

Picker pour Enum avec description et localisation sous Xamarin.Forms

Dot.Blog - il y a 4 heures 18 min

Comment permettre la sélection par l’utilisateur d’une valeur appartenant à une énumération ? En créant un Picker personnalisé ! Comment personnaliser les options ? Par des attributs ! Comment rendre tout cela traduisible ? Avec des ressources ! Tout cela vous sera divulgué dans ces deux vidéos de Dot.Vlog !

To pick or not to pick

That is the question…

En effet, les Enum (énumérations C#) sont très pratiques, elles évitent l’utilisation de chaînes de caractères, sont facilement contrôlées par le compilateur, elles se prêtent aisément à tout refactoring ou évolution, bref les Enum c’est génial.

Très souvent les Enum ont un sens pour l’utilisateur dans le cadre de son activité. Etat d’un document, d’un processus industriel, modes de règlements, etc… Il est alors très tentant de vouloir proposer une sélection directe des valeurs possibles.

Hélas aucun contrôle ne permet d’effectuer une telle sélection sur une Enum. Les listes et autres pickers acceptent des sources de données certes, mais sous forme de collections le plus souvent.

Pas de bricolage !

Le bricolage consiste comme on le voit souvent à transformer les valeurs d’une Enum en string puis à les placer dans une List<string> qu’on donnera ensuite en source de données à une ListView ou un Picker ou autre contrôle UI de sélection.

S’il faut refaire cela pour plusieurs Enum dans l’application on commence mal… sans parler qu’il va falloir ajouter du code pour traduire en sens inverse le choix de l’utilisateur, une string donc, en une valeur d’une Enum bien particulière. Ouch !

Pire encore les évolutions des Enum demanderont à modifier le code, sans rien oublier nulle part… sinon gare aux bugs !

Je pourrais continuer tellement les embuches vont s’entasser et transformer une bonne idée en une horreur.

Une solution propre

L’une des meilleurs solutions est d’isoler tous ces traitements et de les confiner dans un contrôle. C’est ça la programmation Objet dont le premier principe est l’Encapsulation !

Mais partir de rien est fastidieux, le contrôle le plus proche et le mieux approprié est le Picker. Mettons ainsi en œuvre le second principe de la programmation Objet : l’Héritage !

Nous verrons même que nous irons jusqu’à détourner le troisième principe qui est le Polymorphisme…

C’est ainsi une solution propre au sens de la programmation objet que je vais vous présenter.

Deux vidéos pour un seul sujet

Le format que j’impose à Dot.Vlog est que chaque vidéo ne doit pas dépasser 30 min et faire moins si possible. 15 à 20 min étant une bonne durée. Et certains sujets débordent de ce format. Ce fut le cas du Visual State Manager (trois vidéos !) et c’est le cas ici. Mais deux vidéos suffiront à couvrir les trois versions améliorées au fur et à mesure du Picker.

Partie 1/2

Lien direct : http://tinyurl.com/y8empbud

Partie 2/2

Lien direct : https://youtu.be/pRWX3CPXDWo

Commentaires

N’hésitez pas visionner ces vidéos directement sur Youtube et à laisser vos commentaires sur la page des vidéos. Les commentaires laissés ici ne sont pas pris en compte par l’algorithme de Youtube.

Abonnez-vous !

Allez sur YouTube et abonnez-vous à la chaîne vous serez prévenus de chaque sortie en priorité !

Profitez-en pour liker, c’est ce qui permet avec les commentaires que la chaîne soit mieux recommandée.

Vous imaginez bien que sur un tel sujet je ne risque pas d’atteindre les 10 millions de vues ni même les 10 millions d’abonnés. Soyons lucides… Cette chaîne ne sera jamais “monétisable”, et cela ne me dérange pas. Mais en revanche partagez, parlez-en à vos collègues, incitez-les à s’abonner, car passer tout ce temps à faire des vidéos n’a d’intérêt que si elles sont regardées par le plus grand nombre. Non pour mon compte en banque vous l’avez compris, ni pour la gloire (même si, sans hypocrisie, il est toujours bon d’entretenir une réputation ), mais bien pour le seul et unique plaisir de partager un savoir. C’est le seul moteur de Dot.Blog et c’est celui de Dot.Vlog.

Alors pensez à diffuser l’information autour de vous !

Bonus : le code source

Pour les courageux qui auront lu jusqu’ici voici le lien Dropbox vers le répertoire qui contient le code source de toutes les vidéos Dot.Vlog. Conservez-le, les nouveaux exemples viendront s’ajouter avec le temps….

Facile à retenir, le lien raccourci est http://tiny.cc/DotVlog

Conclusion

Les Enum ne sont vraiment pas la feature la plus exaltante de C#, mais c’est l’une des plus pratiques ! Et c’est surtout comment on s’en sert qui permet de développer des connaissances nouvelles, de la compétence et du plaisir à produire un code objet propre mais aussi des UI de meilleure qualité !

Stay Tuned !

Catégories: Dévelopement

Les messageries MVVM avec les Xamarin.Forms (partie 2/2)

Dot.Blog - mar, 04/12/2018 - 03:34

D'où viennent-elles ? A quoi servent-elles ? Quand et comment les utiliser ? Quand ne pas les utiliser ? Cette seconde partie vous montrera le code pour tout comprendre !

Partie 2/2

Cette vidéo est la suite de la partie 1 que vous trouverez ici que je vous conseille de visionner en premier, mais c’est vous qui voyez

Messageries MVVM

Tous les toolbox MVVM en propose une. Il en existe même une “out of the box” dans les Xamarin.Forms.

Mais souvent je rencontre des développeurs qui se demandent à quoi cela peut bien servir, dans quels cas ?

Il est vrai que c’est mystérieux. Le principe semble simple, mais à quel besoin correspond-t-il ? Doit-on en mettre partout, ne pas les utiliser du tout ?

Ca fait beaucoup de questions !

Pour y répondre et rester dans le format Dot.Vlog (30 min maximum) il a fallu que je coupe et découpe…

La vidéo Dot.Vlog

Et même en n’hésitant pas avec les ciseaux, ça dépassait. Alors j’ai tranché. En deux.

Voici la seconde partie, n’oubliez de voir la partie 1 (lien plus haut) !

Le lien direct (surtout pour y laisser des commentaires, ceux laissés ici ne sont pas pris en compte par l’algo de YouTube…) : https://youtu.be/f1N-hJxES3M

Bon visionnage

Et Stay Tuned !

Catégories: Dévelopement

Les messageries MVVM avec les Xamarin.Forms (partie 1/2)

Dot.Blog - lun, 03/12/2018 - 03:21

D'où viennent-elles ? A quoi servent-elles ? Quand et comment les utiliser ? Quand ne pas les utiliser ? Bref, vous saurez tout sur les messageries MVVM !

Messageries MVVM

Tous les toolbox MVVM en propose une. Il en existe même une “out of the box” dans les Xamarin.Forms.

Mais souvent je rencontre des développeurs qui se demandent à quoi cela peut bien servir, dans quels cas ?

Il est vrai que c’est mystérieux. Le principe semble simple, mais à quel besoin correspond-t-il ? Doit-on en mettre partout, ne pas les utiliser du tout ?

Ca fait beaucoup de questions !

Pour y répondre et rester dans le format Dot.Vlog (30 min maximum) il a fallu que je coupe et découpe…

La vidéo Dot.Vlog

Et même en n’hésitant pas avec les ciseaux, ça dépassait. Alors j’ai tranché. En deux.

Voici la première partie, la suite dans la prochaine vidéo !

Le lien direct (surtout pour y laisser des commentaires, ceux laissés ici ne sont pas pris en compte par l’algo de YouTube…) : https://www.youtube.com/watch?v=8r9-EC0bPVE

Bon visionnage

Et Stay Tuned !

Catégories: Dévelopement

Xamarin.Forms : le nouveau ImageButton

Dot.Blog - mar, 27/11/2018 - 16:36

Les boutons avec image font partie de ce petit groupe d’objet d’UI incontournables. Mais jusqu’ici point de bouton à image sous Xamarin.Forms, mais cela vient de changer !

ImageButton

Voici un post qui ne réclame pas de long blabla ni ne justifie une vidéo sur Dot.Vlog. Tout le monde sait ce qu’est un bouton, une image, et tout le monde a déjà vu des bouton avec texte + image.

Les présentations étant faites, depuis la version 3.4.0 des Xamarin.Forms nous avons ainsi le plaisir de trouver une nouvelle classe “ImageButton” qui remplit cet office.

Certes imparfaitement (j’ai vu quelques petits bugs de comportements un peu louche, mais comme le reste ce n’est pas à sa première release qu’il faut juger une nouveauté), mais l’ImageButton fait le job et très simplement.

Utilisations inventives

Un bouton avec image seule cela permet d’obtenir une image cliquable… Sans avoir à bricoler une image en lui ajoutant une Gesture par exemple. Ce qui n’est guère compliqué (mon livre sur les Xamarin.Forms montre des exemples de cette stratégie) mais si c’est déjà fait autant en profiter et se concentrer sur du code plus utile.

Ainsi en associant habilement les possibilités du Visual State Manager et de l’ImageButton on peut facilement créer des effets sympathiques autant que dynamiques, comme par exemple un effet visuel d’enfoncement lorsqu’on clique sur le bouton (en réalité un changement de l’échelle de l’image).

Pour ceux qui souhaiterait tout savoir sur le Visual State Manager, n’oubliez pas ma série de trois vidéos sur Dot.Vlog qui traite du sujet !

Le code suivant illustre une telle astuce :


Ce qui visuellement donnera environ cela :


Comme on le voit gérer l’effet sur le bouton ne l’empêche pas de gérer normalement son clic (mis en évidence ici par l’affichage d’un message).

Les plus perspicaces d’entre vous (et ceux qui auront suivi ma série de trois vidéos sur le VSM !) auront remarqué que l’exemple de code utilise un état “Pressed” sur le bouton. Or les CommonStates ne définissent que Normal, Focused et Disabled. Il s’agit ici d’un petit raccourci, l’état “Pressed” étant un état “custom” géré à part mais ce n’était pas l’objet du papier d’aujourd’hui…

Conclusion

Que dire de plus que merci… L’ImageButton n’est certes pas une fonction “killer”, la terre ne suspendra pas sa ronde autour de son axe ni autour du soleil. Mais c’est une modeste contribution qui simplifie la vie car des images cliquables c’est un besoin fréquent…

Stay Tuned !

Catégories: Dévelopement

Le Visual State Manager des Xamarin.Forms (3 vidéos)

Dot.Blog - jeu, 15/11/2018 - 00:11

Le VSM est un vieil ami créé pour Silverlight puis adopter par WPF, on le retrouve depuis la V 3.0 dans les Xamarin.Forms. Qui est-il ? Comment fonctionne-t-il ? Vous saurez tout en regardant ce cycle de 3 vidéos !

Le Visual State Manager

Il s’agit d’un outil XAML très puissant permettant de faire correspondre les états de votre application à des modifications visuelles de l’UI. Il peut ainsi servir à une infinité de choses comme gérer la mise en page en cas de changement d’orientation de la device, mettre en accord le visuel des états internes des contrôles avec votre thème en spécifiant un look pour les états Normal, Focused et Disabled, il peut servir aussi à mettre en place un retour visuel pour la validation des champs gérés par votre ViewModel… et bien d’autres applications possibles !

On pourrait presque affirmer que bien développer en XAML c’est forcément se servir du VSM.

D’où l’intérêt et l’importance d’en comprendre toutes les facettes.

Le cycle de trois vidéos

Je suis parti de ce qu’il fallait savoir sur le VSM, j’ai construit des démos, puis j’ai enregistré… Ce fut long… A la fin je me suis retrouvé avec du matériel pour faire un film et non une vidéo YouTube, au moins deux heures d’enregistrements….

J’ai alors décidé de segmenter tout cela en trois vidéos différentes. J’ai enregistré un message ajouté en fin des vidéos 1 et 2 pour prévenir que la suite était à chercher des vidéos suivantes car lorsque j’ai enregistré l’ensemble j’en parlais comme si tout n’était qu’en un seul morceau.

Après des heures (3 jours) de montage, d’astuces, d’ajout d’annotations, d’animations, d’accélération en mode time streching, l’utilisation de plusieurs logiciels différents (Camtasia pour le recording écran, Magix Vidéo Deluxe le frère de Sony Vegas pour les effets spéciaux, la compression, les montages complexes…) sans parler d’un bref passage de Jean-Claude et d’une séquence corrective insérée dans la vidéo 1, j’ai le plaisir de vous présenter ce cycle spécial VSM !

Vidéo 1 : Présentation du VSM et Les Common States

La première vidéo pose le décors et explique ce qu’est le VSM. Elle se poursuite par une première démonstration de ce que sont les Common States et comment en tirer parti.

Le lien direct pour la vidéo si le viewer ci-dessous ne marchait pas : https://youtu.be/OFcopVPrgDg

Vidéo 2 : Le VSM pour gérer les résolutions et les form factors

Prétexte pour présenter de nouveaux aspects du Visual State Manager, la seconde vidéo montre comment gérer automatiquement la mise en page en cas de changement d’orientation de la device. Certaines informations peuvent apparaitre ou disparaître selon l’orientation, la place disponible ou tout autre test à votre guise. C’est assez simple mais en comprendre toutes les possibilités au-delà de l’exemple réclamera un petit effort d’imagination !

Le lien direct : https://youtu.be/yOz89aw4K6Y

Vidéo 3 : Le VSM et les Custom States

C’est bien entendu là où le VSM est le plus puissant, dans sa capacité à accepter la définition de nouveaux groupes d’états et la création d’états correspondant à la sémantique de votre application.

Ce troisième volet est plus “trapu” et plus difficile à suivre mais tout ira bien si vous avez regardé les deux épisodes précédents !

L’exemple utilisé est celui de la représentation visuelle dans l’UI de l’état de validation de données à saisir.

Le tout en respectant MVVM ce qui complique les choses comme vous le verrez.

D’ailleurs exceptionnellement le code de l’application exemple utilisé pour la vidéo est téléchargeable ici : https://www.dropbox.com/s/k5o7j5gxmmdfcqv/VsmDemoDistrib.zip?dl=0

En général ce qui est montré dans Dot.Vlog est facilement reproductible. Là, avoir le code pourra vous être utile (notamment pour la classe helper que j’ai ajoutée).

Le lien direct : https://youtu.be/Yrf_hHqq42Q


Conclusion

Le Visual State Manager est un outil majeur de XAML, savoir l’utiliser et en tirer parti même dans un cadre MVVM est indispensable. Les designers avec qui vous travaillez doivent être mis au courant des possibilités que le VSM offre, de même que vous devez prendre en compte cette possibilité de visualisation des états de votre “machine à états” qu’est votre application dans la conception de vos ViewModels.

Trois vidéos, environ 2h au départ, raccourcies en post production par des coupures et l’utilisation de time stretching en trois vidéos d’une demi heure environ, c’était le minimum pour présenter correctement le VSM…

Plusieurs jours de travail ont été nécessaire à la conception, l’enregistrement et la post production de ces vidéos, puissent-elles vous rendre service, tel sera mon salaire !

Stay Tuned !

Catégories: Dévelopement

Dot.Vlog - Xamarin.Forms : Les App Shortcuts

Dot.Blog - lun, 29/10/2018 - 20:52

Comment mettre en place des App Shortcuts sous Xamarin.Forms, quel code, quel plugin utiliser, qu'en attendre visuellement...

Les App Shortcuts

Ces raccourcis bien pratiques que les utilisateurs adorent sont à portée de main !

Ce nouvel épisode de Dot.Vlog vous réserve aussi une surprise…

A voir ici ou directement sur la playlist Dot.Vlog de ma chaîne Youtube : https://youtu.be/e4KVw-gUBnk

A visionner en plein écran pour en profiter

Le Github du plugin utilisé : https://github.com/adenearnshaw/AppShortcutsPlugin

Un article de l’auteur qui précise le fonctionnement du plugin (tout n’est pas abordé dans la vidéo, rien ne sert de faire de redites) : https://adenearnshaw.com/adding-app-shortcuts/


Stay Tuned !

Catégories: Dévelopement

Xamarin.Forms Previewer et données de design

Dot.Blog - jeu, 25/10/2018 - 15:27

A défaut de designer visuel le Previewer de XAML est un outil bien pratique, comment s’en servir et comment gérer des données de design ?

Dot.Vlog épisode 8 : Le Previewer de XAML

Il existe, il fonctionne, il n’est pas parfait, mais il s’améliore avec le temps. Qui ? Le Previewer de XAML pour les Xamarin.Forms.

Cet outil peut vous aider à gagner un temps énorme lors de la conception de vos écrans. Il peut même supporter des données de design ce qui rend le travail plus aisé en matérialisant un affichage réaliste.

S’apercevoir tout de suite qu’une zone est mal placée, qu’une autre est trop grande, trop petite, qu’une couleur ne colle pas, qu’un style a été oublié…. tout ça sans compiler / générer / exécuter c’est un énorme plus.

Mais je n’irai pas plus loin ici puisque tout est dit dans ce nouvel épisode de Dot.Vlog à déguster sur place avec le visionneur intégré ci-dessous ou sur YouTube !

Si vous souhaitez mettre des commentaires faites-le sur Youtube car cela compte dans l’algorithme de proposition de la chaîne à d’autres personnes. Un commentaire laissé ici n’a pas cet effet hélas…Mettre des commentaires sur Youtube, partager, liker, c’est une façon totalement gratuite de soutenir la chaîne, merci d’avance

Lien direct vers YouTube : https://youtu.be/AKTDNQNFhqc

Bon visionnage et…


Stay Tuned !

Catégories: Dévelopement

XAML : Les convertisseurs de valeur

Dot.Blog - mar, 23/10/2018 - 15:50

Souvent croisés dans un code impliquant XAML comme les Xamarin.Forms les convertisseurs de valeur propose une solution élégante pour adapter les données du ViewModel aux besoins de la View sans créer de lien fort entre les deux. Comment ?

Les convertisseurs de valeur

Ils sont au cœur du binding et il est impossible de parler de ce dernier en passant sous silence la notion de convertisseur. Or l’un des principaux avantages des Xamarin.Forms est d’utiliser XAML et ses bindings… Il est donc important de comprendre l’utilité et l’implémentation de ces objets particuliers.

Et comme le visuel est largement moins important que les explications dans cette histoire de convertisseurs, c’est Dot.Blog qui s’y colle et pas Dot.Vlog ! Mais un nouvel épisode est en cours !

Définition par l’exemple

Commençons par poser la définition de cet outil en la rendant compréhensible par un exemple.

Le binding permet de connecter deux propriétés quelconques ensemble. L’une provient du ViewModel, c’est la source, l’autre est celle d’un objet de l’UI, la cible. Par exemple on lie par binding la propriété NomUtilisateur du ViewModel à la propriété Text d’un Label de la View de sorte que le nom de l’utilisateur puisse être affiché. Si la valeur change dans le ViewModel le Label sera mis à jour automatiquement. C’est une liaison “OneWay”, à sens unique. Si on effectue le lien avec la propriété Text d’un Entry, la liaison sera généralement de type “TwoWay”, à double sens. Si la propriété du ViewModel change le Entry sera mis à jour comme précédemment mais en plus si l’utilisateur modifie la valeur dans le Entry le ViewModel sera lui aussi mis à jour.

Tout cela fonctionne très bien notamment grâce à l’objet de Binding qui est créé et qui gère ces passages d’information et aussi grâce à INotifyPropertyChanged l’interface que tout ViewModel implémente et qui permet aux différents bindings posés d’être tenus au courant des éventuelles modifications.

Dans l’exemple introduit plus haut si tout marche comme prévu c’est aussi que la propriété NomUtilisateur du ViewModel est définie comme string et qu’il en va de même pour la propriété Text aussi bien du Label que du Entry.

Mais dans d’autres cas les types des propriétés peuvent être différents. Et cela va poser un problème…

Si le Framework possède des automatismes de conversion, ces derniers ne peuvent couvrir la totalité des besoins créés par le binding. Il est donc nécessaire d’offrir un mécanisme permettant de convertir une valeur source en une autre valeur compatible avec le type de la cible du binding. C’est le rôle des convertisseurs de valeur. Ils prennent une valeur d’entrée et la transforment pour qu’elle devienne une valeur acceptable par la cible en sortie. Le mécanisme complet supporte la conversion dans les deux sens même si cette utilisation est plus rare.

Les convertisseurs de valeur sont des objets dont on créé l’instance sous la forme d’une ressource soit dans la View qui l’utilise soit dans App.Xaml si l’utilisation est fréquente dans plusieurs Views.

C’est un objet tout à fait banal mais il doit implémenter IValueConverter.

Il faut le comprendre comme une sorte de fonction sans mémoire. C’est presque un “anti-objet” dans le sens où il n’y a pas d’état mémorisé alors que l’un des buts d’un objet est d’encapsuler des états. De fait un même convertisseur peut être utilisé par plusieurs Views et plusieurs fois dans une même View sans que cela ne pose pas de problème. La “fonction” est appelée avec la valeur à convertir, elle rend son résultat et c’est terminé, comme les champs visuels ne sont pas traités en parallèle par le moteur d’affichage mais l’un après l’autre il n’y aucun risque de confusion possible.

Scénario d’un exemple

Supposons un rectangle posé sur une fiche ainsi qu’un Slider prenant les valeurs de 1 à 10.

Imaginons que nous voulions que le rectangle soit caché (Visibility.Collapsed en Xaml pur, IsVisible=false en Xamarin.Forms) lorsque la valeur du Slider (propriété Value) est inférieure à 6 et qu’il soit affiché dans le cas contraire (Visibility.Visible en Xaml pur, IsVisible=true en Xamarin.Forms).

Naturellement on ne souhaite pas gérer cette situation « à l’ancienne » c'est-à-dire en programmant un gestionnaire d’événement sur le changement de valeur du Slider, code qui modifierait la visibilité du rectangle et qui serait caché dans le code-behind de la View. Et ce code a encore moins sa place dans le ViewModel. Le ViewModel ne doit rien savoir de la View ou des Views qui l’utilisent. Et puis implémenter un gestionnaire d’évènement pour la View dans le ViewModel, comment dire… c’est une monstruosité, une sorte de palme d’or du code spaghetti…

Dans une vision plus moderne et plus conforme à l’esprit de Xaml et de MVVM nous souhaitons utiliser un binding entre la propriété IsVisible (Visibility sous UWP/WPF) du rectangle et la propriété Value du Slider.

Seulement ces deux propriétés ne sont pas compatibles entre elles (un double et un booléen sous Xamarin.Forms ou une enum Visibility en WPF/UWP).

De plus aucun automatisme ne peut savoir à partir de quelle valeur du Slider il faut considérer que le rectangle est visible ou non. Cette valeur est totalement conjoncturelle et dépend du contexte de l’application, peut-être même du code métier, de la valeur d’autres données… Le Framework .NET ne peut pas deviner tous les cas possibles.

C’est là qu’interviennent les convertisseurs de valeur. Dans le cas précis de notre exemple fictif du rectangle il faudra écrire un convertisseur acceptant en entrée un double (la valeur du Slider, Value) et produire en sortie une valeur de type bool (sous Xamarin.Forms et Visibility en Xaml pur) en respectant les contraintes indiquées.

Ce genre de situation est très fréquent sous XAML et les projets possèdent généralement un répertoire dédié contenant de nombreux convertisseurs.

On notera que l’avènement du pattern MVVM pourrait inciter à croire que le ViewModel pourrait jouer le rôle d’adaptateur de valeur pour sa Vue. Mais c’est une erreur !

Dans notre exemple la propriété à exposer serait un booléen, un type banal et “innocent”. Mais sous d’autres formes de XAML (WPF, UWP) cela impliquerait que le ViewModel expose une propriété de type Visibility dans l’exemple pris jusqu’ici… Or ce type ne concerne que l’UI, une telle confusion des genres, l’obligation d’importer par un “using” un namespace d’UI dans un ViewModel est une catastrophe du point de vue de la séparation code / IHM, ce qui est le but même de MVVM ! Il se trouve que dans notre exemple Xamarin.Forms ne suit pas la convention du XAML traditionnel (avec IsVisible booléen au lieu de Visibility), mais dans de nombreux autres cas le même problème se posera, et jamais un type d’UI ne devra apparaître dans un ViewModel.

On pourrait penser malgré tout qu’ici l’exposition d’un booléen sous Xamarin.Forms ne posera pas ce type de problème. C’est vrai, mais cela ne règle pas tout car il faudra tout de même définir une propriété spécialement pour l’affichage et utile que pour l’affichage sans aucun autre sens fonctionnel et ce dans un ViewModel qui n’a rien à voir avec l’affichage. Il faudra aussi penser à calculer sa valeur puis à notifier le changement de valeur de cette propriété. Tout cela ressemble à du bricolage de débutant je vous l’assure…

Donc on le voit, puisque le ViewModel ne doit pas jouer le rôle d’adaptateur surtout pas en exposant des propriétés définies via des types spécifiques de l’UI, il va bien falloir tout de même un mécanisme pour réaliser le tour de magie qui va convertir un double en booléen comme dans l’exemple du Slider et du rectangle…

Il n’y a pas de magie en programmation, si quelque chose se passe c’est qu’un code s’exécute. Ici ce sera celui d’un convertisseur de valeur.

Implémentation

Les convertisseurs de valeur sont des classes tout ce qu’il y a de plus basiques. Leur seule contrainte : implémenter l’interface IValueConverter pour des bindings simples, ou IMultiValueConverter pour les bindings multiples qui n’existent pas sous Xamarin.Forms mais qu’on trouve en XAML pur. Ces interfaces exposent deux méthodes : Convert et ConvertBack. La première est systématiquement utilisée, la seconde plus rarement (certaines transformations n’étant pas facilement réversibles et de nombreux bindings ne sont pas à double sens). Voici un exemple typique de convertisseur (pour Xamarin.Forms) :

public class NullToVisibilityConverter : IValueConverter { public object Convert(object value, Type targetType, object parameter, CultureInfo culture) { return !string.IsNullOrEmpty($"{value}"); } public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture) { throw new NotImplementedException(); } }

Ce convertisseur implémente uniquement la conversion source vers cible et lève une exception si jamais la conversion inverse est sollicitée. Ici le but du convertisseur est de retourner la visibilité (true/false) pour une chaîne de caractères en fonction de ce qu’elle contient. La visibilité retournée est true si la chaîne contient quelque chose, sinon la réponse est false. Ce code est adapté à Xamarin.Forms, pour du XAML pur on utiliserait Visibility.Visible et Visibility.Collapsed en réponse.

On le voit à la signature des méthodes Convert et ConvertBack la valeur à convertir n’est pas le seul paramètre disponible. On reçoit aussi les informations de culture, ce qui peut être essentiel pour un formatage (nombres, dates notamment) ainsi que d’éventuels paramètres permettant de modifier le comportement du convertisseur. Ces paramètres sont passés via le code XAML du binding utilisant le convertisseur.

A savoir : la culture transmise est celle passée en paramètre dans l’appel au convertisseur ce qui permet de faire des mises en formes dans une culture différente de celle de l’application (forcer une mise en forme de la date à la japonaise quelle que soit la culture de l’application, c’est à dire AAAA/MM/JJ plus logique que les autres formats, et cela sans coder quoi que ce soit…).

Dans l’exemple du Slider et du rectangle à afficher ou cacher, si nous devions écrire le convertisseur il serait certainement intelligent de prévoir un paramètre indiquant la valeur limite de bascule affiché/caché plutôt que de fixer en dur la valeur “6” (celle de l’exemple). Le convertisseur pourrait ainsi être réutilisé dans d’autres contextes et il sera plus facile de s’adapter à tout changement de règle (un code professionnel doit savoir suivre les évolutions des besoins des utilisateurs sans tout remettre en cause…). C’est tout l’intérêt de l’objet parameter passé à Convert et ConvertBack.

On remarque aussi que le type de la cible est fourni aux méthodes de conversion, ce qui permet de rendre encore plus générique le code du convertisseur ou au contraire de limiter son fonctionnement à un ou des types bien définis. Quant à la valeur on note aussi qu’elle est transmise sous la forme d’un object, ce qui impliquera le plus souvent de la transtypée correctement avant de la convertir. Il se trouve que dans le code ci-dessus le type string accepte les null et que tous les types possèdent une méthode ToString() héritée de object. De fait un transtypage n’est pas nécessaire puisque seul le fait que la chaîne soit vide ou null nous intéresse dans ce cas précis. Toutefois s’il fallait intervenir sur le contenu de la chaîne (chercher par exemple si elle contient un caractère spécial ou un bout de texte particulier) il serait nécessaire de convertir le paramètre “value” en une string.

Utilisation

Une fois codés les convertisseurs sont utilisés au sein des balises de binding de Xaml.

Instanciation

Pour utiliser un convertisseur il faut qu’une instance existe, ce qui paraît logique. Il existe plusieurs façons de créer cette dernière. La plus commune consiste à créer une ressource dans la View en cours. Si le convertisseur est utilisable en de nombreux endroits de l’application il est préférable de le placer dans App.Xaml. Après avoir déclaré le namespace on trouvera une déclaration de ce type dans les ressources :

<?xml version="1.0" encoding="utf-8"?> <ContentPage xmlns="http://xamarin.com/schemas/2014/forms" xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml" xmlns:local="clr-namespace:ConverterFormsSample" x:Class="ConverterFormsSample.MainPage" xmlns:converter="clr-namespace:ConverterFormsSample.Converters" BackgroundColor="LightGray"> <ContentPage.Resources> <ResourceDictionary> <converter:NullToVisibilityConverter x:Key="nullToVisibilityConverter" /> </ResourceDictionary> </ContentPage.Resources> <StackLayout VerticalOptions="CenterAndExpand" Padding="40"> <Entry Text="{Binding Name}"/> <Button Text="Enter" IsVisible="{Binding Name, Converter={StaticResource nullToVisibilityConverter}}"/> </StackLayout> </ContentPage>

Bien entendu le nom exact du xmlns est arbitraire et celui du namespace CLR dépend de votre application. Toutefois il est judicieux de placer tous les convertisseurs dans un même namespace (“Converters” par exemple) et de les déclarer avec un raccourci propre plutôt que d’utiliser le namespace de l’application comme un fourre-tout.

Invocation

On invoque un convertisseur au sein d’un binding. Il est difficile de vous présenter un binding sans explication mais l’étude de la nature et de la syntaxe de tous les types de bindings est l’un des sujets traité en profondeur dans mon livre gratuit AllDotBlog Tome 7-XAML que je vous invite à télécharger, vous trouverez donc toutes les explications dans ce document. Pour l’instant concentrons-nous sur le convertisseur.

Je ne vais pas recopier l’extrait de code publié juste quelques lignes plus haut… donc regardez-le bien et cette fois-ci au lieu de vous focaliser sur les parties en gras qui concernent la déclaration du convertisseur regardez la déclaration du Button dont la propriété IsVisible est liée à la propriété Name provenant du ViewModel via le convertisseur.

Paramètres

Cet article est déjà bien long je ne vais donc pas m’étendre sur les détails syntaxiques de l’utilisation des paramètres avec les convertisseurs. Mais comme il s’agit d’une information cruciale pour écrire du code, je vous renvoie à la documentation officielle des Xamarin.Forms qui propose des exemples de convertisseurs de valeur utilisant des paramètres.

Bonnes pratiques

Il n’y a que rarement des règles absolues en informatique, surtout dans des environnements aussi riches que WPF, UWP ou Xamarin.Forms. Il ne peut y avoir que des conseils, des bonnes pratiques éprouvées par l’expérience.

Concernant les convertisseurs les questions qui se posent sont les suivantes :

  • Où faut-il les déclarer ?
  • Où faut-il les instancier ?

J’ai déjà répondu à la première question en proposant de tous les placer dans un sous-répertoire dédié du projet et dans un espace de nom qui leur est propre. Dans certains projets il peut même s’avérer intéressant de les regrouper dans un même projet géré à part, assemblage que les autres applications pourront ensuite partager ce qui augmente la réutilisabilité des convertisseurs (on a souvent des mêmes !).

La seconde question est moins évidente à trancher. Les convertisseurs ne consomment pas beaucoup de mémoire, mais si on en utilise beaucoup il n’est peut-être pas forcément utile de tous les placer dans App.xaml (leur cycle de vie devient alors celui de l’application). Et puis App.xaml peut très vite devenir un fatras inextricable si on n’y prend garde. L’exemple que nous venons d’étudier créée l’instance sous la forme d’une ressource de la View. Cette méthode a l’avantage de « localiser » les convertisseurs et de n’instancier que ceux qui sont exploité par la fenêtre. Lorsqu’elle disparaîtra le ou les convertisseurs utilisés seront libérés.

Toutefois s’il s’agit de la View principale de l’application ou d’une View qui n’est jamais détruite, l’avantage du cycle de vie « localisé » devient caduque. Ainsi, certains développeurs préfèrent créer une classe statique regroupant tous les convertisseurs. Ces derniers sont instanciés systématiquement ou bien à la première utilisation (ce qui est plus économe surtout s’il y a beaucoup de convertisseurs et qu’ils ne sont pas forcément tous exploités).

On dispose ainsi de trois (au moins) stratégies d’instanciation :

  • Dans une ressource locale à la View
  • Dans App.Xaml
  • Dans une classe statique

Aucune de ces trois méthodes n’est bonne ou mauvaise, tout dépend du contexte de l’application, de votre façon de coder.

Créer les convertisseurs dans chaque View permet de les supprimer de la mémoire dès que la View est tuée par le Garbarge Collector. Dans un très gros projet cela peut être avantageux, mais en retour cela implique la perte de temps des instanciations à répétition des mêmes convertisseurs. La classe Statique rend les convertisseurs plus rapidement disponibles, ne consomme qu’un objet par convertisseur mais au fil du temps tous existeront en mémoire jusqu’à la sortie de l’application.

C’est donc comme toujours à vous de décider ce qui sera le plus efficace, au cas par cas.

Conclusion

Les convertisseurs sont des briques indissociables du binding. Bien comprendre leur fonctionnement, leur implémentation et choisir correctement la stratégie d’instanciation peut avoir un effet visible sur les applications, leur maintenabilité, la réutilisation du code et la qualité de celui-ci. Autant dire que ces petits objets presque insignifiants méritaient largement que j’y consacre un article entier !

Stay Tuned !

Catégories: Dévelopement

Cibler WPF avec les Xamarin.Forms !

Dot.Blog - sam, 13/10/2018 - 03:37

Enfin… Xamarin.Forms permet désormais de cibler WPF dans une solution cross-plateforme ! Comment ? …

En suivant Dot.Vlog bien sûr !

En regardant ce 7ème épisode de la série Dot.Vlog vous apprendrez en quelques minutes comment ajouter une cible WPF à toute solution Xamarin.Forms !

Pourquoi WPF ?

D’abord car c’est le seul, le vrai, l’authentique XAML. Mais en passant par celui des Xamarin.Forms on ne peut pas dire qu’on soit dans l’orthodoxie… Mais il y a un second argument de poids : La portabilité.

UWP, seule cible Windows jusqu’à lors, est réservée aux PC les plus récents faisant tourner Windows 10. Or cela est loin de couvrir le parc de tous les PC dans le monde ! Cibler WPF permet de s’affranchir de la limite de UWP et de proposer une version PC qui marche vraiment sur TOUS les PC…

J’allais oublier un dernier argument massue : la Liberté !

En effet, outre ses limitations techniques, UWP oblige à passer par le Store pour diffuser un logiciel. Il y a certes de nombreux avantages à le faire (visibilité, monétisation etc) mais pour beaucoup de petits éditeurs et même de plus gros, pour les créateurs de logiciels libres, etc, le Store peut représenter un contrainte importante. Si l’App est payante il faudra aussi partager les gains avec Microsoft et peu d’entreprises sont prêtes à le faire …  WPF vous permet de vous passer du Store totalement et de tous ces inconvénients. Mais vous pouvez aussi diffuser du WPF via le Store ! C’est donc le choix du roi par rapport à UWP.

Mais il existe encore d’autres aspects à cette liberté : la liberté technique. Avec UWP accéder à une base de données SQL locale est complexe, voire impossible hors de connexions réseaux HTTP qui ne sont pas forcément les plus efficaces pour une application desktop de type LOB notamment (sur un smartphone fonctionner avec des Web services et un serveur dans le cloud est une solution viable et même intéressante, une telle architecture n’est pas adaptée à un réseau d’entreprise en revanche). Mieux, si vous souhaitez dialoguer avec du hardware, ou même un simple port USB, UWP et sa gestion des droits vont se dresser entre vous et ces nobles buts techniques… WPF non !

Il y a donc des tas de raisons de préférer WPF à UWP (ce qui ne veut pas dire que ce dernier n’a pas aussi certains avantages).

Passer par le XAML plus limité des Xamarin.Forms pour “fabriquer” automatiquement du XAML WPF peut sembler une hérésie technique à première vue, mais si on vise le cross-plateforme alors tout devient lumineux, Xamarin.Forms est le seul moyen d’avoir la même application sous WPF que sous iOS ou Android… Sans aucun effort supplémentaire ni maintenance séparée (ou presque pour être réaliste, ce qui est vrai aussi pour Android et iOS).

Alors allons-y !

Le lien direct pour profiter de toute ma chaîne Youtube et de toutes ses vidéos : https://youtu.be/movIA-aA-zk

Et pour les paresseux du clic, et même si je vous conseille un détour par ma chaîne, voici la version en incrustation de l’épisode 7 :


Stay Tuned !

Catégories: Dévelopement

Xamarin.Forms : Utiliser des fontes personnalisées (Dot.Vlog n°6)

Dot.Blog - dim, 07/10/2018 - 14:52

L’utilisation de fontes personnalisées n’est pas très compliqué mais réclame de suivre une “recette” qui diffère selon les plateformes…

Les fontes personnalisées

Ce nouvel épisode de Dot.Vlog, le n°6, nous plonge dans le monde des fontes.

Quel est l’intérêt d’utiliser des fontes non externes aux systèmes ? Dans quel cadre ?

Quels impératifs légaux ?

Une fois cela posé, Dot.Vlog nous emmène dans les méandres du XAML de Xamarin.Forms et de Visual Studio pour mettre en évidence la façon d’utilisation des fontes ou polices personnalisées.

Bonus Animation

Les toutes dernière minutes de la vidéo se terminent par un Bonus concernant les animations pouvant s’écrire désormais directement en XAML grâce à une astuce…

La Vidéo

Lien direct : https://youtu.be/ETtCw5Qoyqc

Bon Visionnage et … Stay Tuned !

Catégories: Dévelopement

Les Triggers XAML : Xamarin.Forms vs WPF

Dot.Blog - mar, 02/10/2018 - 16:20

En complément à la série d’articles Dot.Blog et Dot.Vlog sur les Behaviors et les Triggers un petit point de comparaisons avec le père de tous les XAML n’est pas sans intérêt et répond à une question importante…

Pourquoi WPF ?

D’abord par que le XAML de WPF est le seul “vrai” XAML, le premier, le plus complet de tous, le plus abouti, c’est La référence en matière de XAML. Il est toujours bon de s’y référer pour faire des comparaisons ou tester une mouture spécifique de ce langage.

Ensuite parce que beaucoup de développeurs ont refusé UWP, le Store Microsoft et tout ce que cela suppose, Microsoft ayant mis des années avant même de penser à ajouter des possibilités de diffusion des Apps en interne dans les entreprises ce qui a terriblement pénalisé UWP. UWP C’est Windows 8 aussi, un souvenir qu’on ne peut qualifier de “bon” pour personne, utilisateurs, développeurs et Microsoft compris.

Il est donc encore très fréquent que les nouveaux projets “PC” soient écrits en Windows Forms qui est une vieillerie abominable (le pourcentage donné par MS il y a encore deux ans était effrayant, une majorité de projets !). Heureusement il y a des développeurs soucieux de concevoir des Apps modernes mais sans lien avec le Store, ceux-là choisissent naturellement WPF. La double compétence Xamarin.Forms / WPF n’étant pas rare, et le support bientôt officiel de WPF dans les Xamarin.Forms ne fera que renforcer l’attrait pour cet ancêtre qui avait en réalité 20 ans d’avance…

Je pourrais lister des tas d’autres raisons de parler de WPF, mais peu importe ce qui compte c’est que WPF est toujours d’actualité et qu’il est la référence XAML absolue.

Suite de la série Blog/Vlog sur les triggers/Behaviors en Xamarin.Forms

Dot.Vlog N°2 sur les Behaviors a été le fameux fil de la fameuse pelote de laine ! J’ai tiré un peu sur le fil et c’est toute la bobine qui est venue… J’ai ainsi continué par un article Dot.Blog précisant la différence entre les Triggers et les Behaviors. Puis saisi d’une mauvaise conscience je me suis fendu d’un nouveau Dot.Vlog, le N°5, dédié aux Triggers

Je conseille donc au lecteur de reprendre cette série pour suivre le cheminement de cette présentation multimédia multi-volets…

Quelle est la question ?

Dans le Vlog N°5 je présente une solution utilisant des Triggers pour switcher l’affichage d’un Login et d’un DisplayName selon l’existence ou l’absence de ce dernier dans la fiche de l’utilisateur fictif utilisé pour la démonstration.

La solution proposée utilise deux Labels, exactement comme la “mauvaise solution” présentée au départ pour justifier le passage aux Triggers.

Certes les Triggers vont permettre de rendre l’ensemble du code de la démonstration bien plus pro : un meilleur ViewModel sans propriétés ad hoc inutiles, un code XAML plus technique, utilisation d’un convertisseur de valeur, etc, des choses qui sont autant de prétextes de montrer du XAML sous Xamarin.Forms mais qui rendent la justification des Triggers un peu moins évidente il faut l’avouer.

Car voilà, il reste deux Labels dans le code “propre”.

D’ailleurs cela fut noté assez rapidement par un “lecteur” (regardeur ?) de ce Vlog…

Dans les coulisses du tournage du Vlog N°5 …

Selon le Vlog que je tourne je peux faire tout en une seule passe ou segmenter mes prises de vues. C’est pour cela qu’on peut me voir en éclairage nocturne ou baigné de lumière du jour sur les différentes séquences, ou l’un ou l’autre ou les deux. Pour avoir une lumière constante il me faudrait un studio toujours éclairé artificiellement de la même façon et je ne dispose pas d’un plateau télé pour tourner Dot.Vlog, n’exagérons rien

Etant un minimum à l’aise avec C# et XAML, il arrive donc le plus souvent que je me lance directement. Ce fut le cas pour le Vlog N°5. J’avais bien entendu l’intention de remplacer les deux Labels par un SEUL !

Pour s’en convaincre et si vous êtes attentifs vous noterez que dans la toute première partie de la vidéo j’insiste sur les deux Labels, comme une façon de dire “vous allez voir ce que vous allez voir, ces deux là sont de trop on peut n’en avoir qu’un seul !”. J’ai eu l’intelligence de ne pas le dire (sinon j’aurais du retourner les séquences) mais j’avais insisté un peu lourdement… Si j’avais su à ce moment que cela ne serait pas possible j’aurai au contraire minimisé la présence des deux Labels sans trop revenir dessus… Il faut savoir “vendre” ce qu’on montre et aucune démo n’est totalement honnête… D’ailleurs le philosophe nous dit que toute communication est une manipulation. C’est vrai même quand on parle de la pluie et du beau temps à la machine à café… A vrai dire il faut nuancer un peu et les sociologues eux nous disent que toute communication est une influence. Ce qui revient au même sauf que dans un cas il y a intention de manipuler et pas dans l’autre.

Bref, lorsque je dis que je vais passer à la “bonne” solution et qu’on va se retrouver dans un instant “le temps que je change tout çà”. C’est vrai. Ce fut assez rapide, sauf qu’au moment de remplacer les deux Labels par un seul et donc de swticher le Binding dans le trigger (pour qu’il pointe soit sur le Login soit le DisplayName) les choses ne sont pas allées comme je le voulais…

En réalité ça plantait et j’ai passé plusieurs heures en debug pour tenter de comprendre… C’est pourquoi sur la suite il fait jour, je ne suis pas coiffé pareil, je suis en chemise et plus en t-shirt etc… ce n’est pas raccord dirait-on dans le cinéma…

Et entre temps la “bonne” solution présentée ne parle plus beaucoup des deux Labels dont la présence semble même tout à fait normale, voire obligatoire… Genre on a deux informations, il faut bien deux Labels…

Fausse logique manipulatoire…

Ruse de sioux qui bien entendu n’a pas échappée à tout le monde !

Mais ce n’est pas l’esprit de Dot.Blog, je vous devais la vérité !

Pourquoi me suis-je fait avoir ?

Deux raisons à cela :

  1. Tout simplement parce que cela fonctionne en WPF et que WPF est ma seule référence XAML consciente et inconsciente !
  2. Xamarin.Forms a un bogue dans son moteur XAML…
En quoi tout cela est-il intéressant ?

D’abord c’est important de savoir que Xamarin.Forms peut se comporter différemment de WPF ou de UWP (je n’ai pas testé sous UWP si quelqu’un veut le faire…).

Ensuite cela s’apparente à un bogue mais j’entends très bien la réponse possible qu’il s’agit d’une “feature” …

Et puis au final c’est intéressant de rappeler qu’à chaque fois qu’on passe d’une mouture à l’autre de XAML il faut absolument se forcer à se remettre dans le bon contexte car tous ces XAML ne sont pas identiques… Vouloir faire du XAML WPF avec Xamarin.Forms ne marchera pas dans tous les cas, nous en avons la preuve ici, autant qu’utiliser la syntaxe Xamarin.Forms en WPF risque de vous poser des problèmes… Et cela nous allons en avoir une illustration immédiatement !

Comment atteindre le but avec XAML WPF ?

La première chose à savoir c’est qu’en WPF les Triggers ne s’utilisent pas comme ça à la volée comme en Xamarin.Forms ! C’est un avantage de ces dernières il faut le dire, dommage que cela soit un poil bogué sur les Bindings donc.

Sous WPF les Triggers ne sont utilisables qu’à l’intérieur des Styles et des Templates. Pas dans le flux d’un code comme celui de l’exemple montré dans le Vlog N°5.

Pour adapter le code montré il faudra donc créer un Style. Heureusement pour la simplicité de l’exemple on peut déclarer ce style directement dans le contrôle, on n’est pas obligé de le créer à part dans un dictionnaire de ressources (mais c’est cette dernière façon de faire qui est la bonne).

Donc, j’ai refait entièrement le projet à l’identique sous WPF en changeant tout ce qui doit l’être (pas mal de petites choses même si globalement 90% du code est identique). Je vous ferai grâce du projet dans sa totalité puisque c’est la même chose qu’en Xamarin.Forms, sauf la déclaration de l’unique Label qui switche entre les Bindings. Et ce code est le suivant :

(cliquez sur l’image pour l’avoir en 100% si jamais elle est trop petite)

Il n’y a plus qu’un seul Label, enfin un TextBlock, par défaut il est formaté pour le DisplayName (FontSize à 30 et couleur à DodgerBlue).

On voit clairement en revanche que le Trigger a été enchâssé dans un Style.

On note aussi que le Binding par défaut est défini dans le Style (Binding vers DisplayName) et non pas dans la balise du contrôle TextBlock car dans ce cas il y aurait écrasement de la dernière valeur et le Trigger n’aurait pas d’effet (subtilité du moteur de valeurs de XAML).

Sinon le code est celui auquel on s’attend, si le DisplayName est vide, le Trigger se déclenche et il change le Binding pour pointer vers le Login, et il en profite pour modifier les propriétés visuelles pour recrée exactement le comportement de la démo Xamarin.Forms ! Les Triggers s’annulant grâce au fameux moteur de valeurs de XAML, lorsque la condition n’est plus vraie, toutes les propriétés de dépendances modifiées reprennent leur valeur précédente (donc couleur, taille de fonte et binding du texte). Mais cela est expliqué dans le tome 7 de AllDotBlog dédié à XAML.

Conclusion

Rien ne sert d’aller plus loin, mais il était important de répondre à la question du “pourquoi deux Labels” dans la “bonne” solution présentée dans el Vlog  N°5. Et puis parler de temps en temps de WPF, alors même que cette cible est en train d’être ajoutée aux Xamarin.Forms n’est peut-être pas totalement fortuit… Toute communication est une manipulation non ?

Stay Tuned !

Catégories: Dévelopement

Xamarin.Forms : les Triggers à l’œuvre

Dot.Blog - lun, 01/10/2018 - 01:36

Après avoir présenté les behaviors, la différence entre Trigger et Behavior, il était bien normal de présenter les Triggers et leur bonne utilisation sur Dot.Vlog !

Dot.Vlog

En un mot pour ceux qui ne connaissent pas encore car cela est très récent (au moment où j’écris ce billet), Dot.Blog se double désormais d’un vlog sur YouTube naturellement appelé Dot.Vlog et intégré à ma chaîne YouTube sur laquelle j’ai déjà publié de nombreuses vidéos.

Certains sujets sont ainsi traités à la fois sous forme de billet écrits ici et sous forme de vidéos sur Dot.Vlog, parfois un sujet n’est traité que par l’un ou l’autre de ces médias. Dans tous les cas les annonces passent par Dot.Blog, ce qui ne vous interdit pas de vous abonner à ma chaîne YouTube (en activant la petite cloche !) pour être averti dès la sortie d’un nouvel épisode de Dot.Vlog !

Les Triggers

J’ai présenté dans l’épisode 2 de Dto.Vlog les Behaviors sous Xamarin.Forms. Puis, en toute logique j’ai souhaité dans un papier paru sur Dot.Blog préciser la différence entre Behaviors et Triggers. Finalement il m’a paru plus cohérent de boucler le sujet en parlant aussi des Triggers dans Dot.Vlog… C’est l’objet de l’épisode 5 à voir sur YouTube (lien direct de la vidéo : https://youtu.be/TK6q2LZs31s) ou ci-dessous dans l’incrustation vidéo.

Il est possible de regarder cet épisode sans avoir lu ni vu les autres épisodes (autant sur Dot.Vlog que sur Dot.Blog) mais il paraît logique de vous conseiller de le faire pour avoir une vue d’ensemble du sujet.

Bon visionnage !


Et Stay Tuned !

Catégories: Dévelopement

Utiliser la Toolbox pour taper du XAML

Dot.Blog - ven, 28/09/2018 - 15:12

Lorsqu’on fait une mise en page en XAML la Toolbox permet d’éviter la frappe de toute la “carcasse” d’une balise..

Toolbox (Boîte à outils)

Dans le menu affichage on obtient la Toolbox mais on peut aussi taper Ctrl+Alt+X pour aller plus vite.

Attention, en français il existe deux entrées “boîte à outils” qui se ressemblent…

On peut aussi fixer la boîte sur le côté, c’est plus pratique.

Mais le mieux ne serait-ce pas de voir tout cela à l’œuvre en quelques secondes grâce à Dot.Vlog ? !

Voici le lien direct YouTube (c’est très court 2 minutes 55 avec les génériques)  : https://youtu.be/hud8MMrt9oQ



HORREUR MALHEUR : utiliser la ToolBox pour TAPER et non tapeZ ... Tellement grosse que je ne l'ai pas vue, désolé !!!

A bientôt et


Stay Tuned !

Catégories: Dévelopement

Dot.Vlog épisode 3 : Fenêtres popup animées

Dot.Blog - jeu, 27/09/2018 - 04:18

Les petits détails font les grands design ! Afficher proprement un dialogue popup avec une belle animation rend tout de suite l’application plus vivante. Comment ? Regardez ce nouvel épisode et vous saurez !

Dot.Vlog n°3

Voici le numéro de 3 de Dot.Vlog, la contrepartie YouTube de Dot.Blog. Un épisode court de 8 minutes qui explique comment afficher des fenêtres de type popup avec une animation configurable.

L’astuce se trouve dans l’utilisation d’un petit plugin mais comment s’en servir ?

Vous saurez tout en regardant ce nouvel épisode !

Au passage vous noterez l’utilisation de la nouvelle webcam qui certes ne me rend pas plus beau (quoi que !) mais rend l’image plus belle et c’est déjà pas mal …

Le lien direct si la vidéo s’affiche mal ci-dessous : https://youtu.be/JltTQ2-z4H0


Stay Tuned !

Catégories: Dévelopement

Xamarin.Forms : Triggers vs Behaviors

Dot.Blog - mar, 25/09/2018 - 03:15

Dans le N°2 de Dot.Vlog sur YouTube je vous ai proposé une démo des Behaviors sous Xamarin.Forms. Une question est restée en suspend : quelle différence fait-on entre les Triggers et les behaviors ? …

Dot.Vlog

Dot.Vlog est le pendant YouTube de Dot.Blog inauguré ce mois-ci. Le but de cette playlist sur ma chaîne YouTube est d’offrir un complément vivant et visuel aux billets de Dot.Blog. Certains sujets se prêtent mieux à l’écrit, d’autres à la vidéo.

Par exemple le 1er numéro de Dot.Vlog montrait les Xamarin.Essentials en action, ce qui avait été précédé d’un billet de présentation général de ces API. Aujourd’hui c’est l’inverse, l’épisode 2 de Dot.Vlog vous propose de voir les Behaviors en action, visuellement, et le billet que vous lisez en ce moment sur Dot.Bog vient compléter le propos par des informations plus techniques qui seraient rébarbatives à filmer (et à regarder).

C’est cet équilibre là que je vais tenter de viser avec des vidéos de 30 mn maximum. Il n’y a rien de systématique dans cette alternance, cela sera peut-être souvent le cas, ou pas… tout dépendra des sujets traités et de l’opportunité de les traiter d’une façon ou d’une autre, voire des deux façons !

Regardez les deux premiers épisodes :

Triggers & Behaviors

Si le dernier épisode de Dot.Vlog était une mise en bouche, je vais ici traiter un peu plus en profondeur du sujet, notamment en tentant de répondre à cette question légitime : Quelle différence entre Trigger et Behavior ? La réponse n’est pas évidente tant ces deux procédés peuvent paraître proches.

XAML même la version simplifiée des XForms est d’une grande richesse et d’une flexibilité incroyable. Néanmoins il ne s’agit que d’instancier des classes et de paramétrer ces instances… Quand on commence à définir des styles, des ressources, des templates, XAML commence à se détacher très nettement d’un équivalent codé en C#.
Ces possibilités étendent plus encore le champ de ce qui est réalisable exclusivement en XAML libérant progressivement et presque entièrement le code applicatif de toute la partie UI.
Mais pour aller plus loin avec XAML il faut tout de même un peu de code classique. Les convertisseurs de valeurs en sont une preuve. Ce code n’est plus lié au code fonctionnel, il se destine à l’UI et reste fortement découplé de tout le reste.
Il est ainsi déjà possible d’aller très loin en XAML mais on peut démultiplier sa puissance si on y ajoute quelques morceaux de codes pour en étendre le champ d’action.
C’est le cas des Behaviors (comportements) et des Triggers (déclencheurs).

Les lecteurs de mon livre auront peut être l’impression d’avoir lu ça quelque part… Pour les autres il s’agira d’une découverte puisque je vais piocher largement dans cet ouvrage, notamment le Chapitre 5 qui traitent justement des Behaviors et des Triggers ! Le chapitre 5 n’ayant jamais été diffusé gratuitement c’est un petit cadeau pour donner envie à ceux qui ne le possèdent pas encore de l’acquérir ! Toutefois la totalité du chapitre ne sera pas repris ici, notamment tous les exemples, Dot.Vlog a fait sa part de teasing, cet article complète, pour le reste, le livre reste LA source !

Les Behaviors

Un Behavior est un comportement, c’est à dire un bout de code qui peut faire à peu près n’importe quoi.

Pour être parfaitement juste j’ai conscience que cette définition est un peu trop large pour vous aider… Mais imaginez maintenant tout ce que peut faire un bout de code autonome (ne dépendant pas d’états externes) et faites un paquet autour afin qu’il devienne autonome et facilement réutilisable, comme un composant visuel et vous obtenez un Behavior.

Un Behavior est donc avant tout une sorte de code snippet qui porte un nom et qui s’utilise avec une balise en XAML comme tous les autres contrôles. Lorsqu’il existe un designer visuel comme c’est le cas pour toutes les formes habituelles de XAML les Behaviors apparaissent dans la même palette que les contrôles et peuvent être déposés sur la surface de travail, ce qui renforce leur similarité avec ces derniers.

Mais il s’agit d’une première approximation très simplificatrice. Car les Behaviors sont bien plus : Ils sont certes du code autonome encapsulé dans un composant apparaissant dans les palettes d’outils et utilisable directement en XAML par balisage, mais surtout ils sont conçus spécifiquement pour apporter des comportements nouveaux à des objets visuels sans modifier ni même connaître le code de ces derniers ! Ainsi, un Behavior existe en tant que composant mais pas pour lui-même, il n’a de sens que marié à un composant visuel, une BoxView ou un Button par exemple. Un Behavior s’accroche à un composant existant et c’est en jouant le poisson pilote vis-à-vis de ce composant qu’il lui amène le fameux comportement.

Un Behavior peut être totalement générique ou bien ne s’adresser qu’à une lignée de contrôles (tous les descendants de Label par exemple). Un petit exemple pour clarifier : Imaginons qu’on souhaite valider la saisie d’une zone numérique. Cela pourrait très bien être le rôle du ViewModel en MVVM mais ce n’est pas si simple car il faut un retour dans l’UI pour avertir de la présence d’une erreur.

Le mécanisme complet en mode « découplé » classique apparait ainsi assez peu pratique. De plus c’est un besoin fréquent et on peut vouloir l’appliquer en plusieurs endroits sans répéter le code (principe DRY : Don’t Repeat Yourself, ne vous répétez pas !) Mieux, on souhaiterait que cette validation puisqu’elle est visuelle puisse être gérée côté UI en totalité. Cela permet aussi à un designer pas forcément informaticien de mettre en place une UI et ses comportements, même si ce cas de figure reste assez rare (néanmoins un pattern comme MVVM a été pensé entre autres pour cela au départ).

L’approche classique n’est pas satisfaisante. Que cela soit en MVVM ou pire avec du code-behind. Si maintenant nous encapsulons tout cela dans un Behavior spécialisé pour agir sur les contrôles de type Entry, il suffira de décorer ces derniers avec le Behavior pour les doter instantanément d’une séquence de contrôle de validité numérique – c’est le code du premier exemple du livre d’ailleurs. 

Cette simple association du Behavior avec le contrôle fera qu’il sera ipso facto doté du nouveau comportement sans aucune autre programmation. La réutilisation du code est totale et tellement simplifiée que cette saine démarche s’en trouve favorisée ce qui plaide encore plus en faveur de l’utilisation des Behaviors. Côté développement de l’IHM cela permet même de créer un visuel sans être développeur pour peu qu’on dispose d’une bonne bibliothèque de Behaviors et de Triggers (je reparlerai de ces derniers plus loin). Il faut avoir à l’esprit que les Behaviors sont si versatiles qu’ils peuvent trouver des champs d’application très larges qu’on ne perçoit pas à première vue.

Ici je parlais de valider visuellement la saisie d’une zone numérique, mais on peut ainsi valider toutes sortes de données, adresses mails, code article, on peut même créer un behavior qui ajoute la reconnaissance des « gestures » à une vue particulière ou une hiérarchie de vues, il est possible de contrôler des animations, etc. Les XForms supportent deux types de Behaviors : Les behaviors simples, très fréquents, qui ajoutent un comportement à une vue et qui dérive de Behavior<T> ; Les Attached Behaviors, « comportements attachés » qui exposent en plus des précédents des propriétés attachées disponibles à l’extérieur du Behavior. Ils se définissent en outre d’une façon assez différente notamment par le biais d’une classe statique sans héritage particulier.

Débat terminologique. Quelle différence entre une propriété attachée et un Behavior ? On peut essayer de tracer une limite en disant que les propriétés attachées sont des qualités nouvelles qui n’ont de sens que pour un autre morceau de code (un conteneur comme une grille, une StackLayout) afin d’en paramétrer le comportement. Elles ne produisent aucun travail par elles-mêmes mais au travers de l’objet qu’elle complète. Elles influencent un comportement qui est déjà implémenté quelque part ailleurs, ce ne sont que des valeurs comme toutes les propriétés en général. Quand une propriété attachée effectue un travail sur l’API exposée par le BindableObject auquel elle est attachée il s’agit d’un Behavior. Les Bindable Behaviors des XForms représentent un autre type de comportement et la terminologie de la documentation officielle prête à confusion.

La création d’un Behavior simple est montrée dans l’épisode 2 de Dot.Vlog auquel je renvoie le lecteur pour éviter les redites. Mon but ici est d’essayer de vous aider à comprendre la nuance entre Behavior et Triggers uniquement, mon livre traite le sujet en profondeur ce qui dépasse le cadre d’un simple billet de Dot.Blog.

Les Behaviors avec propriété(s)

Les Behaviors classiques comme ceux dont je viens de parler (l’exemple de Dot.Vlog ou ceux du chapitre 5 de mon livre) n’ont souvent pas besoin d’autre chose que de s’attacher à une vue. Tout se déclenche à partir de là sans avoir besoin de paramétrer ou d’exposer des propriétés à l’extérieur du Behavior . Certains types de Behaviors ont en revanche besoin de déclarer des propriétés pour exister, ce sont les « Attached Behaviors » que je vous propose d’étudier plus bas. Entre les deux il existe aussi des Behaviors classiques qui peuvent exposer des propriétés permettant soit de paramétrer leur fonctionnement, soit de pouvoir exploiter leur travail en de multiples endroits dans la même page. C’est à la découverte de ce type un peu particulier que la fin de l’épisode 2 de Dot.Vlog vous invite…

J’appelle ces Behaviors entre deux genres des “Behaviors paramétriques”.

Il s’agit donc ici de déclarer dans le Behavior des propriétés classiques auxquelles on peu accéder par programmation en C# ou tout simplement en XAML en leur attribuant une valeur dans la balise de déclaration du Behavior. Le chapitre 5 du livre offre un exemple différent de celui montré dans Dot.Vlog qui permet de tester la numéricité d’un Entry..

Les behaviors interrogeables

Là encore il s’agit faute d’une terminologie officielle de trouver un nom le plus représentatif possible.

Qu’entends-je par « interrogeable » ?

Sur la base du même exemple de test de numéricité (Chapitre 5 page 124-125) on pourrait tout simplement vouloir exploiter le résultat du test à l’extérieur du Behavior. Il faut donc pouvoir l’interroger… Interroger un Behavior cela consiste à pouvoir consulter une variable qu’il mettrait à la disposition de l’extérieur. N’est-ce pas ce que fait le Behavior paramétrique ? D’une certaine façon si. Il expose bien une propriété. Mais s’agissant d’une simple propriété de base tout changement de valeur sera impossible à suivre de l’extérieur.

De plus il s’agit en l’espèce d’une propriété de paramétrage, on en fixe la valeur mais celle-ci n’évolue pas toute seule. Pour que cette propriété exposée soit exploitable il faut qu’elle prévienne de ses changements de valeur et qu’elle change réellement de valeur en cours de fonctionnement. Pour ce genre de situation il existe une interface qu’on retrouve partout, INotifyPropertyChanged. Il se trouve qu’un Behavior classique descend de Behavior qui lui-même hérite de BindableObject qui implémente déjà INPC, il suffit de s’en servir puisque les concepteurs des XForms ont eu  l’intelligence de mettre les méthodes afférentes à INPC en protected (donc disponibles pour les classes filles qu’on peut créer à partir de Behavior).

Finalement j’aurais pu appeler ce Behavior « bindable » mais cela aurait créer plus de confusion que de clarification (un Behavior est déjà un BindableObject par son héritage), pire, c’est déjà le nom donné à une autre catégorie de Behaviors que je vous présente un plus bas.

Pour aller plus loin, là encore je renvoie le lecteur au Chapitre 5 de mon livre. Une trentaine de pages ne pouvant tenir dans un simple billet de blog cela ne serait pas raisonnable.

Les Attached behaviors ou Bindable Behavior

L’appellation « Attached Behavior » est reprise de la documentation officielle mais elle ne me semble vraiment pas très pertinente.

Tous les behaviors sont « attached », c’est leur nature même de s’attacher à une vue !

Ici on parle de Behaviors qui exposent des propriétés de dépendance, il y a une confusion entre toutes ces notions que je trouve préjudiciable. D’autant qu’un simple Behavior comme ceux que je vous ai présentés peuvent aussi définir des propriétés de dépendance s’ils le veulent. Mais faisons fi des appellations non contrôlées et concentrons-nous sur la nature de ces Behaviors un peu particuliers qui finalement n’ont que peu de choses à voir avec les Behaviors que nous venons d’étudier.

Car en effet ici ce type de Behavior ne descend pas de la classe Behavior, il n’y a même aucun héritage du tout (en dehors de besoins propres à une application ou librairie donnée). Il ne s’utilise pas non plus de la même façon en XAML puisqu’au lieu d’apparaître dans la liste Behaviors de la vue il apparaîtra sous celle d’un attribut XML qui contient le nom de la classe ainsi qu’une propriété.

Quelle étrange bête ! Une fois cette différenciation clarifiée avec les Behaviors « traditionnels » et peu importe comment on les nomme, ce type de Behavior  est très utile car justement il fonctionne de façon différente et pourra ainsi servir des besoins différents. Les « Attached Behaviors » (je ne vous embrouillerai pas plus en utilisant un nom différent de la documentation) se définissent sous la forme d’une classe statique. A ce titre toutes les propriétés et méthodes seront donc statiques ce qui interdit la gestion d’un état local. Le code d’un tel behavior est donc systématiquement stateless.

Là encore, et je m’en excuse par avance, je vous renvoie au livre car il serait bien trop long de traiter tous les exemples du livre dans ce billet dont l’objectif est de vous permettre de comprendre ce que sont les Behaviors et les Triggers, le livre est bien plus proche d’une formation où on parle en journées et non en minutes de lectures rapide. Mais cela ne veut pas dire que je ne reviendrai pas dans Dot.Blog ou même Dot.Vlog sur tous les exemples et détails que j’ai été obligé d’omettre dans le présent papier.

Les Triggers

Triggers et Behaviors sont généralement étudiés à la suite car bien que de nature différente ils peuvent dans certains cas avoir des champs d’application proches voire se recouvrant. Pourtant il s’agit bien de deux concepts distincts comme vous allez le constater.


Qu’est-ce qu’un « trigger » ?


Au sens propre un trigger c’est un déclencheur. On comprend facilement que pour qu’il y ait déclenchement il faut qu’il y ait une condition à celui-ci (sinon le trigger serait tout le temps déclenché ou l’inverse et cela n’aurait aucun intérêt). On envisage tout aussi logiquement que cela doit mener à une forme d’action. Un interrupteur mural qui ne serait pas connecté à une ampoule ou autre objet électrique pour l’allumer ou l’éteindre n’aurait pas non plus grand intérêt.


Donc un trigger c’est l’association d’une condition et d’une action. Quand la condition est vérifiée l’action est exécutée.
On pense souvent, et toujours à raison, que lorsque la condition n’est plus vérifiée l’action entreprise s’arrête voire que les choses reviennent à leur état précédent. Il n’y a rien de vraiment logique à cela (on associe mentalement le trigger à un bouton mural alors que la notion de déclencheur est plus proche de celle d’un bouton poussoir) mais il se trouve que l’intuition est bonne… Lorsque la condition s’arrête d’être vraie XAML redonne à chaque propriété modifiée par le trigger la valeur qu’elle avait juste avant. Magie du moteur de gestion des propriétés de dépendance . Vous pouvez reprendre l’un de mes anciens articles sur ce sujet crucial en XAML (Les propriétés de dépendance et les propriétés jointes sous WPF, PDF à télécharger), et dans le Tome 7 de AllDotBlog sur XAML (Livre gratuit à télécharger).

Il existe plusieurs types de triggers supportés par les XForms :

  • Les property triggers
  • Les data triggers
  • Les event triggers
  • Les multi triggers


A la différence des Behaviors qui réclament de déclarer une classe spécifique pour exister et fonctionner les triggers, en tout cas les formes les plus simples, fonctionnent directement sans aucun code à écrire autre que la déclaration du trigger en XAML.

Les property Triggers

Comme leur nom le laisse supposer ces triggers sont très liés aux propriétés d’un objet, celui sur lequel ils sont déclarés.

La condition porte sur une propriété de l’objet et l’action consiste à changer la valeur d’une autre propriété du même objet.

L’exemple le plus simple consiste à modifier l’apparence d’une vue quand elle a le focus.

Si sa propriété IsFocused est vraie on change le style de la vue, sa couleur de fond, sa fonte…

Généralement les OS ont leur propre façon d’effectuer cette mise en valeur de l’objet qui a le focus, vouloir interférer avec ces mécanismes propres à chaque plateforme n’est pas en soi une bonne idée. Toutefois comme IsFocused est la seule propriété d’une vue qui puisse changer toute seule en cours d’utilisation c’est un excellent candidat pour une démonstration qui reste simple !

Modifier l’aspect visuel d’une vue n’est pas évident avec les XForms, d’abord parce que les vues ne sont que des façades remplacées à l’exécution par de vrai contrôles natifs. Il n’est donc pas possible par exemple d’ajouter une bordure à une vue qui n’en a pas et encore moins donc de jouer sur les propriétés de celle-ci comme on peut le faire avec les autres versions de XAML. En tout cas de base dans le code partagé (il existe de nombreuses techniques permettant d’interagir avec le code Natif sous Xamarin.Forms).

Ensuite et comme j’ai déjà eu l’occasion de le dire il faut être très prudent dans un projet cross-plateforme, sur une machine le thème sera clair, sur une autre foncé, on ne peut pas le savoir (à moins de le forcer ce qui pose un problème vis-à-vis des préférences de l’utilisateur). En raison du premier point évoqué ici il ne nous reste plus que la couleur d’avant-plan ou d’arrière-plan pour créer un changement visuel, or cela n’est pas une bonne idée. Changer un fond par du jaune sur une machine utilisant un thème foncé ressortira certainement bien, mais la fonte ne sera plus lisible puisqu’elle sera certainement de couleur claire (et inversement sur une machine qui utilisera un thème clair). Ne reste plus que l’opacité. Et je vous propose un raisonnement un peu inversé, au lieu de mettre en évidence la zone qui a le focus il faut mettre en retrait toutes les autres. Visuellement cela revient au même mais la logique est différente et atténuer des zones fonctionne à coup sûr quel que soit le thème (ou presque, les généralisations valent ce qu’elles valent et les contre exemples sont là pour le rappeler !).

Pour cela je vais atténuer l’opacité des zones Entry d’une fiche, et celle qui aura le focus sera modifiée pour reprendre son opacité naturelle. La propriété Opacity est un double qui prend une valeur de zéro (totalement transparent) à 1 (totalement opaque). Ce qui donne le code suivant en supposant les deux champs de saisie sont dans un StackLayout non montré ici :

image extraite du livre page… 134 ! vous avez gagné !

Tout comme les Behaviors se déclarent dans une liste spécifique de la vue (portant le nom de Behaviors) les triggers se déclarent dans leur propre liste logiquement nommée Triggers. Plusieurs propriétés doivent être renseignées :

  • TargetType  qui est le type de l’objet sur lequel le trigger est déclaré;
  • Property qui indique le nom de la propriété à surveiller;
  • Value qui est la valeur particulière que la propriété doit avoir pour que le trigger se déclenche.

Ensuite à l’intérieur de la balise Trigger on peut définir plusieurs balises Setter qui expose les propriétés :

  • Property, le nom de la propriété à modifier;
  • Value, la nouvelle valeur à donner à la propriété.


S’il ne peut y avoir qu’une seule condition (déclarée dans la balise Trigger) il est possible en revanche de déclarer plusieurs balises Setter et donc de modifier plus d’une propriété à la fois qui toutes reprendront leur valeur précédente lorsque la condition du trigger cessera d’être vraie. La condition testée par un Trigger est une égalité stricte. Cela signifie que poser des conditions sur des dates ou des nombres décimaux risque fort d’échouer car les représentations mémoires des nombres à virgules ne « tombent pas rond ». Un classique en informatique que je n’expliquerai donc pas mais qu’il est bon de rappeler pour éviter les déboires.
Les Triggers, tout comme les Behaviors peuvent être utilisés dans des définition de style (sujet qui est abordé en détail dans un autre chapitre du livre).
Ils peuvent aussi définir d’autres actions à réaliser en entrée ou en sortie d’un changement dans la condition et cela par des balises EnterActions et ExitActions. Le livre en donne des exemples commenté.

Les Data Triggers

Les Data Triggers fonctionnent comme les property triggers à l’unique différence qu’ils sont ouverts au monde extérieur à la vue concernée. Avec les property triggers vu précédemment condition et action sont liées aux seules propriétés de la vue qui définit le trigger.

Avec les data triggers si les Setter ne concernent toujours que les propriétés de la vue la condition peut, elle, se lier par binding à la propriété d’une autre vue (ou du ViewModel associé à la page en MVVM). Une vue peut ainsi voir son état modifié selon l’un des états d’une autre vue. Un Label peut par exemple devenir visible si la longueur d’un texte à saisir est à zéro.

Les limitations imposées par le test d’égalité dans la condition d’un trigger peuvent parfois être gênantes. Mais le data trigger grâce à son binding peut fort bien pointer une propriété spécialement taillée pour l’occasion et se trouvant dans le ViewModel attachée à la page. Même s’il faut essayer de ne pas exposer dans les ViewModels des propriétés conçues spécifiquement pour jouer sur l’UI cela n’est qu’un guide, une perfection qui parfois ne peut être atteinte. Et dans le cas présent une telle astuce permet de créer des triggers dont la condition de déclenchement est bien plus sophistiquée qu’une simple égalité. Gardez cela dans un coin de votre mémoire cela vous servira tôt ou tard !

Les Event Triggers

Les property triggers travaillent sur les propriétés d’un objet, tant côté condition que des changements autorisés. Les data triggers autorisent que la condition puisse puiser sa source dans un binding sur un objet extérieur à celui qui est modifié.
Les event triggers changent eux aussi la nature de la condition. Celle-ci devient un évènement de l’objet. Mais ils changent totalement la façon d’agir. Plus de setters mais une classe qui sera instanciée et activée en recevant l’instance de l’objet concerné.
Cela ouvre des horizons nouveaux. Pouvoir réagir à un évènement d’un objet permet d’agir sur un clic, un changement de taille et même le réagencement des enfants de la vue (si elle en a).
Quant à l’action, s’agissant d’une classe elle possède tout le potentiel d’un code C# et permet de presque tout faire.
Si cela modifie la façon de déclarer et d’utiliser ce trigger un peu particulier il n’en est pas pour autant très compliqué à mettre en œuvre.

Une démonstration serait hélas hors portée de ce billet déjà mille fois trop long ! (Mais le livre donne bien entendu des exemples commentés.)

Les Multi Triggers

Les triggers bien que puissants sont limités par la façon assez rudimentaire de déclarer leur condition de déclenchement. Beaucoup militent depuis longtemps même sous WPF pour que soit ajouté un interpréteur pour gérer des conditions plus sophistiquées. Sans aller très loin, déclencher un trigger si la longueur d’un texte dépasse 140 caractères n’est pas possible. Si vous deviez réécrire Tweeter il faudrait utiliser autre chose !
A défaut d’une telle fonctionnalité les XForms nous offrent les multi triggers. Cela ne remplace pas exactement un interpréteur d’expression mais cela permet de complexifier un peu la condition de déclenchement.
En effet le multi trigger tire son nom du fait qu’il est possible de déclarer plusieurs conditions au lieu d’une. Toutes doivent être vérifiées pour que le trigger soit activé, c’est donc un ET logique qui les relie.
Pour le reste cela ressemble à un property ou un data trigger avec ses setters. Le multi trigger dispose d’une section Conditions, une liste de conditions qui accepte tous les autres types de triggers (property, event et data trigger).

Conclusion

Il y aurait encore plein de choses à dire sur les Behaviors et les Triggers... Mon livre traite le sujet plus en profondeur avec des exemples commentés ce qui se rapproche plus d'une vraie formation que ce billet bien trop long que j'aurais du segmenter si je faisais du clientélisme...
Mais ni pub ni rien de tout cela sur Dot.Blog, ni monétisation sur Dot.Vlog.
Alors si vous n'avez pas encore acheté mon livre vous savez ce qu'il vous reste à faire :-) Et si vous l'avez déjà (ce dont je vous remercie) n'hésitez pas à en faire la promo autour de vous c'est tout aussi important !


Stay Tuned !

Catégories: Dévelopement

Dot.Vlog : Les behaviors sous Xamarin.Forms

Dot.Blog - mar, 25/09/2018 - 00:28

Voici le numéro 2 de Dot.Vlog à consommer tout de suite sans modération ! …

Les behaviors avec les Xamarin.Forms


Le lien direct YouTube : https://youtu.be/tVIO0ZxLZ4o


Bon visionnage


Stay Tuned !

Catégories: Dévelopement

Le compas magnétique, démo des Xamarin.Essentials

Dot.Blog - jeu, 20/09/2018 - 22:49

Dans le dernier billet je vous parlais des Xamarin.Essentials, le mieux est de les voir à l’œuvre avec une démo et une surprise…

Les Xamarin.Essentials, démo

Dans le dernier billet je vous ai présenté les Xamarin.Essentials, ensemble d’API regroupant toutes (ou presque) les API dont on se sert habituellement pour des Apps mobiles et qui demandent malgré tout de mettre la main dans le code natif : gyroscope, compas magnétique, infos de la device, envoi de mail, etc…

Bien entendu on sait faire ce genre de choses depuis un moment et grâce à l’esprit des Xamarin.Forms on dispose même de plugins Nuget qui chacun expose l’une ou l’autre de ses API. Mais l’intérêt des Essentials est de tout regrouper dans un ensemble Open Source, gratuit, validé par Xamarin.

Un seul package donne accès à tout, classé par namespaces ou noms de classes très explicites.

Le mieux pour s’en rendre compte, et aussi pour le plaisir de faire du Xamarin.Forms (!) c’est une petite démo…. Et c’est la que se trouve la surprise !

Lancement de Dot.Vlog

Pour les 12 ans d’existence de Dot.Blog (lancé en 2007) et mes 10 ans de MVP il fallait marquer le coup. Bon rien d’extraordinaire non plus, je fais un peu de com là… mais tout de même.

Les tendances de l’époque sont ce qu’elles sont et pour un bloggeur il faut en tenir compte quoi qu’on en pense. Et la tendance principale c’est la consommation de plus en plus énorme de vidéos notamment sur Youtube au détriment de beaucoup d’autres formes de communication.

C’est pourquoi ce billet n’en sera pas un mais sera livré sous la forme d’un Vlog.

J’ai déjà produit des tas de vidéos, donc rien de très nouveau, mais une différence de taille quand même : les vidéos était jusqu’ici des présentations à part de Dot.Blog, n’ayant ni rythme de sortie particulier ni même de thème de prédilection prévisible, cela pouvait être le design comme la programmation asynchrone, c’était au gré de mes envies.

Ce qui change c’est que maintenant les articles de Dot.Blog seront produits soit sous forme de billets soit sous forme de Vlog, avec un nom qui tombe sous le sens : Dot.Vlog.

C’est un petit changement d’apparence mais c’est un grand changement de fond qui va m’obliger à produire plus de vidéos, et à découper ma communication entre billets classiques et vidéos, ce qui n’est pas évident.

Pour cette première les choses allaient d’elles-mêmes. En effet la partie démo, assez visuelle, des Xamarin.Essentials se prêtait assez bien à format Vlog alors que la présentation générale faite dans le dernier billet était mieux rendue par le blog.

Bien entendu pas mal de choses restent à mettre en place (par exemple changer de webcam dont la qualité ne se prête pas à l’exercice, la durée des vlogs, la façon de les présenter…), mais je compte aussi sur vous pour me dire ce que vous en pensez, votre avis sont importants.

Dot.Vlog 1ère Clap !

Assez parlé (enfin “écrit” !) et place justement à la parole vivante et au premier numéro de Dot.Vlog. Bon visionnage !

Si le lecteur de YouTube ne s’affiche pas correctement visionnez directement cet épisode sur ma chaîne : https://youtu.be/75H_TfgO-zY

Conclusion

Aimez-vous ce nouveau format ? Pourquoi ? Expliquez moi tout dans les commentaires !

Et….

Stay Tuned !

Catégories: Dévelopement

Xamarin Essentials pour les besoins … essentiels !

Dot.Blog - dim, 16/09/2018 - 21:32

Il est temps de retrousser les manches le ramollissement des neurones pendant les vacances suivi du rush de la rentrée méritait de vous laisser vous y remettre en douceur ! Au programme aujourd’hui une belle librairie gratuite et une célébration ! de quoi ? ….

Célébration

Commençons par la fête !

Car après les joies des vacances et le dur retour à la réalité du boulot chacun de nous est un peu chargé de nostalgie, on a encore un peu de sable dans le fond de nos chaussures, le bronzage commence déjà à partir (tout ça pour ça…) et même l’été qui joue les prolongations, ce qui aurait été un motif de joie il y a 30 ans, ne fait que nous rappeler que l’épée de Damoclès du réchauffement climatique juste là, au-dessus de nos têtes, se rapproche dangereusement…

Difficile d’être totalement joyeux donc. Heureusement qu’il reste C# et XAML !

Et justement à ce sujet je voulais célébrer avec vous mes 10 ANS de MVP. 10 ans de présence, des milliers de billets, de pages, de livres plus loin, c’est un gros boulot qui a été fait !

Alors ça vaut bien un petit sourire

D’autant que ce n’est pas terminé ! Merci de votre fidélité.

Xamarin.Essentials

Depuis quelques mois se trame quelque chose d’intéressant dans le monde Xamarin : la mise à disposition d’une librairie aussi officielle que gratuite, Xamarin.Essentials.

Nous en sommes toujours au stade preview, la première version releasée, la 0.6.0, datant d’il y a quatre mois, la 0.10.0 d’un mois. C’est donc du tout frais et la peinture n’est pas encore sèche. Le mur lui-même n’est pas encore fini de construire d’ailleurs puisqu’on ne sait pas quand la version 1.0 sera mise en ligne.

Qu’est donc que Essentials ?

Xamarin est déjà un outil fantastique qui permet lorsqu’on développe du code cross-plateforme ou qu’on cible directement iOS ou Android de le faire entièrement en C# sous .NET. C’est un avantage décisif pour tous les devs connaissant ce langage et cette plateforme. Xamarin offre tout cela et bien plus puisque sur chaque plateforme on peut accéder toujours en C# à toutes les API natives.

Traditionnellement Xamarin se décline deux versions Android et iOS (Tizen et Mac sont venus après) pour attaquer directement ces OS mais aussi sous le nom de Xamarin.Forms pour sa version cross-plateforme totalement unifiée.

Tout cela est génial, rien de cette nature n’existe ailleurs. Des bricolages divers et variés trouvent bien sûr ici et là une certaine clientèle, mais rien ne peut égaler la souplesse et la puissance de ce que Xamarin nous offre grâce à C#, .NET et même XAML. Essayez juste de transposer trois lignes de LINQ dans un langage non .NET et vous comprendrez ce que revenir au moyen-âge veut réellement dire !

Bref nous sommes heureux et gâtés. Mais si Xamarin nous offre tout ce qu’il faut pour coder et même pour accéder aux API natives, il reste parfois du travail à faire pour accéder à des features qui réclament alors de mettre les mains dans le cambouis de chaque OS. Pourtant ce sont des besoins… essentiels !

Grâce à la philosophie de plugins de VS et Xamarin, de tels plugins existent pour nous simplifier la vie.

Mais pour l’essentiel ?

Pour l’essentiel il existe donc maintenant Xamarin.Essentials !

L’API de Xamarin.Essentials

Le principe est d’offrir toutes les API indispensables pour créer des applis mobiles. Les choses dont on a besoin souvent et qu’il est fastidieux d’aller bricoler en natif alors que cela revient tout le temps et qu’une bonne librairie bien faite et maintenue pourrait nous éviter de le faire. Cela évite aussi de piocher dans 50 packages Nuget différents juste pour récupérer un ensemble de fonctions si souvent utilisées.

C’est l’esprit même des Essentials…

La première preview proposait 25 API standardisées, nous devons avoir dépasser la trentaine dernièrement et cela ne fera que grossir au fil du temps.

Alors que trouve-t-on dans Xamarin.Essentials ?

La liste des API est un peu sèche à gober toute crue, mais rien ne vaut une liste pour tout voir rapidement… Alors voici les API dont on dispose (sachant que cela n’a rien de définitif) :

Chaque lien renvoie vers la doc officiel pour que vous puissiez facilement regarder le détail d’une API qui vous intéresse.

Conclusion

On va reprendre en douceur… ça sera tout pour aujourd’hui et je reviendrai certainement sur certaines API plus en détail bientôt, le stockage des fichiers par exemple est assez “essentiel” pour qu’on creuse un peu plus la question ! En revanche je vous laisserai découvrir l’API de la torche tous seuls

Stay Tuned !

Catégories: Dévelopement
S'abonner à Sleepy SME agrégateur - Dévelopement