Dot.Blog

C#, XAML, Xamarin, UWP/Android/iOS

De Silverlight à WinRT (partie 1)

[new:30/08/2012]Quand on connait déjà Silverlight, la question qui se pose tout de suite est de savoir comment réutiliser au mieux son savoir-faire sous WinRT, ce qui implique de comprendre et connaître les différences principales entre les deux plateformes. Dans cette première partie j’aborderai les déclarations des espaces de noms, car sans eux, rien ne tourne. Plus...

Se préparer au “big shift” de la stratégie Microsoft

[new:31/12/2011]Tout le monde se souvient de cette petite phrase lâchée par Bob Muglia avant l’été “Our strategy with Silverlight has shifted”, ce qu’on traduirait par “notre stratégie à propos de Silverlight s’est déplacée”. Clair et nébuleux à la fois. La panique a envahi depuis le monde Silverlight, malgré la V5 qui va sortir très prochainement, la question devient “y-aura-t-il une V6 ?”. Mais je crois sincèrement que les vraies questions sont ailleurs. Microsoft a “shifté” sa stratégie, globalement, pas seulement autour de SL. Quelques éléments de réflexion pour mieux comprendre l’avenir. {Nota: le blog a subi une attaque qui a détruit ce billet et tous les commentaires, ceci est donc un nouveau post du même billet} Plus...

Silverlight vs Metro Style quel futur ?

[new:30/10/2011]Le //Build/ a eu lieu. Il devait répondre à toutes les questions concernant l’avenir de Silverlight. Hélas les choses ne sont pas si simples...Dégager une vision pour le futur semble poser problème à une majorité de développeurs et de décideurs. Essayons d’y voir plus clair.Plus...

Article : JOUNCE (Silverlight, MEF et MVVM)

[new:31/12/2011]Jounce... Cela fait un moment que je vous parle de l'article que je prépare sur le sujet... Ca a mis du temps, mais c'est un gros morceau ! Un framework MVVM "light" mais très subtile et bourré de bonnes idées. Au final un article de 110 pages environ et plus de dix applications exemples, mon record est battu !Plus...

Xaml intégré à l’OS sous Windows 8...

[new:15/07/2011]Les bruits courts, les esprits s’échauffent depuis l’annonce d’un Windows 8 dont les programmes seraient écrits en Html 5 + JS. La réalité est forcément différente et certainement bien moins catastrophique. Pour preuve ? L’équipe responsable de XAML vient d’être officiellement intégrée à l’équipe de développement Windows...Plus...

Conversion d’énumérations générique et localisation

[new:30/06/2011]Lorsqu’on travaille avec des énumérations il est très fréquent d’avoir à traduire leurs valeurs par d’autres chaines de caractères. Soit parce que les valeurs ne sont pas assez parlantes pour l’utilisateur, soit parce qu’il est nécessaire de localiser les chaines pour s’adapter à la culture de l’utilisateur.Il faut aussi ajouter les cas où les énumérations sont traduites en des valeurs d’un autre type (des couleurs par exemple) ce qui très courant avec le databinding.Plus...

Deux règles pour programmer Silverlight & WPF

Des règles et des bonnes pratiques pour développer des applications Silverlight il en existe bien plus que deux, faire croire le contraire ne serait pas honnête. Ne serait-ce que par la richesse des EDI utilisés (Visual Studio, Expression Blend, Expression Design…) il faut accumuler de l’expérience et mémoriser de nombreuses patterns pour architecturer et designer correctement une application.

Alors, en vrac, voici deux règles qui me passent par la tête et que je voulais vous communiquer:

Programmation par Templates

Sous Silverlight lâchez les vieilles habitudes. L’une de celles-ci que je rencontre souvent est celle qui consiste à se jeter sur son clavier pour créer un UserControl (ou un Control par héritage) dès qu’on a besoin d’un nouveau composant qui semble absent de la bibliothèque.

Erreur. Méthode du passé.

En effet, Silverlight et WPF impliquent des changements radicaux de mode de pensée et d’habitudes. Sous ces environnements, la majorité des besoins sont couverts par les composants existants, il “suffit” juste d’en modifier le template.

Nous sommes passés d’une programmation par héritage à une programmation par modèle (template).

Deux exemples pour bien cerner ce que j’entends par là.

Sticky Note

Prenons pour premier exemple un cas d’école, déjà ancien mais en plein dans notre propos : sticky notes pour WPF (sticky notes listbox). Ce “composant” se présente comme une liste verticale de petites notes de type “post-it” légèrement décalées les unes par rapport aux autres.

