Dot.Blog

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

Le Web 3.0 = Pas de Web ?

[new:30/05/2012]En attendant de pouvoir sérieusement vous parler de WinRT, je m’intéresse beaucoup en ce moment à l’avenir du développement, tant pour les développeurs que les éditeurs dans la période très troublée que nous vivons depuis deux ans. Depuis plusieurs mois je vous fais part de mes observations, de mes doutes, de mes conseils et j’espère vous aider par mes réflexions à vous forger votre propre opinion. Souvent en décalage avec la pensée unique de l’instant, mes prévisions choquent parfois certains lecteurs. Force est de constater que le Web, donc HTML, a des soucis à se faire et j’en veux pour preuve de nombreux évènements qu’il faudrait être fou d’ignorer...Plus...

HTML 5 : la tragique fin d’un buzz

[new:30/04/2012]HTML 5, l’un des plus gros buzz sur du vaporware des vingt dernières années... Ce buzz prend fin de façon tragique. Il faut rapidement s’en rendre compte pour prendre les bonnes décisions pour le futur de vos développements !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 3 : Styles Cascadés (BasedOn Styles)

Toujours dans ma petite série sur les nouveautés de Silverlight 3 je vais vous présenter aujourd'hui une feature plaisante : les styles cascadés.

En soi rien de nouveau à l'ouest puisque c'est le principe même des feuilles de styles CSS (qui y puisent d'ailleurs leur nom). Mais le CSS s'applique à quelques éléments simples HTML alors que là nous parlons de styles Silverlight, c'est à dire d'objet complexes pouvant définir tout un visuel, animations comprises.

[silverlight:source=/SLSamples/BasedOnStyle/BasedOnStyle.xap;width=405;height=150]

Dans l'application Sivlerlight 3 ci-dessus (fonctionnelle, ce n'est pas une capture écran), vous voyez 4 boutons. Tous sont des boutons standard du framework.

  • Le premier, intitulé "Base SL" possède le style Silverlight par défaut
  • Le second, "Normal" est décoré par le style "BoutonNormal"
  • Le troisième "Gros" est décoré par le style "BoutonGros"
  • Et le quatrième "Alarme" est décoré par le style "BoutonGrosAlarme"

Visuellement c'est plutôt moche, je vous l'accorde, mais le but du jeu est de voir l'effet du cascading styling...

Le style "BoutonNormal" est défini comme suit :

<Style x:Key="BoutonNormal" TargetType="Button">
     <Setter Property="Width" Value="90" />
     <Setter Property="Height" Value="30" />
     <Setter Property="HorizontalAlignment" Value="Left" />
     <Setter Property="VerticalAlignment" Value="Bottom" />
     <Setter Property="BorderThickness" Value="2"/>
</Style>

Là où les choses deviennent plus intéressantes, c'est dans le style "BoutonGros" ci-dessous où l'on voit apparaître l'attribut BasedOn qui permet de fonder le style courant sur celui qu'on indique :

<Style x:Key="BoutonGros" 
         BasedOn="{StaticResource BoutonNormal}"
         TargetType="Button">
  <Setter Property="Width" Value="180" />
  <Setter Property="Height" Value="60" />
  <Setter Property="FontFamily" Value="Comic Sans MS"/>
</Style>

Enfin, le dernier style se fonde lui-même sur le précédent par le même mécanisme, le niveau de cascading n'étant pas limité. On peut voir notamment que le changement de famille de fonte introduit dans le style "BoutonGros" s'est propagé au style "BoutonGrosAlarme" (fonte Comic).

<Style x:Key="BoutonGrosAlarme" 
         BasedOn="{StaticResource BoutonGros}"
         TargetType="Button">
  <Setter Property="Width" Value="160" />
  <Setter Property="Height" Value="40" />
  <Setter Property="FontSize" Value="18"/>
  <Setter Property="FontWeight" Value="Bold"/>
  <Setter Property="Foreground" Value="Red"/>
  <Setter Property="BorderThickness" Value="4"/>
  <Setter Property="BorderBrush" Value="#FFFF0202"/>
</Style>

Voilà, c'est tout simple, mais cela peut radicalement simplifier la création de gros templates pour des applications. Tous les avantages du Cascading Style Sheet de HTML dont l'intérêt ne se démontre plus, mais appliqué à des objets et à la sophistication de Silverlight. Que du bonheur...

Bon Styling,

...Et Stay Tuned !

Silverlight 3 : L'Element Binding

