Dévelopement

Xamarin : angoisses du débutant et solutions !

Dot.Blog - mer, 13/06/2018 - 00:32

Lorsqu’on débute avec Xamarin on se retrouve souvent face à des problèmes qui semblent trop nombreux ou insolubles. Le manque de connaissance fait paraître tout cela bien plus grave que ce ne l’est. Heureusement il y a Dot.Blog pour vous sortir de l’impasse !

Problem Solving

L’informatique est un métier qui peut s’exercer de cent façons différentes, mais toutes ont une chose en commun : l’obsession de régler des problèmes. Des problèmes de toutes sortes. L’objectif reste constant,leur trouver une solution. Celui qui n’aime pas les problèmes et préfère la routine ne doit jamais faire d’informatique !

Bien plus que le codage qui n’est qu’apprentissage d’une langue étrangère simplifiée, c’est la résolution des problèmes qui fait le métier et ses difficultés mais aussi son charme… L’informaticien doit être un joueur d’échec passionné qui sait analyser, savourer la victoire mais profiter aussi de ses défaites pour apprendre… sinon sa vie sera un enfer !

Aborder de nouveaux langages, de nouveaux OS, de nouveaux environnement obligent à sortir de sa zone de confort et par force à se confronter à des problèmes nouveaux devant lesquels le plus endurci se retrouvera comme un débutant démuni et stupide… Passer du sommet de la montagne au fond de la vallée en quelques instants est vertigineux. Les clients du parapente ou du saut à l’élastique restent rares malgré tout, l’humain est casanier et prudent, comme les chiens… L’informaticien est plutôt un aventurier même s’il travaille dans un bureau !

Xamarin n’échappe pas à la règle qui touche tous les environnements, au départ on se frotte à des difficultés qui peuvent sembler insurmontables alors que celui qui aura franchi ces premières étapes d’apprentissage donnera l’impression que tout y est simple et facile. C’est le cas des démos ou des conférences et je suis bien placé pour en parler ! Pour une heure de présentation il y a parfois des journées entières de travail, de test, d’échecs, de préparation du discours, le répéter plusieurs fois, etc. Les choses paraissent alors simples et couler de source… Mais quand on rentre chez soi et qu’on lance Visual Studio les choses se compliquent, s’embrouillent. Ce qu’on pensait avoir compris ne fonctionne pas, il manque des choses, les messages d’erreurs s’accumulent, certains abandonnent là et retournent à leurs habitudes. C’est triste. Si vous n’êtes pas de ceux là, alors voici quelques pistes qui vous permettront de dépasser les premiers instants parfois rugueux !

Trop d’erreurs au premier build

Le premier mur qui se dresse devant le débutant est bien celui-là ! Vous lancez Visual Studio, créez un projet Xamarin.Forms qui vous offre un template de base mais malgré cela vous ne pouvez pas faire un build et encore moins exécuter l’App immédiatement malgré sa simplicité déconcertante ! Ne paniquez pas, en général cela est du aux paquets Nuget qui ne sont pas restaurés par VS ou qui nécessitent d’être mis à jour (les templates ont parfois un peu de retard sur les mises à jour désormais très fréquentes de VS).

Solution

Restaurer tous les paquets Nuget, mettez à jour ceux qui le nécessitent.
Pour vous aidez, vous pouvez lire cet article de Microsoft : Restauration des packages

Impossible de compiler ou d’exécuter l’App

Hélas les choses ne sont pas toujours aussi simples qu’une restauration de paquets… Et malgré vos efforts pour tous les vérifier ça ne veut pas aller plus loin.

Ici il s’agit le plus souvent de paquets spécifiques à une plateforme qui manquent à l’appel. Après avoir restauré les paquets vous pouvez fort bien avoir des messages d’erreur vous indiquant qu’il en manque ! Cela est déconcertant je l’accorde. C’est souvent le cas avec les paquet pour Android comme Xamarin.Android.Support.Design ou d’autres paquets de supports. Ou bien c’est VS qui va rapporter des références manquantes à des dépendances ou des paquets qui sont pourtant déjà présents dans votre solution ! Agaçant et frustrant… Et si vous arrivez à lancer l’App, elle se fermera immédiatement. Si près du but…

