[new:31/09/2015]Avant de se jeter dans le code dans de prochains articles je vous propose un petit tour d’horizon de la plateforme Windows 10 avec les Universal Apps pour comprendre les concepts principaux et les avantages de ce nouvel environnement en rupture avec le passé.
Une plateforme unifiée … de plaisir
On y est ! Je vous en avais parlé très tôt, en novembre 2011. Rappelez-vous, le fameux “our strategy with Silverlight have shifted” de Bob Muglia (qui flingua sérieusement et à raison le moral des amoureux de Silverlight). Vous remettez ? (sinon suivez ce lien où j’expliquais tout !).
A ce moment précis je vous expliquais comment je voyais les choses en développant une explication basée sur le passage chez Microsoft du rêve de l’universalité horizontale (cross-plateforme tel Silverlight) à la réalité de l’universalité verticale (cross-form-factors).
L’avenir m’a donné raison avec les annonces de Windows 8 puis 8.1 et sa convergence WinRT desktop / mobile.
La verticalité de UWP
Mais c’est désormais le présent qui enfonce le clou de cette vision qui avait quelques années d’avance sur les faits : Windows 10 réalise pleinement ce concept d’universalité verticale, à tel point même que la plateforme de développement s’appelle UWP (Universal Windows Platform). Même le terme et le thème de l’universalité ont été repris… (je vais demander des copyrights si ça continue !).
Bref c’est fait. Microsoft ne rêve définitivement plus, ils deviennent rationnels et nous proposent une véritable bombe atomique avec UWP : Un seul Windows conçu sur un noyau identique pour toutes les machines, de l’ARM à la télévision, du smartphone au PC. Plutôt une seule plateforme, vous allez comprendre la nuance.
Comme je le déplorais dans ce vieil article évoqué ici ce retour à la réalité n’est pas sans laisser la trace indélébile d’un rêve perdu. L’universalité horizontale, cross-plateforme, que Silverlight nous a fait effleurer était si beau… Mais un rêve est un rêve, et même cassé on doit en garder la force évocatrice comme une énergie nouvelle pour appréhender le futur et l’aimer. Aimer ce qu’on a plutôt que ce qu’on veut est le début de la sagesse parait-il…
Mais aimer UWP n’est pas un acte de désespoir ou un pis-aller. La convergence proposée par Windows 8.x était encore trop bancale, trop restrictive, elle n’était pas porteuse de rêve en elle-même. En revanche la plateforme unifiée UWP est elle porteuse d’espoir. Au moins parce qu’elle est concrète, elle existe, elle est là avec ses outils de développement. Elle rend un rêve possible, un rêve qui est devenu aujourd’hui une obligation incontournable : le cross-form-factor.
Après tout le cross-Platform on s’en moque, j’ai ai beaucoup parlé par intérêt technique mais cela ne m’a jamais fait frissonner. C’est une obligation imposée par le marché, d’un côté Apple, de l’autre Google et un peu de Windows Phone chez Microsoft. Alors on bricole. Un bricolage peut être génial comme MvvmCross dont j’ai parlé longuement (plus douze vidéo d’une heure sur Youtube !) ou les fabuleuses Xamarin.Forms. On peut s’emballer même, pour la beauté du travail accompli. Mais c’est ce que j’appelle un plaisir négatif.
UWP, une avancée positive
Je me souviens d’une vieille blague un peu moisie je l’avoue, genre blague de récré de CM1 qui illustre en revanche à merveille ce concept, celle du type dans un asile qui en voit un autre en train de se taper la main avec un marteau et qui lui demande “mais pourquoi vous faites ça ?” et le fou de lui répondre “ça me fait tellement de bien quand j’arrête !”.
Vous voyez le concept ? Xamarin, MvvmCross c’est ça. Le marché nous met sous le nez plein d’OS différents, le marteau nous tape sur la main, c’est même un “casse-tête”, alors quand ces merveilleux outils apparaissent on se sent tellement soulagé que c’est comme si le bonheur c’était ça : juste arrêter de se faire mal… le langage populaire utilise d’ailleurs l’expression “s’enlever une épine du pied”, même concept d’un faux bonheur créé par l’arrêt d’une souffrance.
Mais le vrai bonheur ce n’est pas ça. C’est partant d’un état serein et sans souffrance ajouter un quelque chose qui procure du plaisir. Ce que j’appelle donc un plaisir positif par opposition au plaisir négatif évoqué plus haut. En réalité couvrir plusieurs OS est une simple contrainte, sans aucune richesse ni jouissance potentielle. En revanche pouvoir couvrir par un seul code de l’Xbox au PC en passant par les télévisions et les smartphones, ça c’est un vrai rêve, un véritable besoin car même si un seul OS existait au monde toutes ces machines différentes existeraient tout de même. Répondre à ce rêve par un tooling et un plateforme au point c’est apporter un plaisir positif, c’est ça UWP.
L’entreprise et UWP
Vous allez me dire que c’est bien joli mais qu’étant donné le marché parler d’universalité en la limitant au monde Windows qui au niveau unités mobiles est plutôt dans les cordes ça fait un peu fanboy à côté de ses pompes.
Certes. Mais la réalité est un petit bouchon de liège sur une mer agitée. Trimbalé par les vagues sa position change en permanence et il suffit d’un vent favorable pour qu’il aille par ici plutôt que par là…
Ce vent favorable c’est UWP bien plus d’ailleurs que Windows 10 qui n’en est qu’une émanation, un simple maillon de la chaine.
Car si vous ne l’avez pas remarqué, les unités mobiles ont envahi le monde… sauf les entreprises. Et on le comprend.
Pour le vulgum pecus le saut est facile à faire, quelques centaines d’euros et on a une bonne machine. Peu importe l’OS, après tout pour streamer de la télé réalité, écouter du rap et partager des photos de son hamburger de midi sur les réseaux sociaux l’OS n’a aucune importante. Facebook et Instagram sont les mêmes partout, et un SMS reste un bout de texte même sur un iPhone à 1000 euros…
Pour les entreprises l’affaire prend une autre tournure : il faut développer des softs spécifiques interconnectés, ça coute cher, et vu que les trente glorieuses sont finies depuis longtemps, engager un pro de Apple, un pro de Android, un pro de Windows Phone en plus des gars qui s’occupent des vieilles applis en WinForms (et qui sont techniquement souvent largués avouons-le), ce n’est pas possible tout simplement, pas plus que de fantasmer sur un type qui serait expert en tout (et pas cher en plus)…
Du coup il faudrait que les mêmes qui maintiennent du vieux WinForms puissent aussi devenir des génies du cross-plateforme et se transformer au passage en roi du Design. Là aussi il y a comme une sorte d’impossibilité pratique…
Entre deux impossibles qu’elle s’est construite toute seule l’entreprise est coincée. Pourtant il va bien falloir intégrer ces fichus zinzins mobiles dans la logique globale du SI … Et le temps presse surtout en France où le retard à ce niveau est gigantesque.
Alors UWP pourrait bien être la solution…
Former des gens connaissant WinForms donc .NET pour faire du code Universal App c’est possible. Pour les choix stratégiques d’architecture on peut ponctuellement faire appel à un spécialiste, ça ne coute pas si cher, et pour le Design on peut faire sobre et simple, il n’y a pas de client à accrocher. Tant que c’est fonctionnel c’est le principal.
Et si on a la chance d’être un peu mieux doté, alors on pourra former des équipes déjà compétentes en C#/XAML, les guider pour appliquer les bonnes pratiques de codage et de Design et ça peut même faire de très bonnes applications !
Car ce qui coute cher c’est la pluralité des OS, et elle est obligatoire uniquement pour gérer tous les form-factors. Sauf avec UWP ou cette barrière disparait et à condition de rester avec Windows mais puisqu’il couvre tous les form-factors pourquoi s’embarquer dans des culs de sac couteux ?
UWP est donc le meilleur train à prendre pour les entreprises. Au top de la modernité, mais réclamant un investissement humain quasi nul quand on a déjà des équipes de bon niveau en place. Le meilleur train car c’est aussi le dernier, dans tous les sens. C’est la dernière technologie la plus achevée, mais c’est aussi la dernière chance de rattraper le retard. Attendre mieux que UWP ne sert à rien, cela n’existera pas. Mieux ce serait un UWP cross-plateforme… Ca existe en ajoutant Xamarin à UWP, mais c’est le maximum. Jamais les OS ne seront harmonisés entre les concurrents et aucune chance qu’un EDI indépendant véritablement cross-plateforme émerge (en dehors des trucs java qui sentent la naphtaline). Tous les trucs de ce genre sont des leurres qui coutent cher en licences, en formations et en essais infructueux (les apps hybrides par exemple)… Rappelez-vous, l’universalité horizontale est morte avec Silverlight et avec Flash pour qui sonne aussi le glas…
UWP est donc le choix de la sagesse en restant centré sur les mêmes technologies déjà utilisées par l’entreprise, ce qui au passage assure une compatibilité sans problème entre les sous-ensembles du SI.
Reste à généraliser les tablettes Surface (mais les entreprises en utilisent déjà en raison de son support du desktop classique) et surtout les Windows Phone. Et là encore il s’agit de faire des économies et la stratégie Microsoft est bien placée : combien coute plusieurs salariés à l’année pour maintenir du cross-plateforme dans une logique BYOD et combien coute l’achat groupé de quelques smartphones Microsoft ?
Si je défends souvent la position du salarié il me semble qu’il faut raison garder. Il ne me parait pas raisonnable que ce soit le salarié qui décide de quel smartphone il doit se servir professionnellement. Et s’il en possède déjà un à lui, c’est son affaire. Envisagerait-on des chauffeurs-livreurs imposer chacun à leur patron leur marque et leur modèle de camion préféré ? C’est ubuesque. Avec le BYOD on tente de répondre à un faux problème. L’entreprise fonctionne sur une rationalisation du travail, ce n’est pas le buffet du Club-Med où chacun se sert comme il veut de ce qu’il veut… Faire plaisir à tout le monde c’est bien mais les entreprises ne sont pas structurées pour avoir un service informatique Club-Med… Donc UWP est une réponse rationnelle à un problème rationnel.
Qu’est-ce que UWP ?
Il faut considérer UWP comme une véritable plateforme physique sauf qu’elle n’est que virtuelle. Si elle présente toujours la même face aux applications (ses API), côté pile elle s’adapte à chaque hardware. En fait c’est le principe de Silverlight mais au niveau d’un OS… SL Apple et SL PC ce n’était pas le même code, mais pour les applications SL c’était la même API. Microsoft pousse très loin ce concept en allant au bout du voyage, le plus loin possible, l’OS lui-même.
Les applications désormais ciblent UWP et non pas Windows 10. La clé de l’universalité est là. UWP peut évoluer à sa propre cadence indépendamment des OS spécifiques des machines.
Dans le monde Microsoft toutes les variantes actuelles commencent malgré tout à faire pas mal de hardwares différents. On le voit sur une des illustrations précédentes, on pense tout de suite à Windows sur PC ou sur smartphone mais on oublie les phablets, les petites tablettes, les grandes, les 2-en-1 (tablette / portable), les portables, Surface Hub, la Xbox, Hololens les lunettes 3D de réalité augmentée, la domotique et même IoT, le fameux “Internet of Things”, l’Internet des Objets, ce qui va du bracelet pour faire du sport au Raspberry Pi 2 ou l’Arduino !
Tout cela avec la même plateforme, et comme le montre une seconde illustration :
- Un système d’exploitation : Un seul Windows pour toutes les machines.
- Une seule plateforme : une application fonctionne sur toutes les familles de machines.
- Un seul centre de développement : une seule soumission d’app avec un seul suivi de son flux et un seul dashboard.
- Un seul Store : un seul point d’entrée pour l’utilisateur/client, une recherche globale, monétisation centralisée …
A elle seule cette liste est un véritable conte de fée… Et il se réalise car Windows dispose d’un nouveau cœur commun qui s’interface entre la machine et les applications. C’est lui qui unifie tout en proposant un environnement d’exécution stable et commun.
Bien entendu un même Windows aurait du mal à couvrir tous les besoins de machines aussi différentes que Hololens et un Arduino, entre un smartphone d’entrée de gamme et un serveur d’entreprise.
Le noyau de Windows est donc commun mais selon le hardware on peut y ajouter des librairies spécifiques qui donnent accès aux spécificités de chaque machine.
Le développeur peut écrire un code unifié malgré ces librairies spécialisées en testant l’existence ou non des API et en s’adaptant (par exemple la présence d’un bouton hardware pour prendre un photo est piloté par une API absente sur un PC mais présente sur certains smartphones, on peut savoir à l’exécution s’il faut afficher un bouton ou si on peut utiliser le bouton hardware présent). Mais il n’y a pas non plus obligation d’utiliser les librairies spécifiques, le noyau très riche peut être utilisé pour 95% du code dans de nombreux cas.
Les outils
On retrouve bien entendu Visual Studio (2015) et le sublime Blend, rescapé de l’époque Silverlight et qui reste à mon sens l’EDI visuel le plus atypique et le plus fantastique jamais édité.
On peut développer depuis une machine équipée de Windows 10, c’est préférable pour tout faire (et bénéficier des émulateurs). On peut aussi le faire depuis Windows 8.1 et Windows Server 2012 R2. Mais dans ce dernier cas il faudra des machines physiques pour le débogue car les émulateurs ne marchent pas (mais qui voudrait rester en Windows 8.1 ???).
La fin des trucs compliqués
Pour celui qui a développé pour Windows Phone 7 et suivant comme moi, la nouvelle approche de Windows 10 me déconcerte : pourquoi n’ont-ils pas commencé par là ? ! C’est en tout cas l’une des choses que je demandais depuis longtemps car c’était un vrai frein au développement…
Je veux parler de l’utilisation de machines physiques pour le débogue.
Avant, mais ça c’était avant, il fallait enregistrer une machine (et pas plusieurs) via un système d’activation en ligne super bancale et complexe. A l’époque de Windows Phone 7 le service de support de Microsoft a essayé de m’aider pendant des semaines car même eux ne comprenaient pas pourquoi ça ne voulait pas marcher. Une horreur. Là où pour Android il suffisait déjà de brancher n’importe quelle machine en USB et rouler jeunesse !
Pour faire fuir les développeurs il n’y avait pas mieux que ce système tordu, complexe et capricieux.
Donc c’était avant et je suis bien content !
Aujourd’hui il suffit d’aller dans les bons menus d’une machine Windows 10 et dire comme pour Android qu’on débloque le mode développeur. Et c’est tout bon.
Normalement ça ne devrait pas donner l’occasion d’un paragraphe entier une telle feature, çà devrait être naturel depuis le début. Mais étant donné le saut gigantesque entre “avant” et “maintenant”, ça mérite d’être dit. Le Microsoft version Nadella a l’esprit pratique et s’affranchit des trucs tarabiscotés à la Sinofsky /Ballmer qui ont fait perdre des années à tout le monde… Il y a malgré tout un vrai changement de mentalité salutaire (même si Nadella a été choisi par ceux d’avant ce qui faisait craindre le pire. Mais le pire n’est jamais certain, la preuve).
Une seule App, vraiment
Un seul binaire tourne sur toutes les machines. Pas un code compilé pour 10 cibles avec 10 binaires, non un code, un binaire, toutes les machines.
Le concept d’Adaptive App
L’adaptabilité est un concept phare de UWP, c’est l’essence même de ce dernier qui sinon n’apporterait rien. Ce fut le cas de WinRT qui en réalité n’apportait rien par rapport à .NET sauf qu’il permettait de faire des applis pour le menu à tuile dont personne n’a voulu. Techniquement WinRT était une approche intéressante mais dans la pratique pas d’intérêt (même pas mal de gênes en raison de sa nature sandboxée).
UWP marque une différence de taille par rapport à WinRT, UWP apporte quelque chose : l’universalité mais aussi la simplicité d’un seul code pour toutes les machines. C’est une avancée extraordinaire. Le passage de .NET à UWP se justifie pleinement par les exigences du monde réel aujourd’hui inondé de machines très différentes les unes des autres mais étant toutes des ordinateurs qu’il faut programmer !
A cela .NET n’offre qu’une réponse imparfaite (Mono et Xamarin principalement). UWP est conçu pour relevé ce défi, là est son avantage incontestable.
En réalité on chipote car du point de vue du développeur tout cela revient un peu au même. Même si quelques namespaces changent de ci ou de là, le développeur .NET n’a pas l’impression de changer d’environnement, c’est juste un .NET un peu modifié (en apparence). Un peu comme la mort de Silverlight n’a heureusement pas impliqué celle de XAML qui se retrouve au cœur de Windows depuis la version 8.0.
On pourra d’ailleurs dire ce qu’on veut, on a longtemps reproché à Microsoft son art consommé de la rupture totale. On a par force associé certains changements comme la fin de Silverlight à cette pratique détestable. Mais en réalité depuis Vista et la sortie de WPF, le développeur qui manipule C# et XAML a pu sans trop de travail s’adapter à tous les changements, de Silverlight, WPF à WinRT jusqu’à UWP aujourd’hui. La critique a été assez facile pendant longtemps pour qu’on puisse se permettre de relever, a contrario, cette exceptionnelle cohérence dans le monde Microsoft pour le développeur depuis une dizaine d’années malgré les bouleversements technologiques vécus entre temps.
Ainsi, avec le concept d’Adaptive Apps :
- Une app s’adapte aux différentes versions de la plateforme (compilation conditionnelle, tests au runtime)
- Une app s’adapte aux différents type de machine (tests du support de certaines API par exemple)
- Une app s’adapte aux différentes résolutions (états visuels XAML spécifiques par exemple)
Les Adaptive UI sont capables en effet de gérer plusieurs type d’écran dans le même code. Tout comme l’Adaptive code peut exécuter certaines parties uniquement sur certaines machines dotées de certaines propriétés.
Il est important de comprendre ce mécanisme d’adaptabilité. C’est la réponse trouvée par Microsoft pour résoudre la quadrature du cercle : comment avoir un seul code binaire qui peut s’adapter à autant de cibles si différentes ?
On l’a vu dans des domaines beaucoup plus limité avec MvvmCross (pour les smartphones et tablettes) ce que l’adaptabilité oblige comme gymnastique. Toujours dans le monde restreint des mobiles on voit l’effort à fournir même à l’aide des Xamarin.Forms. Alors imaginons un peu l’effort insensé pour supporter à la fois un Raspberry et un PC, des Hololens et une tablette Surface !
Certes comme je le disais c’est l’idée de Silverlight qui est poussée au bout de sa logique : un runtime qui présente une face identique aux applications mais qui est adapté à chaque plateforme. Sauf que pousser le concept au niveau de l’OS intellectuellement est une chose, le réaliser et le rendre “praticable” en est une autre ! UWP c’est pourtant ce pari fou qui se réalise.
L’Adaptive design & UI
Le code adaptable j’aurai l’occasion d’y revenir dans des exemples concrets, l’idée est géniale mais une fois énoncée ce n’est qu’une façon d’écrire du code ce n’est pas forcément très excitant en soi. De plus faire du code “portable” depuis Xamarin on savait grosso-modo le faire correctement. Avec UWP c’est juste un principe intégré à la plateforme elle-même. C’est plus puissant, plus propre, mais ce n’est pas une idée nouvelle.
Le véritable chalenge dans une application c’est de gérer les différences phénoménales au niveau des UI !
Xamarin.Forms est une réponse possible (pour le cross-plateforme) mais limitée à un domaine précis et encore ce n’est pas parfait il faut bricoler un peu dans de nombreux cas pour faire vraiment de belles choses. La faute en revient aux OS sous-jacents qui sont préhistoriques comme iOS ou Android.
Mais sous Windows et avec XAML on travaille en vectoriel. C’est à dire le mode le plus sophistiqué qui soit et qui se trouve le mieux adapté au monde actuel de l’informatique. Une ellipse en vectoriel reste une ellipse peu importe la résolution. Sous Android il faut de tas d’images PNG différentes selon l’orientation (et oui une ellipse c’est pas un cercle !), la résolution, la taille écran, etc. C’est une vraie catastrophe. Et iOS ne fait pas mieux, si ça semble plus simple c’est que le monde fasciste d’Apple ne propose qu’un seul modèle de machine à ses clients là où Android est supporté par des centaines de machines différentes.
Mais posséder XAML aussi fantastique que cela soit (je suis un adorateur fou de XAML depuis toujours) ne résout pas forcément tout. Beaucoup mais pas tout. Il faut y ajouter quelques pincées de logique bien pensée pour que cela devienne universel. Comme les adaptive triggers qui déclenchent des états visuels XAML selon des seuils (taille, résolution…).
Prenez Groove par exemple, le lecteur de musique de Windows 10. Si on le réduit au minimum il ressemble à cela :
Cet affichage on le soupçonne pourra fonctionner presque identiquement sur un smartphone. La mise en page en tout cas (avec peut-être des boutons plus gros). Mais si j’agrandi la fenêtre l’approchant d’un format tablette on voit alors :
La barre bleu s’est allongée, elle affiche des informations sur le disque en cours. La liste des pochettes prend maintenant une place plus importante mais apparait à gauche un système de menu facilitant le pilotage du logiciel.
L’adaptive Design c’est ça : Prévoir une mise en page différente selon la résolution et la taille de l’écran. Le tout dans un même code XAML avec un seul exécutable.
Prenons cet autre exemple entre un smartphone et un PC portable :
La mise en page est différente, jusque dans la taille du bouton permettant de raccrocher qui est agrandi pour le smartphone (facilitant la manipulation d’une main) ce qui n’est pas le cas de la version PC adapté à un clic souris ou un touch du doigt sur Surface.
Adaptive Design & UI c’est penser la mise en page en constante évolution, en mouvement permanent, mais avec un seul code XAML… Et cela UWP le permet.
XAML possède déjà une énorme souplesse, ce que UWP ajoute c’est par exemple la notion de pixels effectifs différents des pixels physiques. Des algorithmes ont été pensé pour que l’œil voit toujours le pixel de la même façon alors que les résolutions sont différentes mais aussi les distances d’utilisation (ce que les autres OS négligent)…
Prendre en compte les PPI c’est bien mais si on ne prend pas en compte la distance à laquelle une machine se regarde de façon habituelle cela n’est pas assez pour assurer le confort visuel de l’utilisateur.
Avec UWP on oublie les échelles, la résolution, les DPI et les centaines d’images dans des sous-répertoires, les nine-patches et autre aberrations aux XXIème siècle. On travaille en pixels effectifs. Et en XAML.
Ca aussi j’en reparlerai, mais c’était important de porter votre attention sur ces améliorations décisives de UWP en matière de Design des applications.
Franchement je suis soulagé et heureux : avec WinRT il fallait expliquer les raisons des limitations, avec UWP il faut faire découvrir des tas de possibilités nouvelles, c’est autrement plus sympa pour le blogger que je suis !
.NET natif
Impossible de finir ce tour d’horizon sans parler des bouleversements côté code même s’ils sont en partie invisibles. Les effets sont eux énormes.
Les langages managés comme C# deviennent encore plus rapides et efficaces une bonne raison à cela, .NET devient natif au sens le plus strict du terme.
.NET Native c’est une nouvelle génération de compilateurs dans le cloud. Les apps utilisent l’optimiseur de code C++ standard, elles possèdent un bootstrapper .NET car il n’y a plus de runtime ! .NET devient une partie de l’exécutable tout simplement, la plateforme n’a pas besoin du framework X ou Y. Le code produit est donc du vrai code machine même pour un langage managé…
Les bénéfices sont nombreux et se chiffrent d’après Microsoft à une vitesse de chargement d’une app 50% plus rapide et une occupation mémoire de 14% inférieur à l’équivalent .NET classique.
Binaire machine, optimisation “optimales”, pas de framework à déployer, moins de mémoire consommée, chargement plus rapide… la nouvelle plateforme a réellement de quoi séduire sur tous les tableaux.
Conclusion
Windows 10 est l’arbre qui cache la forêt UWP. Une forêt magique où tous les problèmes qui se sont entassés ces dernières années avec le foisonnement des form-factors trouvent une solution simple et élégante.
J’espère que ce petit tour d’horizon vous aura permis de saisir cette partie encore immergée de l’iceberg et que vous aurez plaisir à suivre les prochains articles qui iront plus en détail dans les possibilités concrètes de Windows 10 et UWP.
Stay Tuned !