Dot.Blog

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

Windows 8 : créer des tuiles vivantes (live tile)

[new:09/11/2012]Les tuiles, éléments emblématique du look Modern UI (ex Metro Style) et donc de Windows 8 sous toutes ses déclinaisons (PC, tablettes, et Smartphones). Plus que de simples icônes, les tuiles sont facétieuses, changeantes, en un mot vivantes. Comment en tirer partie dans vos apps ?

La tuile

image

La tuile est la base du menu tactile de Windows 8. Comme on le voit sur la capture ci-dessus elle peut revêtir différentes formes. Il faut déjà différencier deux types de tuiles :

  • La tuile-icône. Elle ne fait que reprendre l’icône d’une application Windows classique et l’affiche dans un carré. C’est la moins belle des tuiles, la plus passive, mais elle n’est là que pour assurer la compatibilité avec les anciennes applications. Dans la capture on reconnaît la tuile-icône de la console de développement Visual Studio (sur la droite).
  • La tuile-vraie. C’est déjà une vraie tuile Windows 8. Son iconographie est adaptée à l’OS. Elle est statique mais mieux intégrée à l’ensemble. Sur la capture on notera dans ce style la tuile "Caméra” qui donne accès à l’appareil photo de la machine (la webcam sur ce PC, ou la caméra embarquée pour une tablette, un Smartphone).

 

Les tuiles peuvent adopter deux formes :

  • Les tuiles carrées. La capture en donne plusieurs exemples. Elles prennent moins de place et sont donc bien adaptées aux petits écrans (Smartphones notamment), Windows Phone 7 utilisait déjà à l’époque cette forme pour densifier l’affichage. Elles peuvent contenir des informations changeantes mais la place est limitée.
  • Les tuiles rectangulaires (dites “wide”, large). Ici aussi la capture en donne quelques exemples. Plus larges, elles permettent d’afficher plus d’information et se prêtent mieux que les tuiles carrées aux contenus riches et / ou changeant.

 

Enfin, il faut différencier :

  • Les tuiles passives. Comme celle de la caméra de la capture elles ne font qu’afficher une icône fixe. Rien ne sert de les agrandir, elle ne feront que prendre plus de place sans rien apporter de plus.
  • Les tuiles vivantes. Ce sont elles qui nous intéressent ici. Sur la capture on en découvre quelques unes mais faute d’avoir insérer une séquence vidéo ou un gif animé il est difficile de voir lesquelles “bougent”… Par exemple celle affichant un bout de clavier de PC avec un clavier Midi est une tuile vivante de la galerie photos. L’image présentée change régulièrement. La tuile des informations du jour est de même nature et présente en alternance les gros titres de l’instant.

 

Les tuiles qui nous intéressent aujourd’hui sont les tuiles “vraies”, carrées ou rectangulaires, mais “vivantes”.

La librairie NotificationsExtensions

Même si l’API WinRT est très bien faite, toute simplification est la bienvenue. Concernant la manipulation des notifications Microsoft à mis à disposition dans le SDK la Dll “NotificationsExtensions” qui simplifie grandement la manipulation de toutes les notifications : tuiles, badges et toasts.

Je ne parlerai que des tuiles vivantes ici, mais cette extension est utilisables dans d’autres contextes donc (badges et toasts).