Solution

je vais vous décevoir mais il n’existe pas de solution simple à ces problèmes, pas de recette miracle… Chaque cas est un cas particulier et seule la connaissance que vous accumulerez ainsi que l’expérience vous permettra de vous en sortir rapidement… Mais je ne vais pas vous planter là comme ça, ce n’est pas mon genre ! Je vous propose plutôt de lire cet article qui a l’avantage d’être écrit par une jeune femme, jolie et qui nous vient d’un coin qui n’est pourtant pas réputé pour sa haute technologie, la République Dominicaine…Common compilation problems in Xamarin and how to solve them (j’ai corrigé la faute du titre original qui se termine par “it” au lieu de them, on lui pardonnera !). J’entends quelques grincheux anglophobes là bas au fond… Problem-Solving… Utilisez l’un des traducteurs en ligne pour lire en français

C’est du XAML “çà” ? !

Si vous êtes un aficionado de XAML, un dur, un tatoué, du genre à faire du WPF dans le bloc-note Windows avec un main attachée dans le dos, forcément le XAML de Xamarin.Forms va vous sembler un peu curieux et parfois déroutant. XAML est un langage à balise, issu de XML et de leur grand-papa SGML. Xamarin.Forms ne fonctionnait pas en XAML au départ, uniquement en C#. Puis est venu XAML, très limité au départ et de plus en plus sophistiqué malgré tout. Mais il faut l’avouer il manque quelque chose à ce XAML là : le graphisme. Pas de templating de contrôles, pas de dessin vectoriel non plus. Au départ Xamarin.Forms ne fait que proposer des “wrappers” fantômes et non des contrôles réels… Un “Button” Xamarin.Forms n’a aucune existence réelle, c’est un décorateur, une façade, une pure vue de l’esprit. A l’exécution Xamarin.Forms instancie directement le contrôle équivalent natif de la plateforme. Les contrôles Xamarin.Forms sont ainsi des synthèses de ce qui existe, le plus petit dénominateur commun entre iOS, UWP, Mac OSX et même Tizen. C’est déjà une prouesse ! Mais on comprend qu’on ne peut pas bricoler le look du Button (ou de toute autre contrôle) comme on le fait en XAML classique, le “Button” n’existe pas ! C’est une abstraction pure. Et même si les XAML de Xamarin.Forms avait des primitives graphiques cela n’aiderait en rien pour ce problème là.

Solution

Là encore pas de miracle, il n’y a pas une option cachée à activer pour se retrouver avec des courbes de Bézier !

En revanche Xamarin.Forms est fourni avec une panoplie complète de primitives pour faire des animations… De même les Xamarin.Forms offrent tout ce qu’il faut pour travailler dans chaque projet natif, toujours en C#, pour y faire tout ce qu’on veut et utiliser toutes les possibilités de la plateforme sans perdre l’avantage d’un code centralisé, c’est le principe même des contrôles cross-plateforme supportés par les XF… Mieux, et comme le dernier article le montre, en utilisant une librairie comme SkiaSharp on retrouve des primitives graphiques 2D permettant de créer des contrôles personnalisés au graphisme léché et cross-plateformes !

Le XAML de Xamarin.Forms n’est peut être pas le plus puissant de la famille, mais il offre tout le nécessaire et sait ouvrir la porte pour ce qu’il ne sait pas faire.

Alors faut-il utiliser le XAML des Xamarin.Forms ou pas ? La réponse est un OUI francs et massif ! XAML est étudié pour créer des UI, il n’y a rien de mieux ni de plus pratique pour cela, ne cherchez pas. Et une fois que serez familiarisé avec ce XAML là, vous ne voudrez plus jamais faire vos UI en code C#…

