Dot.Blog

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

Prism pour WinRT– Partie 1

[new:10/06/2013]Je l’ai déjà évoqué ici plusieurs fois, l’équipe Prism vient de publier les premiers rushs de “Prism pour WinRT” sur Codeplex, une spécification à laquelle j’ai participé en tant que membre du Developer Guidance Advisory Council. En toute logique je me devais vous présenter cette nouvelle guidance…

Prism or not Prism ?

Autant le dire immédiatement, Prism for the Windows Runtime - Prism pour WinRT - (appelé pendant son développement “Kona RI” pour Référence d’Implémentation “Kona”) n’a que très peu de choses à voir avec Prism pour WPF ou Silverlight.

L’équipe n’est certes pas tout à fait la même mais la différence ne vient pas de là. Elle tient à la nature même de WinRT qui a une philosophie radicalement différente de celle de WPF. Le mode fullscreen, l’absence de fenêtres secondaires, le tactile, le mode sandboxé, et les limitations de XAML sous WinRT font partie de ces choses qui interdisent de porter la même guidance de WPF à WinRT.

Il ne faut donc pas chercher dans cette version de Prism une quelconque analogie avec Prism pour WPF/Silverlight, il n’y en a pas, tant au niveau code qu’au niveau de la guidance elle-même. Seul l’esprit est le même : promouvoir les meilleures méthodes pour produire des applications fiables.

WinRT pour le LOB ?

C’est “ze question”. La nature même des besoins d’une application LOB en entreprise s’adapte en fait assez mal aux contraintes de WinRT et au mode fullscreen. C’est un problème de support et non de technologie. Sur tablette WinRT s’avère au contraire bien meilleur que WPF, d’où mon incompréhension devant le peu de courage à pousser Surface RT et l’empressement de Microsoft à sortir une Surface Pro dont la seule différence réelle est de rétablir le bureau classique. J’adore Surface RT et elle n’aurait jamais du être “lâchée” aussi vite. Le bureau classique n’a pour moi aucun sens ni intérêt pratique sur Surface car les applications classiques ne sont pas conçues pour de si petits écrans. Mais bon, les choses étant ainsi, faisons avec le monde tel qu’il est et non tel qu’on voudrait qu’il soit… Et tentons de répondre plus en détail à la question.

L’implémentation de référence (la “Kona RI” créée au départ) a fixé un scénario qui se veut orienté “business”, comme toute les implémentations de Prism. Il s’agit donc bien de développer des applications LOB ou dans cet “esprit” en tout cas, malgré les limitations déjà évoquées de WinRT. Or, durant les premières phases de l’étude il est très vite apparu que quoi qu’on fasse WinRT ne se pliait guère aux exigences habituelles des applications LOB… L’équipe de Prism n’a pas baissé les bras mais a un peu baissé ses prétentions sans trop l’avouer tout en essayant de trouver des solutions originales. De fait la RI ressemble plus à une application Web de type site marchand qu’à une “vraie” application LOB tel qu’on l’entend en entreprise sur un PC de bureau. Mais le résultat est assez convainquant et prouve que WinRT peut, dans un cadre aux limites qui doivent être comprises, servir à écrire des applications pour le monde de l’entreprise. Vous noterez le bémol dans ma façon de m’exprimer : je ne parle plus d’applications LOB mais d’applications pour le “monde de l’entreprise”. C’est une nuance à bien saisir.

On ne verra certainement jamais de WinRT dans les salles de marché par exemple. Fenêtres multiples ouvertes simultanément, écrans multiples où s’étalent des modules de plusieurs applications, tout cela est impossible avec la disparation du bureau classique et le mode fullscreen de WinRT sous Windows 8.

Dès lors soyons francs WinRT sous sa forme actuelle n’est pas une panacée pour les applis LOB car cette nouvelle technologie n’est pas “complète” dans le sens où elle n’est pas en mesure de remplacer totalement et immédiatement l’existant tel que WPF ou même Windows Forms dans les circonstances précises du LOB. Toutefois des pans entiers d’applications peuvent fort bien trouver sur les tablettes un cadre parfait pour s’épanouir. On peut penser à des présentation de catalogue, de la prise de commande, de la saisie de devis autant que des tableaux de bord avec graphiques. Cela fait tout de même beaucoup de choses !