La Dll se trouve dans le SDK quelque part sur votre disque et dans de nombreux exemples (notamment ceux portant sur les tuiles – voir mon précédent billet https://www.e-naxos.com/Blog/post/Telechargez-tous-les-exemples-de-code-officiels-Windows-8.aspx ).

Un mode d’emploi se trouve aussi sur les sites Microsoft à cette adresse : http://msdn.microsoft.com/en-us/library/windows/apps/Hh969156.aspx.

Nous utiliserons cette extension pour simplifier le code de création d’une tuile vivante.

A noter : cette Dll se présente sous la forme d’un projet Visual Studio de composant Windows 8 à ajouter à votre propre solution. Dans les exemples de code du SDK vous en trouverez un exemplaire par exemple à cet endroit : “Toast notifications sample\C#\NotificationsExtensions”. Pour des applications hors test je vous conseille de copier ce projet dans la solution de votre app plutôt que de pointer celui se trouvant dans le SDK.

Les astuces à connaître

La toute première astuce à connaître est plutôt un bug (ou un mauvais réglage ?) du simulateur. Les notifications ne marchent pas dans le simulateur, pour le programme exemple montré ici autant que pour toutes les autres tuiles animées. Je n’ai pas trouvé d’information sur ce point, peut-être n’est-ce qu’un paramètre à changer dans l’émulateur, en tout cas, sauf à trouver cet éventuel paramètre, ne vous fatiguez pas à tester les notifications sous simulateur… Il faut utiliser la machine locale.

La seconde astuce est une vraie astuce : dans le manifeste de l’application veillez à ce que le support du mode paysage soit bien coché. Visiblement quand rien n’est coché ça marche moins bien (encore beaucoup de mystères autour de WinRT ! ça se décantera avec le temps).

La troisième astuce est vicieuse : il faut fournir un logo 150x150 mais aussi un logo en 310x150 pour que le mode tuile large soit accepté. Le logo 150x150 est fourni par défaut (un carré avec ses diagonales dessinées, pour les tests cela peut suffire), en revanche le logo “wide” n’est pas fourni. Il faut donc en ajouter un. Lorsque cela est fait et que le programme est installé dans le menu Windows 8, on peut faire un clic droit dessus pour choisir le mode large ou carré.

On remarquera que les notifications utilise un fond décidé par le thème en cours, du coup les logos choisis sont masqués dès qu’une notification arrive. Dans ce test ils ne servent donc à rien d’autre qu’à permettre le fonctionnement en mode large ou carré ! (les logos sont aussi visibles au lancement de l’application quand aucune notification n’a été lancée ou quand on désactive les notifications pour la tuile dans le menu contextuel du menu Windows 8).

Les notifications sont des objets complexes et ils peuvent supporter des images, même provenant du Web (avec une URL donc). Ici je ne montre que le mode texte le plus simple. Il serait possible de réutiliser les logos pour écrire par dessus dans une version un peu plus sophistiquée.

Les thèmes pour tuiles

Windows 8 définit un certain nombre de thèmes pour les tuiles. Lorsqu’on utilise des notifications on fait à appels à ces styles qui conditionnent la présentation. Cela peut être fait par code (il y a des classes et des méthodes qui permettent de créer une notification avec un style donné) ou bien en XML. Dans ce dernier mode on définit la notification à l’aide de balises.

Les tuiles peuvent donc être carrées ou large (le rectangle n’étant finalement qu’un “carré long”…).

Selon cette forme de base certains styles sont disponibles.

TileSquareImage

 

Une image qui remplit tout l’espace du carré. Aucun texte. TileSquareImage example
TileSquareBlock Un gros bloc texte accompagné d’une ligne en fonte grasse mais nettement plus petite TileSquareBlock example
TileSquareText01 Un texte assez large d’entête et trois lignes simples de texte. Pas de wrap. TileSquareText01 example
TileSquareText02 Un texte assez large d’entête et une ligne simple pouvant se wrapper sur 3 lignes. TileSquareText02 example
TileSquareText03 4 lignes de texte simple sans wrap. TileSquareText03 example
TileSquareText04 Une ligne de texte simple pouvant wrapper sur 4 lignes. TileSquareText04 example
TileSquarePeekImageAndText01 Une image puis un texte large avec 3 lignes sans wrap. TileSquarePeekImageAndText01 example
TileSquarePeekImageAndText02 Une image puis un texte avec entête une ligne pouvant se wrapper sur 3 lignes. TileSquarePeekImageAndText02 example
TileSquarePeekImageAndText03 Une image puis 4 lignes de texte simple sans wrap. TileSquarePeekImageAndText03 example
TileSquarePeekImageAndText04 Une image puis une grande ligne de texte simple pouvant se wrapper sur 4 lignes. TileSquarePeekImageAndText04 example

 

Bien entendu ces styles se déclinent aussi pour les tuiles larges (rectangulaires) avec quelques nuances, ce qui donne environ une quarantaine de styles supplémentaires !

L’idée étant ici de vous donner un aperçu des styles et non de recopier la documentation officielle, je renvoie le lecteur à cette adresse http://msdn.microsoft.com/en-us/library/windows/apps/windows.ui.notifications.tiletemplatetype pour prendre connaissance de toutes les variantes possibles.

Un exemple

Le plus simple maintenant est de voir comment se servir de toutes ces connaissances sur les tuiles !

Pour commencer je vais créer une application Windows Store simple (le modèle “blank”). J’ajoute à la solution une copie du projet NotificationsExtensions évoqué en début de billet, puis je créée une interface minimale permettant de saisir un texte qui sera utilisé pour la notification accompagné d’une CheckBox sélectionnant soit le mode de création simple soit le mode utilisant une définition XML pour le formatage de la tuile.

Un bouton termine l’UI, à chaque clic une nouvelle notification est envoyée à la tuile de l’application (basée sur le texte saisi par l’utilisateur donc).

Ce qui donne quelque chose de ce genre :

image

Je vais avoir du mal à vous montrer l’effet final, en effet tout se joue dans le menu Windows 8 alors que le développement s’effectue en bureau classique d’une part et que, d’autre part, Windows 8 est “full screen” et pour voir l’effet du clic sur le bouton il faudra retourner sur le menu Windows. Enfin l’effet est une animation qui réclamerait une capture écran en vidéo.

Le mieux sera que vous jouiez avec l’application en créant des notifications tout en switchant sur le menu Windows 8 pour retrouver l’application et regarder sa tuile s’animer.

Notification simple par code

La première option prise en charge par la démonstration est la création d’une notification textuelle simple.

private void simpleNotification()
        {
            // création d'une tuile large + tuile carrée
            var contenu = TileContentFactory.CreateTileWideText03();
            contenu.TextHeadingWrap.Text = txtNotification.Text;
            var carré = TileContentFactory.CreateTileSquareText04();
            carré.TextBodyWrap.Text = txtNotification.Text;
            // le design carré est attaché à la tuile large
            contenu.SquareContent = carré;
            // création de l'objet de notification
            var notification = contenu.CreateNotification();
            // création de l'objet updater 
            var updater = TileUpdateManager.CreateTileUpdaterForApplication();
            updater.Update(notification);
        }
 

Le mécanisme peut sembler compliqué, en fait il l’est :-) Pour une fonction si rudimentaire de l’OS je m’attendais à quelque chose de plus direct. Non seulement il faut décomposer toute l’action mais pour la rendre “humainement supportable” il faut intégrer le fameux projet d’extensions.