Les animations : téléchargez un chapitre gratuit de mon livre sur les Xamarin.Forms !

Sur SkiaSharp : Création d’un contrôle personnalisé avec SkiaSharp, SkiaSharp et Xamarin.Forms la 2D cross-plateforme

Les erreurs fantomatiques !

Ca fait peur hein ! Bon, ce ne sont pas non plus des poltergeists qui viendront tourmentez vos nuits, n’exagérons rien. Ces erreurs là arrivent le plus souvent quand il y a une erreur en XAML ou côté plateforme native. Malgré tous les efforts de Xamarin et de Microsoft, remonter des infos complètes sur certaines erreurs de ce type est très complexe. Le plus souvent il faut se contenter d’un message du genre “ça a planté” sous-entendu démerdez-vous ! Même si on sait pourquoi, c’est très frustrant. J’ai parfois passé des heures à tenter de comprendre des bogues de ce genre.

Solution

… Jusqu’au jour où j’ai compris que puisque XAML est natif sous UWP et malgré le peu d’intérêt que cette plateforme suscite c’est par elle que viendrait le salut ! Depuis j’ajoute systématiquement la cible UWP à mes projets même lorsqu’ils ne ciblent qu’Android ou iOS. Pourquoi ? Faut suivre… parce que XAML est natif sous UWP. Il suffit donc de lancer son appli en mode UWP et le curseur viendra s’arrêter là où le code est mauvais le plus souvent et le tout garni d’un message d’erreur complet… La grosse astuce est donc de toujours avec une cible UWP dans ses projets et dès que vous tomberez sur l’une de ces erreurs angoissantes, au lieu de passer des heures à chercher, basculer sous UWP et relancez… Vous gagnerez des heures précieuses, croyez-moi !

Pas de designer visuel ?

la question revient forcément souvent. Non, pour l’heure il n’y a pas de concepteur visuel pour Xamarin.Forms. Si vous avez lu tout ce qui précède vous avez compris pourquoi : les contrôles de Xamarin.Forms n’existent pas ! Ils sont remplacés au runtime par des équivalents natifs qui ne sont pas tous exactement identiques. Comment offrir un concepteur visuel dans un tel cas de figure ?

Solution

Il y a des tentatives de proposer un système “'d’écho”, c’est à dire une fenêtre qui affirme en temps réel les modifications faites en XAML. Mais ce n’est pas encore très au point et cela ne peut pas remplacer un concepteur visuel soyons franc. Mais tout de même cela permet de se faire une idée, de ne pas être totalement en aveugle.

A connaître donc : Le Générateur d’aperçu XAML pour Xamarin.Forms

Il existe aussi un produit commercial, Gorilla Player, je n’ai pas accroché mais certains en sont contents.

Vous noterez qu’il existe en revanche un concepteur visuel pour Android et un autre pour iOS lorsqu’on utilise Xamarin en mode natif (et non pas en mode Forms).

Comprendre la philosophie des Xamarin.Forms et ses astuces

Au final ce qui manque le plus lorsqu’on débute c’est bien d’avoir une vue d’ensemble tout autant que de bénéficier d’un coup de pouce pour résoudre certains problèmes comme le support de MVVM ou l’utilisation d’une base de données SQL par exemple…

Solution

Si vous ne l’avez pas déjà, procurez-vous mon Livre sur les Xamarin.Forms ! Il vous donnera à la fois cette vue d’ensemble indispensable ainsi que ces petits détails qui rendent les choses plus faciles… Je donne aussi des formations ou propose des formules de monitoring ou de starter-kit mi-développement mi-formation pour bien démarrer vos projets… Et pour les grandes occasions, j’assure aussi un service de forfait qui vous évitera de vous prendre la tête ! Vous ne pourrez pas dire que vous n’étiez pas au courant

Conclusion