L’effet est sympathique et donne un peu de fantaisie et de vie à ce qui ne serait qu’une liste rectangulaire dans une grille en programmation classique.

Ce magnifique “composant” n’utilise aucun code “'classique”. Inutile dans les sources de chercher la classe StickyNotes qui hériterait de Control ou même de chercher dans les fichiers de l’application le UserControl créé pour l’occasion.

Rien de tout cela.

Sticky Notes est créé uniquement en jouant sur le templating d’une simple… Listbox ! Une poignée de Xaml et des templates, c’est tout.

Language button

Dernièrement dans une application Silverlight je devais implémenter un bouton permettant de choisir depuis la page d’accueil la langue à utiliser (français ou anglais). Forcément on pense à un ToggleButton ou quelque chose d’équivalent (ce qui n’existe pas de base). On pourrait aussi associer deux RadioButton dans une grille.

Mais le plus intéressant consiste à se demander “quel control existant se rapproche le plus du comportement que je souhaite implémenter”. En y réfléchissant quelques secondes on s’aperçoit assez vite qu’une CheckBox possède deux états stables (oublions ici l’état indéterminé). Ce composant comporte toute la logique et les états visuels permettant de gérer deux états.

Par défaut une CheckBox c’est une case à cocher avec un bout de texte devant ou derrière.

Le plus dur consiste à se l’imaginer comme deux drapeaux (français et US) côte à côte, celui qui est sélectionné étant à 110% de sa taille et l’autre à 50%. Par convention arbitraire et chauvinisme inconscient certainement j’ai considéré que IsChecked = True était le Français, à False l’anglais. En partant d’une CheckBox que j’ai totalement vidée de son contenu, et en ajoutant les deux drapeaux (et quelques autres ingrédients et animations via le VSM) j’ai obtenu un merveilleux “ToggleButton” sans jamais “sous-classer” le moindre contrôle. Juste en écrivant un template.

Le ViewModel de la page d’accueil offre une propriété IsFrench de type booléen qui est simplement bindée à la propriété IsChecked du CheckBox (en mode TwoWay) et l’affaire est jouée !

Règle 1 : De l’héritage au templating

La programmation Xaml (Silverlight / WPF) est une programmation visuelle qui s’effectue par templating. Créer des UserControl et encore plus sous-classer des contrôles existants devient quelque chose de rarissime.

Nous sommes passés de l’ère de la programmation objet par héritage à celle de la programmation visuelle par templating. Bien comprendre toute la signification de ce changement est un point primordial et un préliminaire indispensable pour comprendre cette technologie et donc la programmer intelligemment.

Programmation par Properties

Il s’agit du même genre de glissement, une pente douce mais dont la longueur finit par conférer une vitesse tellement grande à celui qui s’y laisse glisser que le décor n’a plus rien à voir avec celui qu’on a tout le temps d’admirer en balade à dos d’âne…

Dans l’exemple précédent on touchait du doigt cette nouvelle approche mais sans la mettre en exergue.

En effet, dans la pattern M-V-VM plutôt que de créer un code incompatible avec le visuel d’un côté pour ensuite créer de l’autre des tripotés de convertisseurs (programmation classique non M-V-VM sous WPF et Silverlight dans une moindre mesure) il semble bien plus simple d’exposer dans les ViewModels des propriétés directement exploitables par l’UI. Si adaptation des données il doit y avoir c’est le ViewModel qui s’en charge (directement si cela est ponctuel, ou via une classe de service si la chose doit être réutilisées ailleurs).

Dans l’exemple précédent du Checkbox transformé en ToggleButton de langue, aucun événement n’est programmé, aucun gestionnaire n’est écrit pour réagir au clic. Tout se joue dans le ballet automatique de IsChecked de la CheckBox et de IsFrench du ViewModel sous l’égide discrète mais indispensable d’un binding two way…

Quant l’utilisateur clique sur la CheckBox (enfin sur le ToggleButton avec les deux drapeaux) le composant sous-jacent bascule sa propriété IsChecked à vrai ou faux selon le cas. Comme cette dernière est liée à IsFrench du ViewModel, une propriété de type booléen aussi pour assurer la compatibilité des comportements, le ViewModel reçoit pas un événement mais l’une de ces propriétés (IsFrench) se voit modifiée. Ce qui déclenche le Setter de cette dernière. Ce dernier s’occupant de modifier le fichier de ressource utilisé pour puiser les chaines de caractères. De là et par une série de notification de changement de propriétés, il avertit en retour la Vue que toutes les propriétés de type texte ont été modifiées. La vue (et ses binding) y réagit en rafraichissant les affichages…