Mais c’est comme tout, une fois qu’on connait le code à appliquer c’est très simple, évidemment…

L’action est commentée dans le source ci-dessus, je ne me répèterai donc pas.

A noter qu’on créée une tuile (large par défaut) et qu’on créée une seconde tuile carrée qui est raccrochée à la première. On notera aussi que l’on formate les tuiles en utilisant les styles évoqués plus haut, ici sous la forme d’appels de méthodes. Enfin, les plus perspicaces auront compris qu’il faut faire le formatage deux fois de suite, pour chaque forme de la tuile (large ou carrée), ce qui est encore un peu plus lourd.

Une API efficace aurait été une classe avec une méthode statique à laquelle on aurait passé le texte à afficher et le nom du style et qui se serait débrouillé du reste. Rien n’interdit d’écrire votre propre extension au-dessus des extensions !

Bien entendu la décomposition possède aussi son avantage : celui de pouvoir intervenir différemment à chaque étape. Par exemple nous créons ici un objet updater à chaque clic, il serait certainement plus subtile de conserver l’adresse du premier et de s’en resservir. Tout comme l’objet de notification. Ce qui prend sons sens lorsque l’application doit effectuer des notifications régulièrement.

Le code exemple ci-dessus montre le mécanisme, pas forcément la façon la plus optimisée d’utiliser l’API dans un contexte de production. Démo pour comprendre et production optimisée sont deux objectifs distincts, je ne vise le plus souvent dans Dot.Blog que le premier.

Notification par XML

L’API nous offre deux méthodes pour créer des tuiles vivantes. Chacun utilisera l’approche qui lui convient le mieux.

La première est entièrement par code comme nous venons de le voir.

La seconde déplace tout le formatage de la tuile vers une description XML, et c’est ce “bout” de XML qu’on passe à l’API.

Il y a des avantages aux deux approches, l’un de ceux du mécanisme par XML est qu’il s’agit d’une chaîne de caractères qui peut être construite à la volée dans l’application, relue depuis un fichier de configuration, personnalisée par l’utilisateur ou un outil de configuration par exemple, etc.