Xamarin.Forms représente une avancée fantastique. Depuis son rachat il y a déjà un moment par Microsoft c’est en plus une plateforme “officielle” soutenue et garantie. Tout n’est pas rose, mais le problème posé est véritablement diablement complexe à résoudre. Les Xamarin.Forms s’en sortent très bien et offrent l’avantage de langages à la pointe, C# et XAML, le plus puissant des IDE, Visual Studio, la plateforme objet la plus riche, .NET, et le support de tous les OS, jusqu’au Mac sur lequel il existe une version de Visual Studio pour ceux qui ne veulent pas toucher à un PC !

C’est plutôt du lourd. Alors on comprend que les débuts ne soient pas toujours faciles faciles… Mais là encore, Solution : lisez Dot.Blog et…

Stay Tuned !

Catégories: Dévelopement

Les papiers des lecteurs : Créer un contrôle graphique Xamarin avec SkiaSharp

Dot.Blog - dim, 10/06/2018 - 17:19

Xamarin vous semble figé avec son XAML sans primitives graphiques ? C’est oublié SkiaSharp… Alors découvrez comment développer un contrôle graphique personnalisé avec cette librairie !

Les papiers des lecteurs

Cette rubrique est la vôtre, Dot.Blog publie de temps en temps des articles écrits par ses lecteurs, saisissez cette possibilité !

Ce mois-ci c’est Patrick Breil qui s’y colle. Patrick développe des applications mobiles pour l’entreprise où il exerce ses talents par exemple des suivis de dossiers pour des techniciens qui interviennent sur site et qui peuvent ainsi prendre connaissance des tâches à effectuer et saisir le détail de leurs interventions. L’adoption de tels logiciels réclame non seulement un fonctionnel à la hauteur mais aussi un look & feel comparable aux autres Apps que l’utilisateur à l’habitude de voir sur son smartphone. Cela place la barre assez haute !

Les papiers des lecteurs c’est un retour d’expérience qu’on partage, c’est noble et c’est utile ! Vous aussi vous pouvez me proposer vos articles, pensez-y…

SkiaSharp

Pour ceux qui ne connaissent pas : c’est une API 2D complètement portable iOS, Android, UWP et même Mac OSX ou WPF. SkiaSharp ce sont un peu les primitives graphiques qui manquent au XAML de Xamarin.

J’ai déjà présenté cette librairie l’année dernière et je renvoie le lecteur intéressé à ce papier : SkiaSharp et Xamarin.Forms le dessin 2D cross-plateforme.

Créer un contrôle personnalisé avec SkiaSharp

Il est temps de laisser la parole à Patrick pour son papier…

Objectif

Créer un contrôle permettant d’indiquer une valeur de % sur un arc, un peu comme une barre de progression mais qui aurait été courbée (dessin ci-dessous).

Création du projet

Un classique mais il faut bien commencer par là : Nouveau projet > Prism Xamarin.Forms

(Patrick a fait des captures parfois un peu justes niveau résolution mais on comprend l’action !)



Ajout du Package Nuget SkiaSharp


Création du contrôle utilisateur :

Créer un nouveau dossier ‘UserControls’, puis un nouveau ContentView ‘Gauge’

Le xaml du contrôle ne va pas contenir grand-chose si ce n’est un SKCanvasView qui contiendra le dessin de notre contrôle.

Une fois saisi SKCanvasView il est proposé d’ajouté l’espace de nom SkiaSharp.Views.Forms.

Il suffit ensuite d’ajouter un gestionnaire d’événements à PaintSurface.

Nous passons ensuite au code behind, et plus précisément sur la méthode SKCanvasView_PaintSurface qui sera invoqué par l’événement ‘InvalidateSurface’ du CanvasView.