WinRT souffre de problèmes de jeunesse (comme les manques dans XAML tels les Behaviors), mais aussi d’un problème d’UX fondamental, sur PC de bureau le fullscreen et la suppression de la métaphore du bureau ne semble pas une approche pertinente. C’est ainsi plutôt sur tablettes qu’on s’essayera aux applications d’entreprise sous WinRT. Mais, avantage de la plateforme, ces mêmes applications pour tablettes tourneront sur PC aussi. Il faut donc le voir dans ce sens, et l’inconvénient se transforme en avantage !

Pour comprendre le problème d’UX sur PC il faut aller à la genèse de WinRT qui fait partie d’un plan particulier visant à conquérir le marché grand public pour sortir Microsoft de ses déboires sur le marché des unités mobiles. L’idée d’une plateforme unique pour tous les form factors est géniale. Mais WinRT a d’abord été conçu pour le mobile, Windows Phone mais aussi et surtout Surface RT. Et cela se sent. L’UX de Windows 8 sur PC n’est pas à la hauteur de son côté novateur, c’est d’ailleurs pourquoi Microsoft en fait l’aveu en annonçant aussi rapidement de grands changements dans Windows 8.1 sous la forme d’un “je vous ai compris!” et propose d’ailleurs d’offrir cette mise à jour. Une si grande générosité n’a de sens que dans l’aveu d’une “faute” qu’on cherche à effacer.

Ainsi l’idée un peu saugrenue de porter à l’identique le WinRT tablette sur les PC de bureau s’est imposée dans ce schéma d’un OS pour tous les form factors sans que vraiment on s’interroge sur le bienfondé de cette démarche. Un seul OS, une seule plateforme de développement, et un seul look, tout cela semblait tellement parfait. Mais cela implique aussi, hélas, une seule UX. Or, ce qui est bien conçu pour une tablette ne l’est pas forcément pour un PC de bureau.

WinRT est une plateforme que j’aime et que je trouve intéressante à plus d’un titre. Ce qui ne va pas, au moins pour l’instant, c’est de l’avoir portée “tel quel” de la tablette au PC et de l’imposer comme “seul et unique futur” de Windows alors même que WinRT n’est tout simplement pas capable d’assumer totalement ce rôle à l’heure actuelle. WPF est négligé, faisant partie d’un passé révolu, alors même qu’il reste le seul et unique moyen de faire des applications modernes sous Windows s’affranchissant des limitations de WinRT (principalement la sandbox et le fullscreen mais aussi les machines équipées de Windows 7 qui représentent un parc énorme).

Membre du DGAC, collaborateur sur le dernier livre de Eyrolles présentant le développement WinRT, auteur de nombreux billets ici sur le sujet, je me considère comme étant un bon spécialiste de la question. Et je dois avouer que sur PC de bureau WinRT n’est pas tout à fait utilisable pour du LOB. Au moins “un certain type d’applications LOB”. Comme je le disais plus haut il reste néanmoins de nombreuses applications du “monde de l’entreprise” qui peuvent parfaitement être écrites sous WinRT.

Alors à la question “WinRT est-il utilisable pour des applis LOB ?” je répondrais un peu la normande : oui et non… Non sur PC de bureau pour du LOB traditionnel, mais oui sur tablette pour certaines applications du “monde de l’entreprise”.

Quoi qu’il en soit, au moins sur tablettes, WinRT offre une bien meilleure UX que les applications classiques qui ne sont absolument pas conçues pour des petits écrans de 10” voire moins. Et techniquement, WinRT surtout avec C#/XAML est une plateforme de très loin supérieure à celles proposer par Apple ou Google.

Dans ce contexte quelle est la place et l’intérêt de Prism ?