Le désavantage principale est qu’on passe un objet string non validé à la compilation. Et tout ce qui nous écarte d’un langage compilé fortement typé est risqué.

Bref, code ou XML, chacun choisira en fonction du contexte et de ce que cela peut lui apporter mais surtout en connaissance de cause et en assumant les risques et désavantages de chaque méthode. Mon rôle n’est pas de censurer mais de vous prévenir. A vous de voir !

Voici exactement le même code mais utilisant la définition de la tuile en XML :

private void xmlNotification()
        {
           
            string xml = "<tile>"
                             + "<visual>"
                             + "<binding template='TileWideText03'>"
                             + "<text id='1'>"+txtNotification.Text+"</text>"
                             + "</binding>"
                             + "<binding template='TileSquareText04'>"
                             + "<text id='1'>" + txtNotification.Text + "</text>"
                             + "</binding>"
                             + "</visual>"
                             + "</tile>";

            var tuileDom = new XmlDocument();
            tuileDom.LoadXml(xml);
            var notification = new TileNotification(tuileDom);
            TileUpdateManager.CreateTileUpdaterForApplication().Update(notification);
        }
 

Côté mécanisme de notification c’est beaucoup plus simple (les deux dernières lignes). Côté XML ce n’est pas trop lourd non plus (deux lignes qui pourraient être écrites en une seule).

C’est donc plus léger, sans aucun doute.

Reste à définir le XML. Dans un cas comme notre exemple on s’aperçoit que cela revient à écrire autant de lignes. Dans le premier cas (par code) tout sera contrôlé à la compilation, dans le second cas ça plantera à l’exécution. Et croyez moi, quand j’ai écrit cet exemple il a fallu que je m’y prenne à trois ou quatre fois avec plantage et exception incompréhensible (un gros code hexadécimal…) pour corriger le XML dans lequel j’avais introduit quelques petites coquilles… CQFD.

Plus prosaïquement le lecteur attentif reconnaîtra dans le code XML l’appel aux styles discutés plus haut. Par exemple TileSquareText04 utilisé ici comme le nom d’un template auquel il faut se binder en place et lieu d’une méthode de même nom dans la version par code.

Binder ? c’est du Xml ou du Xaml ? … non c’est bien du Xml qui emprunte sa syntaxe à Xaml qui lui même est une extension construite sur Xml. Un peut tordu mais c’est ici l’effet de la lutte intestine qui s’est jouée chez MS entre les équipes Xaml et Sinofsky. Ce dernier a gagné le contrôle des opérations, il pille les bonne idées de ces concurrents déchus car, au final, il n’y a pas mieux que Xaml :-)

Le code du projet

Amusez-vous avez le code, testez d’autre styles de tuile, c’est amusant (un peu fastidieux à tester malgré tout avec les aller-retours bureau classique / menu Windows 8 et retrouver l’application de test qui est tout au bout de ce long menu horizontal…).

Et pour éviter la fatigue d’une frappe sans grand intérêt, voici le projet Visual Studio 2012. Il faudra bien entendu utiliser VS 2012 sous Windows 8 et non sous Windows 7…

Solution exemple VS 2012 TuilesVivantes

Conclusion

La critique est facile, l’art est plus difficile, c’est bien connu.

Sinosfky n’a jamais aimé Silverlight ni WPF, il nous le fait bien sentir depuis des années, il est légitime de lui rendre la monnaie de sa pièce par quelques remarques acerbes... Cela étant dit, Windows 8 est une belle mécanique, puissante, agréable, rapide, et jouer avec les tuiles est divertissant. De ce côté là Steve il a fait son "job" correctement (!).

Reste à savoir si les tuiles sauront convaincre le monde d’abandonner la métaphore du bureau. Encore quelques semaines pour connaître la réaction du grand public après le lancement officiel.

Notre rôle à nous n’est pas de juger, mais d’être prêts dans tous les cas de figure.

Dot.Blog participe à cette veille technologique et à cette diffusion indispensable de l’information technique. Succès ou pas, l’avenir du produit n’est pas entre nos mains mais dans celles des utilisateurs. Soyons prêts à leur donner ce qu’ils aiment, WPF, Silverlight ou WinRT ou même MonoDroid, grâce à Dot.Blog vous serez prêt !

Dans ces périodes de doute et de choix incertains, plus que jamais… Stay Tuned !

blog comments powered by Disqus