Toute cette mécanique s’est déroulée sans aucun gestionnaire d’événement, sans aucune programmation “classique” (en dehors du ViewModel et de ces propriétés gérant INotifyPropertyChanged, ce qui peut être automatisé ou simplifié en utilisant Mvvm-light par exemple).

Règle 2 :  de l’événementiel à binding

La seconde règle d’or à bien comprendre pour tirer totalement partie de Xaml et de ses enfants (Silverlight et WPF) est ainsi d’opter pour un modèle de développement de type Model-View-ViewModel se basant presque exclusivement sur des couples de propriétés mis en relation via binding.

On est passé de l’ère du développement dit “événementiel” des premières versions de Windows à ce qu’on pourrait appeler la “programmation par Binding” ou par “properties”.

Conclusion

Pour résumer :

Règle 1 on cherche à templater des contrôles existants sans créer des UserControl ni dériver des contrôles existants.

Règle 2 : on base la dynamique de l’application sur le binding entre propriétés et non plus sur les gestionnaires des événements des contrôles.

Si vous avez déjà fait vôtre ses règles alors vous allez devenir, si ce n’est pas déjà le cas, de très bons développeurs Silverlight et Xaml très recherchés !

Si vous n’aviez pas encore vu les choses sous cet angle là, je serai très heureux si par chance j’ai réussi à tirer le voile qui vous empêchait de les voir ainsi. Vous ne ferez qu’entrer plus vite dans la catégorie précédente !

Bon Dev, et, œuf corse,

Stay Tuned !

Xaml Dynamique

Xaml n’est pas compilé, ce qui signifie que le runtime l’interprète à l’exécution. Cet interpréteur est donc présent aussi bien quand on exécute une application WPF que Silverlight. Cela peut permettre des choses intéressantes comme la création de code Xaml dynamiquement au runtime…

Cette possibilité n’est que peu souvent évoquée alors que dans certains cas elle autorise de dynamiser tout ou partie d’une interface. Rien n’interdit en effet de créer une mise en page complète par ce procédé, VSM et animations comprises. La génération de Vues (partielles ou totales) en fonction d’une description paramétrée par l’utilisateur fait partie des cas concrets où de la génération dynamique de code Xaml peut grandement simplifier la mise en œuvre du code.

Le potentiel est grand, il suffit juste de savoir que cela existe car techniquement cela est finalement très simple. L’essentiel tient dans XamlReader.Load() qui sait rendre un objet à partir d’un code Xaml.

Pour sortir des sentiers battus, voyons comment on peut utiliser cette stratégie pour créer dynamiquement un composant à partir de son nom de classe non pas en utilisant la réflexion sous C#, juste en générant du code Xaml…

L’exemple live ci-dessous permet de créer un contrôle (pré-saisi par défaut pour un textBlock) qui sera ajouté dans un StackPanel dans la seconde moitié verticale de l’affichage. Créez plusieurs TextBlock de cette façon en modifiant le texte ou d’autres paramètres. Puis créez-en un auquel vous ajouterez dans les paramètres: Name=’Test’. Enfin cliquez sur le bouton “changer couleur des TextBlock”.

Tous les TextBlocks créés passeront en Foreground noir, et celui qui a pour non ‘Test’ vera sa taille de fonte augmentée de 4.

[silverlight:source=/SLSamples/DynXaml/DynamicXaml.xap;width=480;height=400]

Le code de création du contrôle est le suivant :

namespace DynamicXaml{    
public static class DynamicXamlHelper
{
public static UIElement CreateControlFromName(string controlName, 
string controlNamespace, string xmlnsPrefix, string properties)
{
var sb = new StringBuilder();
sb.Append("<" + controlName + " xmlns");
if (xmlnsPrefix.Length > 0) sb.Append(":" + xmlnsPrefix);
sb.Append("=\"" + controlNamespace + "\" " + properties + "/>");
try
            { return (UIElement)XamlReader.Load(sb.ToString()); }
catch
            {
return null;
}
}
}
}

Les paramètres sont ceux que vous pouvez taper dans les textBox de l’exemple live ci-dessus:

Pour le reste, le plus simple est jouer avec le code source de l’exemple : DynamicXaml.zip (7,08 kb)

Article ! Le Binding Xaml, sa syntaxe, éviter ses pièges… (WPF/Silverlight)

imagePromis dans mon dernier billet, le voici enfin ! Ce nouvel article dédié au binding Xaml pèse 77 pages (le record était tenu jusqu’à lors par mon article M-V-VM avec Silverlight avec 70 pages) et se présente sous la forme d’un PDF et de 9 projets exemples.