Comme je viens de l’expliquer WinRT n’est peut-être pas une panacée et n’est certainement pas en capacité de pouvoir remplacer totalement des technologies comme WPF en bureau classique. Mais Il ne faut pas voir les choses avec dogmatisme, ni même trop écouter le langage commercial de Microsoft qui, par force, pousse la nouvelle technologie pour d’évidentes raisons ce qui interdit toute nuance dans le discours. Dans la réalité le bureau classique est loin de disparaitre non pas parce que je le “crois” comme une sorte de “conviction” personnelle, tout simplement parce que des milliers de logiciels professionnels ne peuvent absolument pas être portés sous WinRT en raison ne serait-ce que de la sandbox ou du mode fullscreen.

Cette situation est peut-être temporaire, mais elle va perdurer des années encore, peut-être toujours. Le jour où Adobe annoncera une version WinRT de Photoshop et de Illustrator ou Première, le jour où Cubase ou Ableton Live seront proposés en WinRT, ce jour là seulement on pourra dire adieu au bureau classique. Mais là c’est une conviction personnelle, je n’y crois pas. Une bonne raison à cela : si les développeurs indépendants et les petits éditeurs peuvent voir un intérêt d’être distribués sur le market place, les gros éditeurs déjà connus et faisant eux-mêmes leur CA ne sont absolument pas prêts à céder un pourcentage sur leurs ventes à Microsoft, leurs actionnaires ne le permettraient pas. Il y a donc une réalité économique et non technique derrière le maintien pour de longues années du bureau classique…

A l’heure actuelle au moins, il faut donc voir WinRT comme une nouvelle opportunité de concevoir des logiciels “autrement” ne remplaçant rien du tout mais s’ajoutant au contraire à la panoplie déjà disponible comme WPF.

Il y aura des applications (ou des morceaux d’applications) parfaitement à l’aise sous WinRT qui leur offrira même un écrin leur donnant encore plus de valeur, et il y aura des applications (ou des morceaux d’applications) qui n’auront de sens que sur PC de Bureau en multifenêtrage, donc sous WPF.

C’est plutôt vers une telle cohabitation intelligente que nous nous dirigeons. Une fois la langue, un peu de bois, de la phase de lancement très commerciale de Windows 8 / WinRT passée, Microsoft adoptera très certainement un discours plus nuancé.

D’ailleurs, dans le dernier livre paru chez Eyrolles sur le développement WinRT, livre auquel j’ai collaboré et écrit par des employés de Microsoft France, on voit déjà très nettement l’infléchissement du discours “tout WinRT”. Les solutions classiques sous WPF ne sont plus présentées comme des vieilleries hasbeen mais comme des alternatives parfois mieux taillées pour certains types de logiciels. Pour qui sait lire entre les lignes ce changement sous la plume de gens très officiellement liés à Microsoft est un signe qui ne trompe pas.

Une fois la place et l’avenir de WinRT et du bureau classique clarifiés on comprend qu’il existe et existera des créneaux tout à fait viables pour certains types d’applications d’entreprise sous WinRT. 

Dès lors disposer d’une guidance de qualité comme Prism se justifie totalement et prend tout sens.

Prism pour WinRT

Partant d’un scénario orienté business, l’équipe de Prism a débuté une implémentation dite de référence, la fameuse “Kona RI”. L’esprit étant de développer une application telle qu’elle pourrait l’être au sein d’une entreprise, avec les besoins d’un tel contexte, sans passer par le market place ni être conçue pour le grand public (type jeu ou réseau social).

En suivant le scénario et en implémentant AdventureWorks Shopper RI de nombreux problèmes propres au cadre WinRT ont du être réglés. A chaque étape l’équipe de Prism avec l’aide des membres du DGAC (Developer Guidance Advisory Council) s’est demandée comment généraliser le code, comment le rendre réutilisable. Le code mais aussi les méthodes utilisées qui deviendraient des guidances.

En menant ce travail de bout en bout, l’application de référence a été souvent modifiée, adaptée. Et dans les dernières étapes elle a été refactorée pour en ressortir tout le code réutilisable sous la forme d’une bibliothèque “Microsoft.Practice.Prism.StoreApps” et d’une série de recommandations écrites, le tout formant Prism pour WinRT.

Le lien entre Prism et Prism pour WinRT est donc purement conceptuel. Aucune partie du code de Prism n’a été réutilisée. Prism pour WinRT a été entièrement créé pour répondre aux problématiques WinRT. Certains trouveront dommage que le résultat soit justement si éloigné de Prism pour WPF et qu’il n’existe aucune compatibilité entre ces deux versions de Prism, mais c’est un choix assumé en raison des différences trop importantes entre les deux mondes.