private void SKCanvasView_PaintSurface(object sender, SkiaSharp.Views.Forms.SKPaintSurfaceEventArgs e)
{
  SKSurface surface = e.Surface;
  SKCanvas canvas = surface.Canvas;

canvas.Clear();

int width = e.Info.Width;
  int height = e.Info.Height;

canvas.Translate(width / 2, height / 2);

SKRect Rect = new SKRect(-100, -100, 100, 100);
}

Le code ajouté sur la méthode positionne le point 0,0 au milieu de la surface définit en fonction du contenant de notre contrôle.

Le point 0,0 se situe en haut et à gauche.

Notre contrôle sera centré est définit dans un carré de 200 x 200.


Nous définissons un rectangle (qui pour le coup est carré !)

SKRect Rect = new SKRect(-100, -100, 100, 100);


Il faut maintenant adapter la taille de notre contrôle en fonction de la taille du contenant.

L’échelle retenue sera la plus petite calculée pour la largeur et la hauteur.

float scale = Math.Min((width / Rect.Width), (height / Rect.Height));

canvas.Scale(scale);

Passons au dessin du fond de notre gauge. Pour cela nous devons définir un chemin qui sera parcouru par un pinceau.

Le chemin représente le milieu de l’épaisseur du pinceau, soit 75 + (25/2) = 87.5.

Le code suivant, instancie un chemin path.

using (SKPath path = new SKPath())

{
    path.ArcTo(new SKRect(-87.5f,-87.5f,87.5f,87.5f), 135, 270, false);

    canvas.DrawPath(path, new SKPaint
            {
              Color = Color.Gray.ToSKColor(),
              Style = SKPaintStyle.Stroke,
              StrokeWidth = 25
             });
}

Un arc est décrit par la méthode ArcTo.

  • Le rectangle décrit l’espace dans lequel sera tracé notre arc. Il s’agit bien d’un rectangle ce qui signifie qu’il est possible de décrire une section d’une ellipse si le rectangle n’est pas un carré !
  • La première valeur correspond à l’angle de départ dans le sens horaire (ou inverse trigonométrique), soit dans notre cas 45° + 90° = 135 °
  • La seconde l’angle décrit par notre arc, soit 360° -90° =270°
  • Le booléen indique si la suite du chemin part ou non de la fin de notre arc.

Nous traçons ensuite notre arc avec un pinceau d’une épaisseur de 25 correspondant à la différence de nos deux rayons.

Pour tester le résultat (provisoire), il suffit d’ajouter notre contrôle au Xaml

<ContentPage xmlns=http://xamarin.com/schemas/2014/forms
             xmlns:x=http://schemas.microsoft.com/winfx/2009/xaml
             xmlns:usercontrols="clr-namespace:ControleSKiaSharp.UserControls"
             x:Class="ControleSKiaSharp.Views.MainPage"
             Title="{Binding Title}">

<StackLayout HorizontalOptions="FillAndExpand" VerticalOptions="FillAndExpand">
   <usercontrols:Gauge HorizontalOptions="FillAndExpand"VerticalOptions="FillAndExpand"/>
</StackLayout>
</ContentPage>



Notre contrôle est centré et occupe l’espace disponible et s’adapte au changement de taille de la fenêtre.

Ajoutons maintenant le second arc correspondant à la valeur à représenter.

La variable valeur contient la valeur à représenter.

L’angle décrit est calculé en fonction de l’angle complet de notre compteur soit 270°.

La fonction pourrait être adapter pour des plages de valeurs différentes, ainsi qu’un angle de représentation plus petit ou plus grand.

float valeur = 55;
float AngleValeur = (270 * valeur) / 100;
using (SKPath path = new SKPath())
{
   path.ArcTo(new SKRect(-87.5f, -87.5f, 87.5f, 87.5f), 135, AngleValeur, false);
   canvas.DrawPath(path, new SKPaint
                             {
                               Color = Color.CornflowerBlue.ToSKColor(),
                               Style = SKPaintStyle.Stroke,
                               StrokeWidth = 25
                              });
}


Ajoutons maintenant l’affichage de valeur au centre de notre contrôle.

