Cela pourrait être une fable avec un peu trop d’acteurs mais le même récit un peu triste et à la fin une morale… En effet comme on dirait pour un statut amoureux sur Facebook “c’est compliqué” ! …
C’est compliqué !
En ce moment nous avons le droit à un petit festival de mises à jour de VS 2017, 15.4.2, 15.4.3 et ses amis qui suivent, avec chacun d’entre nous des expériences différentes (plantage complet, pertes de certaines fonctions ou alors tout va bien, mais dans ce cas là vérifiez tout de même ce que faisait votre compagne/on hier soir !).
Le plus fun c’est que cela s’ajoute à des mises à jour de Xamarin.Forms, de Prism, et toute la famille et que dans cette joyeuse effervescence vient s’inviter celui qu’on attend mais pas si vite : .NET Standard 2.0.
On s’imagine, non, on constate plutôt le fouillis que cela peut engendrer et ce n’est pas drôle pour tout le monde. Certains lecteurs savent de quoi je parle 
Non, c’est pas compliqué, c’est le souk…
Il faut être franc, c’est le bazar. C’est pas compliqué, tout est simple, mais rien ne marche comme prévu.
Par exemple le template Prism prévu pour PCL se met à faire des projets .NET Standard mais qui ne compilent pas, par force. Il faut deviner qu’il y a une mise à jour du 11 novembre dernier qui est étudiée pour tourner sous .NET Standard. Elle créée ainsi du .NET 2.0 Standard aussi mais au moins ça marche.
Enfin… ça marche une fois. En tout cas j’ai réussi une fois à compiler et à avoir quelque chose sur le smartphone. En acceptant de perdre l’Intellisense sous XAML. Un peu dommage…
Mais ça ne marche plus la seconde fois. Les messages d’erreur sont assez abscons et on ne sait pas trop s’il faut tout reformater et réinstaller Windows ou juste fracasser son UC et aller à la pêche… C’est bien la pêche, c’est paisible, c’est cool…
Une solution docteur ?
Comme disent les médecins un rhume non soigné dure une semaine, et un rhume bien soigné dure sept jours…
Donc ici le mieux c’est de ne pas mettre à jour Visual Studio, conserver son environnement de développement stable, faire le gros dos, et attendre que “ça passe”, comme un gros rhume. Car comme à chaque fois qu’il y a un passage de flambeau comme .NET Standard 2.0 mieux vaut débrancher son PC d’internet pour ne faire aucune mise à jour et attendre une bonne année que ça murisse…
C’est dommage d’un autre côté de se passer des nouveautés de Xamarin.Forms qui évolue sans cesse.
Et puis c’est trop tard vous avez fait les mises à jour…
- “Il me reste combien de temps doc’ soyez franc…”…
- (le toubib montre sa main ouverte)
- Quoi ? 5 ans !!!
- …
- Comment çà 5 mois ? !
- …
- 5 jours ? !!!!
- (le toubib annonce chaque chiffre en pliant doucement chaque doigt) 5 – 4 – 3 …
C’est flippant hein ? Et bien c’est un peu ça en ce moment, mais ça va passer, faut pas s’en faire. Faut juste passer le coup de tabac sans finir à la mer…
La méthode russe
La méthode russe ? Da tovaritch développeur !
Comme chez les russes, on n’a pas de moyens mais avec de l’ingéniosité et trois bouts de ficelle on fait pareil que les américains avec un budget stratosphérique…
Donc on commence par se passer du luxe paresseux et bourgeois des templates de Prism.
A la russe, on va tout faire à la main !
Ensuite on oublie .NET Standard 2.0, c’est génial, ça devient la norme, mais laissons aux équipes de MS le temps de serrer les boulons qui se débinent un peu partout… On va pas se laisser démonter pour si peu ! … Heu si, ça se démonte même tout seul chef ! – J’ai vue seconde classe, j’ai vu…
La main plus sophistiquée qu’une fusée et pas de mises à jour à faire !
Donc on va reprendre calmement sans s’énerver, le cran est ce qui caractérise le mieux les héros. Et on va faire tout à la main, c’est pas si compliqué.
1 – Créer le projet (la solution)
Dans C# / Cross-Platform on choisit une application Xamarin.
On répond aux quelques questions habituelles (non de l’appli etc) ainsi qu’au dialogue demandant des détails sur le mode de création, là on préfère choisir le mode PCL.
On valide tout ça, on attend que Visual Studio ait créé tous les projets.
On obtient une belle solution Xamarin.Forms qui marche très bien.
Mais elle n’a pas encore Prism…
2 – Ajouter Prism à la mimine
Ajouter Prism n’est pas très compliqué mais quand on est habitué aux templates forcément on sent comme un vide… Car simple ne veut pas dire évident.
Les paquets
Première chose : vérifier que les paquets sont bien installés.
On va choisir Prism.Forms, puis Prism.xxx.Forms où xxx est le nom du conteneur IoC, DryIoc par exemple. Ensuite on installe xxx lui-même. On fait cela pour tous les projets
Les folders
On créée les répertoires Views et ViewModels dans le projet PCL.
Ensuite on déplace dans Views la MainPage.xaml et son code behind. Si on a déjà plusieurs pages on fait pareil pour toutes.
On n’oublie pas de corriger le namespace dans le code behind et dans la page XAML.
Le type de l’App
On va dans App.Xaml.cs et on change l’héritage. App devient un descendant de PrismApplication. Cette classe est définie dans Prism.xxx, c’est à dire qu’elle porte toujours ce nom mais est différente selon le conteneur IoC choisi. Le constructeur de la classe doit être changé aussi :
On vire tout le code de base qui ne sert plus à rien mais en revanche on override les deux méthodes OnIntialized() et RegisterTypes qu’on complète selon les Views et les ViewModels qu’on possède. Si on part d’un projet vierge on n’a pour le moment qu’une seule View, MainPage et pas encore de ViewModel ce qui va donner :
Dans cet exemple le conteneur est Unity. Il est vrai que Unity est cuit, fini, plus maintenu et lent… Oui mais ne l’enterrons pas si vite ! Je sais qu’une version 5 est en cours de préparation qui pourrait relancer ce conteneur IoC dans la bagarre !
Bref, dans OnInitialized() on initialise… et dans RegisterTypes on enregistre les types … Celui de la page de navigation, toujours déclarée en premier et ensuite les pages à disposition, pour l’instant MainPage donc.
Au niveau des pages il n’y a plus rien à faire puisqu’il n’est plus nécessaire d’ajouter l’initialisation de AutoWire, sauf si on veut le mettre à False, ce qui certainement très rare.
Les ViewModels
Si vous venez de créer la solution, forcément il n’y en a même pas un. Il faut le créer (au moins pour MainPage).
Pour cela il suffit de créer une classe qui s’appellent MainPageViewModel, le suffixe permettant le lien automatique avec la page. Cette classe descend de BindableBase fournie par Prism. En dehors de cela elle n’a aucune contrainte.
En général le constructeur utilise l’injection de dépendance pour récupérer le gestionnaire de dialogue, le service de navigation, mais tout cela est optionnel malgré tout.
Le ViewModel expose aussi des propriétés et des commandes, mais encore un fois c’est à vous de décider en fonction du besoin, ni les Xamarin.Forms ni Prism ne vous oblige à quoi que ce soit.
Le ViewModel de MainPage pourra donc ressembler à cette version minimaliste avec juste une propriété Titre exposée pour faire joli. On notera que la méthode indiquée marche aussi bien pour un projet en mode Shared plutôt qu’en PCL.
Les initialiseurs de plateforme
Là encore rien de bien méchant puisqu’il s’agit juste de créer une instance de la classe partagée App en lui passant en référence une méthode qui peut être utilisée pour ajouter dans le conteneur IoC des choses spécifiques à la plateforme en question. Souvent vide, cette section doit tout de même être déclarée :
Sous Android, dans la MainActivity, en fin de code on change un peu le code de l’appel à LoadApplication et on ajoute la classe d’initialisation :
Sous iOS et UWP c’est le même principe. Toujours avec une classe supportant IPlatformInitializer et sa méthode RegisterTypes généralement vide comme je l’ai dit.
C’est fini !
Et oui, c’est pas si compliqué que ça…
Conclusion
Au final on a une belle solution PCL fonctionnant sous .NET, généralement le profil 259, avec Prism, bref le grand pied bleu pour démarrer une App qui fera un succès !
Pour l’instant on laisse de côté le template Prism, l’ancien comme le nouveau, les mises à jour bizarres de Visual Studio, et on se tient à l’écart de .NET Standard 2.0 qui va devenir la norme, c’est en cours, mais franchement on voit que le chantier n’est pas totalement terminé. Si cela se trouve dans une ou deux mise à jour, c’est à dire dans quelques jours vu le rythme actuel (!) tout sera rentré dans l’ordre. Mais en attendant il faut bien avancer.
Avant Visual Studio était peu mis à jour. C’était parfois un peu long pour bénéficier des nouveautés mais on disposait de grandes plages de calme pour travailler et faire ce pour quoi nous sommes payé et non pour réparer les outils.
Désormais Visual Studio fait des mises à jour tout le temps, et des mises à jour du programme de mise à jour aussi. Dans cette intense bourdonnement forcément il y a plein de ratés et on a un peu l’impression que Visual Studio n’est plus qu’un logiciel en béta test permanent…
Ca va se tasser, mais c’est un peu pénible je l’accorde. .NET Standard 2.0 est une idée géniale pour fédérer tous les .NET sans tous les réécrire, mais mettre au diapason Visual Studio, les toolkits tiers, les templates, etc, ça ne peut pas se faire en deux jours. On aimerait que MS prenne un peu plus de temps pour nous livrer des choses utilisables et fiables, c’est certain.
Mais le magasin reste ouvert pendant les travaux !
Malgré ces petits soucis temporaires, on peut continuer à profiter de Visual Studio, de Xamarin.Forms et de Prism, juste en se servant de ses mains !
Stay Tuned !