L’Element Binding est une nouvelle feature de Silverlight 3 déjà présente sous WPF.

L’Element Binding définit la capacité de lier les propriétés des objets entre eux sans passer par du code intermédiaire. Cette possibilité existait déjà sous WPF, on la retrouve désormais sous SL3.

Pour simplifier prenons l’exemple d’un panneau d’information, par exemple un Border avec un texte à l’intérieur. Imaginons que l’utilisateur puisse régler l’opacité de cette fenêtre par le biais d’un Slider. (ci-dessous l'application exemple pour jouer en live).

[silverlight:source=/SLSamples/EBinding/EBinding.xap;width=452;height=240]

On place quelques éléments visuels sous le Border (ici des rectangles) afin de mieux voir l’effet du changement d’opacité.

Trois méthodes s'offre à nous pour régler le lien entre le Slider et l'opacité du Border. J'appellerai la première "méthode à l'ancienne", la seconde "méthode du certifié" et la troisième "méthode Silverlight 3". Les trois ont leur intérêt mais si vous êtes très pressé vous pouvez directement vous jeter sur la 3eme solution :-)

Méthode 1 dite « à l’ancienne »

Le développeur Win32 habitué aux MFC ou à des environnements comme Delphi aura comme réflexe immédiat d’aller chercher l’événement ValueChanged du Slider et de taper un code behind de ce type :

MonBorder.Opacity = MonSlider.Value ;

Ça a l’avantage d’être simple, efficace, de répondre (apparemment) au besoin et de recycler les vielles méthodes de travail sans avoir à se poser de questions…

Méthode 2 dite « du certifié »

Ici nous avons affaire à un spécialiste. Son truc c’est la techno, suivre les guide-lines et écrire un code qui suit tous les dogmes de l’instant est un plaisir intellectuel. Parfois ses solutions sont un peu complexes mais elles sont belles et à la pointe de la techno !

Conscient que la solution « à l’ancienne » a un petit problème (en dehors d’être trop simple pour être « belle », elle est one way, le slider modifie l'opacité du border mais l'inverse ne fonctionne pas) il va chercher une solution objet élégante répondant à l’ensemble des cas possibles couvrant ainsi le two way, considération technique trop technophile pour le développeur du cas précédent.

Ici forcément ça se complique. C’est techniquement et intellectuellement plus sexy que la méthode « à l’ancienne » mais cela réclame un effort de compréhension et de codage :

Il faut en fait créer un objet intermédiaire. Cet objet représente la valeur du Slider auquel il est lié lors de son instanciation. Quant à l’objet Border, sa propriété Opacity sera liée par Data Binding standard à l’objet valeur.

Voici le code de la classe de liaison :

public class ValueBinder : INotifyPropertyChanged
       {
             public event PropertyChangedEventHandler PropertyChanged;
             private Slider boundSlider;
             public ValueBinder(Slider origine)
             {
                    boundSlider = origine;
             }
 
             public double Value
             {
                    get { return boundSlider==null?0:boundSlider.Value; }
                    set {
                           if (PropertyChanged!=null)
                                  PropertyChanged(this,
                                    new PropertyChangedEventArgs("Value"));
                           boundSlider.Value = value;
                    }
             }
       }

Cette classe, ou plutôt l’une de ses instances, servira a représenter la valeur courante du Slider. Ce dernier est lié à l’instance lors de la création de cette dernière (voir le constructeur de la classe ValueBinder ci-dessus).

Comment utiliser cette classe ?

La première chose est qu’il faut en créer une instance, cela peut se faire dans le code XAML ou bien dans le code behind de la façon suivante (dans le constructeur de la page par exemple) :

var valueBinder = new ValueBinder(slider);

Maintenant il suffit dans le code XAML de lier les deux objets à la valeur de la classe intermédiaire, par Data Binding :

Côté Slider, le code est :

<Slider x:Name="slider"Value="{Binding Value, Mode=TwoWay}"/> 

Côté Border :

<Border x:Name="borderInfo"Opacity="{Binding Value, Mode=TwoWay}"> 

Ne reste plus qu’à rendre visible l’objet intermédiaire par exemple en en faisant la valeur courante du DataContext de l’objet LayoutRoot :

LayoutRoot.DataContext = valueBinder;

Et voilà ! Ne reste plus qu’à compiler et vous le plaisir de voir que l’opacité du Border change bien lorsque le Slider est déplacé.

La chaîne est la suivante : la modification de la position du Thumb entraîne dans le composant Slider la modification de la valeur de la propriété Value. Comme celle-ci est liée par Data Binding TwoWay à la propriété Value de l’objet intermédiaire cette propriété va se trouver modifiée dans le même temps. Comme le Setter de la propriété notifie le changement de valeur de la propriété (la classe implémente INotifyPropertyChanged) et comme la propriété Opacity du Border est elle aussi liée par Data Binding à la propriété Value de l’objet intermédiaire, le Border sera « prévenu » du changement de valeur et sa propriété Opacité sera immédiatement modifiée pour recevoir la valeur courante de Value de l’objet intermédiaire ! C’est pas fun tout ça ? (hmmm j’en vois un qui suit pas là bas au fond… !).

Vous allez me dire, TwoWay, on veut bien te croire mais on ne le voit pas là … Pour l’instant cela se comporte exactement comme la première solution, juste qu’il faut avoir un niveau de certifié pour comprendre…

C’est pas faux. C’est pourquoi je vais maintenant ajouter un petit bout de code pour faire varier la valeur de la propriété Opacity du Border. Le plus simple est de gérer la roulette de la souris dans le Border :

<Border x:Name="borderInfo"MouseWheel="Border_MouseWheel"> 

Et dans le code behind :

private void Border_MouseWheel(object sender, System.Windows.Input.MouseWheelEventArgs e) 
             { 
                    borderInfo.Opacity += e.Delta/1000d; 
                    e.Handled = true;
             }

Il suffit maintenant de faire rouler la molette au dessus du Border pour en changer l’opacité. Le TwoWay ? Regardez bien : le curseur du Slider avance ou recule tout seul… Pour éviter que la page HTML contenant le plugin Silverlight ne se mette à scroller il faut bien entendu indiquer que l'événement est géré (Handled=true) ce qui est fait dans le code ci-dessus.

Cette solution est élégante, complète mais complexe. Elle reste l’approche à préconiser dans tous les cas du même type car, on le voit bien, si la première solution est simple, elle n’est pas complète. Complexifier par plaisir est un mauvais réflexe, mais ne pas voir qu’une solution est trop simpliste est aussi un défaut qu’il faut fuir !

Bref, sous Silverlight 2 la solution présentée ici est une bonne solution. Sous Silverlight 3 qui supporte le Binding direct entre éléments (comme WPF) nous allons pouvoir faire plaisir à la fois au développeur du premier cas et à celui du second :

Méthode 3 dite « Silverlight 3 »

Comment marier le reflexe (plutôt sain) du premier développeur de notre parabole de vouloir faire vite et simple avec l’exigence intellectuelle (tout aussi saine) du second qui implique de faire « complet » ?

Pour illustrer l’Element Binding de façon simple, prenons un Scrollbar en mode horizontal et un Slider en mode vertical.

Et regardons le code XAML de leur déclaration :

<ScrollBar x:Name="scrollA"Value="{Binding Value, ElementName=sliderB, Mode=TwoWay}"/> 
 
<Slider x:Name="sliderB"Value="{Binding Value, ElementName=scrollA, Mode=TwoWay}" /> 

Et c’est tout ce qu’il y a à faire pour obtenir une solution complète, élégante, sans code behind et très facile à mettre en œuvre ! Merci Silverlight 3 !

En début de billet vous pouvez jouer avec les deux dernières implémentations (je n’ai pas implémenté la méthode 1) .

Vous pouvez aussi télécharger le code du projet (Blend 3 ou VS2008 avec les extensions SL3) : elementBinding.zip (61,43 kb)

Pour d'autres nouvelles, Stay Tuned !

Xaml, l'ami des artistes

XAML, comme le savez, est au coeur de WPF et de Silverlight. Sa puissance, doublée par celle du Framework et de langages comme C#, en fait une machine de guerre sans équivalent pour qui veut développer des applications modernes, c'est à dire efficaces techniquement mais "lookées". 

Mais si XAML est l'ami des développeurs, il est aussi celui des artistes !
Il créé un lien entre deux mondes parallèles : celui des métiers IT et celui des métiers de l'art, graphisme, vidéo, son et musique.

Démontrer une nouvelle technologie est généralement assez facile, il suffit de se former et d'écrire un article et des exemples. Mais comment "démontrer" et rendre tangible ce lien immatériel entre informatique et art créé par XAML ?

Car une application aujourd'hui, en plus du fonctionnel, c'est aussi de l'image et du son. De l'interface, mais aussi de la "promo" visuelle, des vidéos, de la musique, des logos.

Evoquer ce lien entre art et technique, c'est la finalité de E-Naxos Art, une démo Silverlight 2 qui permettra peut-être de réveiller l'artiste qui sommeille en vous et vous inciter à vous lancer dans WPF et Silverlight si vous hésitez encore !

Pour l'instant l'application est en bêta et elle n'est pas encore très fournie. Il y a tout de même à voir des vidéos en 3D, des dessins et des bouts de sons ou de musiques. Tout cela sera complété au fil du temps.

Alors pour mieux comprendre le mariage entre "art" et technologie que matérialise XAML, bonne visite sur E-Naxos Art !

Et Stay tuned ! 

 

Article : Créer des Splash Screens sous Silverlight

Encore un article tout chaud à peine démoulé ! Le sujet aussi est brûlant : Avec l'arrivée prochaine de la version 3 Silverlight est un environnement qui a le vent en poupe... Puissant et hyper agréable à programmer, surtout accompagné de la suite Expression, Silverlight est un vrai plaisir.

Raison de plus pour savoir comment enrichir vos belles applications avec des Splash Screens originaux !

Comment ? Vous saurez tout en lisant ce nouvel article que je vous ai concocté : Conception de Splash Screens sous Silverlight (PDF 22 pages avec source des exemples VS 2008/Blend 2 sp1)

Bonne lecture !

 

(voir aussi le billet sur la façon de centrer un splash)

Centrer un splash screen personnalisé avec Silverlight

Silverlight... ma seconde passion avec LINQ... Faire de belles application sous SL est un plaisir, mais une belle application n'est terminée que lorsqu'elle dispose de son splash screen personnalisé. La "final touch" qui fait voir au monde que vous n'êtes pas du genre à vous contenter des comportements par défaut et que vous êtes un vrai développeur, un dur, un tatoué !

Je reviendrai dans un tutor sur la façon de créer un splash screen sous Silverlight [EDIT]voir l'article créer des splash screen sous Silverlight[/EDIT], ce n'est pas très compliqué mais il y a quelques étapes à bien comprendre. Partons du principe que vous avez déjà un beau splash screen. Donc une présentation sous la forme d'un fichier Xaml contenant la définition d'un Canvas avec plein de jolis choses dedans. C'est le format Silverlight 1.0 utilisé pour les splash screens.

Tout va bien, vous avez fait tout ce qu'il faut, mais quand vous lancez votre application le splash est affiché en haut à gauche ! Damned ! Alors on commence à bricoler. Certains vont tenter de fixer une taille plus grande au Canvas de base et de centrer les objets dedans. Pas glop! ça ne s'adapte que très mal à la largeur réelle du browser... D'autres vont plonger les mains dans JavaScript pour calculer dynamiquement la position du Canvas. Compliqué et fatiguant...

Je vais vous donner une astuce. Plus facile à mettre en oeuvre j'ai pas en stock. Le truc consiste simplement à englober votre Canvas dans une balise Grid sans paramètres !

Et oui, la Grid est utilisable dans un splash sous Silverlight 2. Voilà comment faire :

   1: <Grid>
   2:     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
   3:     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"  
   4:     >
   5:     <Canvas x:Name="MonSpash" ....... >
   6:     </Canvas>
   7:     </Grid>
   8: </Grid>

 C'est tout ! Votre splash, originellement dans le Canvas "MonSplash" (lignes 5 et 6) se trouve entourré par un Grid. Et le tour est joué, le splash apparait bien centré sur le browser quelle que soit ses dimensions.

Attention à un détail : Le fichier Xaml du splash est placé dans le l'application Web et non dans le projet Xap de Silverlight (normal sinon il serait chargé avec l'appli et ne pourrait plus servir de splash). Mais dans cette configuration Expression Blend ne reconnaît le fichier que comme un source Silverlight 1.0, du coup si vous voulez rouvrir le splash sous Blend ce dernier affiche une erreur, Grid étant du SL 2 et ne pouvant être root d'un fichier Xaml SL 1.0. Je vous recommande donc de placer le Grid une fois que vous aurez terminé la conception du splash sous Blend... Dans le pire des cas vous pouvez toujours supprimer la balise Grid, travailler sur le splash, et remettre la balise. C'est tellement simple que cela ne devrait vraiment pas gêner.

Pour voir un splash personnalisé centré, regardez l'application de démo : les Codes Postaux Français sous Silverlight. L'application a été mise à jour pour intégrer un splash.

 Et .. Splashhhh !