canvas.DrawText(valeur.ToString("0.0") + "%", 0, 10, new SKPaint
   {
     Color = Color.CornflowerBlue.ToSKColor(),
     Style = SKPaintStyle.Fill,
     StrokeWidth = 1,
     TextAlign = SKTextAlign.Center,
     TextSize = 40
    });



Notre contrôle à l’apparence souhaité mais pour le moment son utilité est plutôt limitée. Il faut que nous rendions Bindable la propriété valeur pour qu’elle soit dynamique.

// NDE : Patrick a eu un problème pour définir la propriété en float et il a réussi à le faire en utilisant le type string.
// Ce n’est évidemment pas optimal… j’attends qu’il m’envoie le code source du projet pour regarder
// et je vous tiendrai au courant !


float valeur = 0.0f;

public static readonly BindableProperty ValeurProperty =
           BindableProperty.Create(propertyName: "Valeur",
                                   returnType: typeof(string),
                                   declaringType: typeof(Gauge),
                                   defaultValue: "0.0",
                                   defaultBindingMode: BindingMode.Default,
                                   propertyChanged: UpdateValeur);




public string Valeur
         {
             get { return (string)GetValue(ValeurProperty); }
             set { SetValue(ValeurProperty, value); }
         }

private static void UpdateValeur(BindableObject bindable, object oldValue, object newValue)
         {
             var ctrl = (Gauge)bindable;
             var v = (string)newValue;
             ctrl.valeur = float.Parse(v.Replace(".",","));
             ctrl.canvas.InvalidateSurface();
         }


On modifie ensuite le Xaml de la page pour lier la propriété du contrôle avec un Slider

<?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:usercontrols="clr-namespace:ControleSKiaSharp.UserControls"
              x:Class="ControleSKiaSharp.Views.MainPage"
              Title="{Binding Title}">

     <Grid HorizontalOptions="FillAndExpand" VerticalOptions="FillAndExpand">
         <Grid.RowDefinitions>
             <RowDefinition Height="25" />
             <RowDefinition Height="1*" />
         </Grid.RowDefinitions> 
         <Slider x:Name="Slider" Minimum="0" Maximum="100"/>
         <usercontrols:Gauge Grid.Row="1" HorizontalOptions="FillAndExpand" VerticalOptions="FillAndExpand"
                             Valeur="{Binding Source={x:Reference Slider}, Path=Value}"/>
     </Grid>

</ContentPage>





Notre contrôle est maintenant fonctionnel et peut être utilisé en MVVM.

SkiaSharp est une bonne technologie pour créer ses propres contrôles et peux nous dispenser de télécharger des Packages complet pour n’utiliser que quelques composants.

Ce contrôle est relativement simple, mais il est possible d’en créer de plus complexe en ajoutant des propriétés dynamique comme les couleurs, les unités, des listes de valeurs, etc…

Exemple : Une application mobile de contrôle pour Terrarium.


Conclusion

Remercions à nouveau Patrick pour ce bel effort ! Cela vous prouve qu’en prenant un peu le temps on peut écrire des papiers intéressants et les partager avec la communauté… je vous incite à suivre cet exemple !

Cela prouve aussi que Xamarin.Forms a atteint une vraie maturité. Son C# est à la hauteur (c’est le même que pour WPF ou UWP), son XAML s’est complexifié avec le temps et supporte l’essentiel de ce langage, et pour la partie graphique, problématique dans un environnement cross-plateforme, nous disposons de librairies simples d’utilisation qui comblent le fossé avec le XAML classique.

Il est donc possible à la fois de gagner du temps (un code, de multiples cibles natives) sans rien sacrifier au look & feel si essentiel sur les smartphones.

A vos claviers ! (pour coder mais aussi pour écrire un papier des lecteurs !)

Stay Tuned !

Catégories: Dévelopement

Xamarin Forms 3.0 une release qui a du Style !