L’esprit de Prism, le concept, est justement de formuler des guidances en adéquation avec la plateforme visée et non pas d’adapter une méthodologie unique à plusieurs plateformes… Prism est un concept, celui des meilleurs moyens pour créer des applications fiables sur une plateforme donnée. Cela implique dans les faits des guidances et des implémentations totalement différentes si les plateformes le sont aussi. Et c’est le cas.

On notera, en écho à mes propos d’introduction, que la RI en question s’appelle AdventureWorks Shopper RI, c’est à dire, l’implémentation de référence du consommateur/client de AdventureWorks. Autrement dit une application native de vente destinée aux clients (fictifs) de la société (fictive) AdventureWorks.

AdventureWorks est l’application RI de Prism pour WPF et Silverlight. Il s’agit d’une société fictive permettant de démontrer plusieurs aspects de la programmation d’applications LOB.

La spécification Prism pour WinRT n’est pas “AdventureWorks” mais la partie “site marchand” de AdventureWorks…

Il ne s’agit donc plus ici de prétendre développer une application LOB classique, mais bien d’utiliser au mieux le support tablette pour développer une partie bien spéciale de l’application. On reste dans le “monde de l’entreprise” mais on n’est plus dans le LOB proprement dit…

On pourrait reprocher d’ailleurs à cette RI d’être une application “externe” destinée aux clients de l’entreprise et de n’être justement pas une application utilisable _dans_ l’entreprise. Mais après tout c’est aussi un besoin de l’entreprise que de séduire ses clients et les fidéliser…

La question finale que soulève cette approche c’est qu’en regardant AdventureWorks Shopper RI on se demande si dans la réalité de l’entreprise on n’aurait pas fait un meilleur choix en optant pour une implémentation sous ASP.NET MVC avec HTML pour une telle application de vente en ligne… Cela aurait été mon conseil si un client m’avait posé la question. Une telle application aurait eu l’avantage de fonctionner aussi depuis une tablette Apple ou Android sans aucune modification. L’avantage du natif ne semblant pas décisif dans ce cas précis qui n’est qu’un site de vente en ligne.

Comme vous le voyez il m’est très difficile de vous donner un conseil aussi clair que d’habitude, je ne cacherais pas mes propres doutes et questionnements sur la place de WinRT en entreprise. Mais finalement mon conseil tient aussi dans ce doute que je partage avec vous…

Après tout, le choix de ce scénario par l’équipe Prism n’était peut-être pas le bon car il prête le flanc aux attaques sur l’intérêt même de WinRT, c’est un problème que j’ai soulevé dès les premières réunions du DGAC, mais ce n’est qu’une RI, un simple exemple d’implémentation qui devait rester simple à comprendre par tous sans imposer un lourd contexte plus réaliste. Nul doute qu’en situation vous aurez milles autres idées de développement plus proches des vraies besoins de votre entreprise.

Conclusion

Je vais tenter de conserver un format compatible avec le support “blog” en évitant de faire un papier à rallonge… C’est donc la fin de cette première partie qui présente à la fois Prism pour WinRT et les raisons pour lesquelles je vous présente cette guidance sans masquer les questions que l’utilisation de WinRT pose en entreprise, ni les opportunités qu’elle ouvre aussi.

J’agis ici en éclaireur, je montre un chemin, à vous de le prendre ou non. Mais pour vous faire votre propre idée le mieux c’est encore de savoir de quoi le chemin sera fait. Et cette étude de Prism est là pour vous aider à faire les meilleurs choix technologiques.

Pas de dogmatisme donc, ni de propagande, une simple présentation d’un travail intelligent pour vous permettre de l’utiliser au mieux ou de savoir pourquoi vous ne l’utiliserez pas. C’est open ! (mais si vous devez faire du LOB en WinRT, ne pas utiliser Prism pour WinRT faute de le connaitre serait vraiment dommage).

Alors pour la suite qui montrera Prism pour WinRT par l’exemple…

Stay Tuned !

blog comments powered by Disqus