Le binding cet inconnu … J’en parlais dans mon billet Le retour du spaghetti vengeur, le binding avec sa syntaxe pleine d’accolades et de chaînes de caractères non contrôlées à la compilation est un piège à bugs et la porte ouverte au code spaghetti.

Plutôt que de me lamenter et vous laisser vous embourber dans la sauce de ces spaghetti là, j’ai pris ma plume, et voici le résultat : 77 pages sur le binding Xaml, son fonctionnement, ses différentes syntaxes le tout illustré par des exemples clairs. L’article aborde aussi le débogue du binding assez délicat puisque Xaml échappe au débogueur de Visual Studio, et que le binding n’est que partiellement couvert par Intellisense.

Des conseils, du vécu, beaucoup d’exemples, voilà ce que vous trouverez dans cet article à télécharger en suivant le lien suivant :

Le Binding Xaml – Maîtriser sa syntaxe et éviter ses pièges (WPF/Silverlight)

(Attention, avant de cliquer sur le bouton “télécharger” attendez que la fiche détail de l’article soit bien affichée, sinon le site pensera que vous tentez un accès à une ressource non publique et vous demandera un login… Je reçois tous les jours des demandes d’ouverture de compte provenant de lecteurs trop impatients qui cliquent trop vite sur le bouton ! La prochaine version du site en Silverlight est en préparation et corrigera ce petit problème, mais d’ici là : slow down cowboy !).

Pour vous aider à vous faire une idée du contenu de l’article voici son sommaire :

Sommaire

  • Références    5
  • Code Source    6
  • Préambule    7
  • Le Binding Xaml : Ange ou Démon ?    7
    • Le Binding    8
    • Définition    8
    • Utilisations    9
    • Schéma du principe    9
    • Déclaration    10
      • Par code    10
      • En Xaml    11
  • Les modes de binding    13
    • Le mode OneTime    13
    • Le mode OneWay    13
    • Le mode TwoWay    14
      • Gestion du timing    14
    • Le mode Default    16
    • Le mode OneWayToSource    16
  • Hiérarchie de valeur    18
    • Règles de précédences    19
  • La notion de  DataContext    20
  • Les convertisseurs de valeur    21
    • Définition    21
    • Scénario    21
    • Implémentation    22
    • Utilisation    23
      • Instanciation    23
      • Invocation    23
      • Bonnes pratiques    24
      • Pour résumer    26
  • Les dangers du Binding    27
    • Des chaînes non contrôlées    27
    • Un langage dans le langage    28
  • On fait quoi ?    28
  • Déboguer le Binding    28
    • Vigilance    28
    • Une code Xaml court    29
    • Refactoring sous contrôle    29
    • Utiliser des outils intelligents    29
    • Utiliser Expression Blend    29
    • Vérifier les erreurs de binding dans la fenêtre de sortie    30
    • Créer un fichier des erreurs de Binding    30
    • La feinte du convertisseur inutile    32
    • Quelques outils supplémentaires    33
      • Spy++    33
      • ManagedSpy    33
      • Snoop    34
      • Mole    34
      • Reflector    34
      • Vos neurones    34
  • Les syntaxes du Binding    34
    • Le binding simple    34
      • Binding direct    35
      • Binding sur une propriété    35
      • Binding sur une sous-propriété du contexte    36
      • L’Element Binding    37
      • Convertisseurs de valeur    37
        • Paramètres de conversion    38
      • StringFormat    40
        • Injection de culture    41
        • Le ContentStringFormat    42
        • Gérer les nuls    43
    • Le Binding Multiple    44
      • La classe Personne    44
      • Le code du multi convertisseur    45
      • Le code Xaml    46
    • Le Binding XML    47
      • Binding sur une source Web    47
      • Binding sur une source XML en ressource    48
      • Binding sur une requête Linq To XML    49
    • Le Binding Relatif    52
      • Binding to Self    52
      • Le TemplatedParent Binding    53
      • Le Binding sur recherche d’ancêtre    54
      • Le Binding PreviousData    56
        • La source de données    58
        • La visibilité des flèches : la magie de PreviousData et du Binding Multiple    58
        • Le contenu des textes    61
      • Le Template binding    61
        • Utilité    61
      • Le Collection Binding    67
      • Le Priority Binding    69
  • Les propriétés de tous les bindings    74
  • Conclusion    76

Avril est froid et pluvieux mais les soirées rallongent, c’est le printemps même si cela n’y ressemble pas encore beaucoup, grâce à moi vous savez maintenant comment occuper vos soirées et vos weekend au lieu de faire l’idiot dans les embouteillages des vacances : Lisez cet article !

Et Stay Tuned !