Dot.Blog - dim, 13/05/2018 - 14:34

Xamarin.Forms est déjà un ensemble mature et complet d’outils, compilateurs, templates et contrôles cross-plateformes basés sur .NET et XAML. Développer pour Android, iOS, UWP avec un seul code unifié est déjà en soi une prouesse. Pour un résultat natif, pas un bricolage hybride ou interprété. La version 3.0 pousse encore plus loin les choses…

Les évolutions

Chaque évolution de Xamarin.Forms 3.0 mérite un article, il sera donc difficile ici de faire beaucoup mieux que de vous donner un aperçu de sujets sur lesquels je reviendrai dans les semaines à venir.

La première chose intéressante à noter c’est l’intégration du travail de la communauté. Xamarin.Forms s’enrichit par le travail de son équipe de développement mais aussi par celui de la riche communauté qui s’est formée autour de ce produit. Et c’est une excellente nouvelle !

Autre point : la convergence avec XAML de WPF s’améliore encore… Avec l’une ces possibilités les plus marquantes pour qui manipule WPF…

Le Visual State Manager

Emblématique fonctionnalité de WPF ? Non pas tout à fait… C’est feu Silverlight qui le premier introduisit cette extraordinaire possibilité doublée d’un pilotage admirable dans Blend. Ce n’est qu’après, constatant le côté incontournable de cette évolution, qu’on vit apparaître le VSM sous WPF.

Aujourd’hui il arrive dans Xamarin.Forms. Silverlight n’est pas mort, son âme plane toujours sur XAML !

Sous WPF et Sliverlight qui sont (était) des systèmes graphiques totalement vectoriel le VSM a toujours été une merveille visuellement. Vous définissez des “états” de votre UI, vous leur donnez des noms, vous fixez éventuellement des transitions, des effets, et via une commande en C# vous faites passer votre UI d’un état à l’autre. Brusquement ou plutôt via des effets de transition du plus bel effet. Cela s’accorde de plus facilement avec MVVM puisque le ViewModel n’a besoin que d’envoyer des noms d’état à l’UI pour que celle-ci s’adapte sans avoir à connaître les contrôles eux-mêmes. Le nom de l’état est une string, le découplage est donc total. En envoyant le nom de l’état dans un message MVVM vers la View les puristes retrouve un découplage total. Car ce nom envoyé ne présume en rien de ce qui en est fait. Un ViewModel peut ainsi prévoir de passer de l’état “Idle” à l’état “Chargement en cours” sans même savoir ce que l’UI en fera. Charge au designer d’utiliser ou non ces changements d’états bien identifiés pour les matérialiser dans l’UI.

Sous Xamarin.Forms le procédé n’est pas graphiquement du même niveau puisque ce XAML là n’est pas vectoriel, pas même graphique. On y manipule des abstractions de contrôles qui seront remplacées par des contrôles natifs. Impossible de déformer lentement l’enveloppe d’un bouton en tirant sur les points de contrôle de la courbe de Bézier de son contour par exemple…

C’est pourquoi WPF est et restera la référence absolue pour XAML, sa plus belle et plus puissante implémentation. Le petit frère Silverlight est tombé au combat, mais ce qu’il a lui-même apporté à WPF vit toujours et se retrouve désormais dans Xamarin.Forms.

Je ne vais pas vous gaver d’images piquées ici ou là, d’extraits de codes sortis de leur contexte, je réserve une accueil un peu plus sérieux au VSM sous Xamarin.Forms, et j’en parlerai plus en détail dans un article entièrement consacré à ce procédé absolument génial et indispensable même.

Le FlexLayout

Encore un contrôle permet de disposer ses enfants selon des modes particuliers. Dans la lignée de tous les xxxLayout. Et à chaque fois nous gagnons en souplesse car chaque layout propose une stratégie de placement de ses enfants que les autres ne savent pas faire.

FlexLayout est inspiré de la FlexBox du Web très en vogue pour les mises en page aujourd’hui. Un outil de plus pour se sortir de tous les cas c’est toujours bon à prendre.

CSS

CSS ? Vade Retro Satana ! Un exorciste vite !

Oui… la Bête immonde fait sont apparition dans Xamarin.Forms… Les âmes sensibles sont prévenues. Cauchemars à prévoir.

Alors disons le tout de suite pour rassurer tout le monde, c’est une option. Une simple option. Totalement démagogique je vous l’accorde. Comme à chaque fois qu’on met des morceaux de web dans de vrais langages. C’est justifié systématiquement par le fait que cela permettra aux développeurs Web de venir plus facilement à la technologie en question. MS a fait ça avec UWP, on voit le résultat, Xamarin, aujourd’hui possession de MS a certainement été poussé à le faire pour les mêmes raisons.

Si vous vomissez CSS comme moi, oubliez cette “possibilité” immédiatement.

car Si XAML est excitant, CSS, satan l’habite…

Mais si vous êtes un pratiquant de messes noires (du genre à coder en JS par exemple), vous serez heureux de pouvoir faire vos mises en page Xamarin.Forms en CSS !

L'utilisation de CSS pour styliser vos mises en page est un moyen optimal (langue de put* inside) d'exprimer des styles en tandem avec XAML. Beaucoup de développeurs adorent la magie noire CSS à cause de leur expérience avec les technologies Web n’ayant pas eu la chance de connaître un vrai cursus professionnel en informatique. Mais les développeurs XAML, ces saints, restent accrochés à la définition des styles en XAML. Xamarin.Forms vous offre ces deux options de productivité! Utilisez ce qui vous rend le plus productif (mais de préférence XAML).

Les StyleSheets peut être ajouté en tant que fichiers CSS distincts dans votre projet, ou en ligne dans vos ressources. Une variété de sélecteurs communs sont disponibles pour composer vos styles.

C’est pas merveilleux ça le mariage de la carpe et du lapin ?

(le texte ci-dessus est en partie une traduction très libre de l’annonce officielle : “Cascading Style Sheets (CSS) is a natural companion to FlexLayout given their shared heritage. Using CSS to style your layouts is an optimal way to express styles in tandem with XAML. We know many of you love CSS from your experience with web technologies and we also recognize XAML developers love to express their styles in XAML. We are so excited to bring both of these productivity options to you! Use what makes you most productive.”)

Bon alors next !

Localisation gauche droite

Il y a des langues qui s’écrivent dans l’autre sens que le  nôtre, l’hébreu, l’arabe par exemple. Pour gérer ces cas de façon simple il suffit désormais d’utiliser FlowDirection…

Support de WPF

Voilà une riche idée, rendre à César ce qui lui appartient, un juste retour des choses… C’est un travail communautaire, ça avance mais ce n’est pas encore terminé à 100%. Ce projet permet d’ajouter WPF aux cibles d’une solution Xamarin.Forms… Vous pouvez accéder ici au statut d’avancement de ce chantier très intéressant !

Conclusion

Xamarin.Forms ne déçoit pas, chaque release apporte son lot d’améliorations. On peut certes regretter que des satanistes venus du Web aient noyauté l’équipe de développement pour souiller la pureté mariale de XAML, mais bon, ayons l’esprit large en sachant que cette mode d’ajouter du JS ou du CSS un peu partout pour faire venir des développeurs Web n’a jamais fonctionné qu’à la marge alors restons zen…

Voire la communauté travailler au support de WPF est une excellente chose en revanche. Voire des inventions géniales de Silverlight faire leur comeback par la grande porte est aussi un plaisir.

Il y a vraiment du très bon dans cette version 3.0.

Je vais y revenir forcément.

J’ai eu 4 / 5 mois de charge un peu plus dense et j’ai moins écrit dans Dot.Blog, mais ne vous inquiétez pas, cela va revenir ! Alors…

Stay Tuned !

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