[new:31/08/2014]Les deux premiers volets de cette série vous ont montré les grandes lignes du cross-plateforme avec Xamarin.Forms. Nos exemples tournaient sous Android. Il est temps de les faire tourner sous Windows Phone !
Windows Phone
On le sait tous Windows Phone a eu des débuts difficiles. Si difficiles que bien que présent depuis des années il a toujours des parts de marché qui ressemblent aux premières semaines du lancement d’un nouveau produit … Mais nous sommes là pour cela change non ?
Windows Phone est pourtant depuis sa première apparition (Windows Phone 7 sous Metro / Silverlight) le meilleur OS mobile qu’on puisse trouver. Aujourd’hui la version 8.1 est vraiment au top de ce qu’on peut attendre d’un tel OS. Peu-être pas forcément pour le grand public, sinon ça se verrait d’ailleurs, mais nous les professionnels œuvrant principalement en entreprise on le sait.
Le quidam ne peut savoir la beauté de C#, l’importance du vectoriel de XAML dans un monde noyé par les form factors, la puissance d’un EDI comme Visual Studio, l’incroyable qualité d’un outil de design comme Blend, la force d’un framework comme .NET … Non, le quidam de la rue ne voit que des tuiles qui ne lui plaisent pas depuis le premier jour. Et c’est vraiment dommage. Car s’il savait ce qu’était Cocoa et son C minable tout autant que les bricolages odieux de type nine-patches des UI Android, il préfèrerait certainement lui aussi la pureté et la cohérence de Windows Phone.
C’est que quelque part on lui explique mal et qu’on refuse de lui mettre un bureau classique comme tout le monde, ce que Microsoft commence à faire sur PC après l’erreur W8 et de ces fichues tuiles qui sont à la base de tous les derniers flop... Je peux toujours dire du bien de Windows Phone ici, c’est un blog que le quidam ne lit pas… néanmoins en rappelant aux professionnels que Windows Phone est tout de même ce qui se fait de mieux, même du point de vue du développement, peut-être arriverai-je à influencer un peu le quidam… Nous sommes des geeks pas des no-live donc on connait aussi des quidam que nous pouvons convaincre !
Et d’ailleurs dans cette quête évangélique motivée par mon vrai amour de Windows Phone et non pour faire plaisir à qui que ce soit, je vais vous montrer comment on ajoute le support de Windows Phone a notre application de démo d’hier !
Attention ça va très vite !
Je vais décomposer le mouvement en le filmant à très haute vitesse car l’action va très vite, préparez-vous pour ne rien louper …
Bon, ça va être tellement court qu’avant d’y aller je veux vous parler de deux choses importantes :
L’enregistreur d’action de l’utilisateur
Au lieu de pirater SnagIt ou équivalent savez-vous que Windows, depuis la version 7, est fourni avec un “enregistreur des actions de l’utilisateur” ?
Kesako ? Un super mouchard pour tenter de piéger les bugs. Mais on peut aussi s’en servir pour enregistrer toute action dont on souhaite garder une trace, pour une démo, un article…
Bouton démarrer / lancez : psr
L’intérêt de cet utilitaire est de prendre automatiquement des screenshots de tous les écrans installés en une seule image, de montrer où l’utilisateur a cliqué, et de fournir des commentaires très précis (par exemple le nom des boîtes de dialogue, le nom des entrées de menu sélectionnées, etc).
C’est vraiment un super outil, j’espère vous avoir fait découvrir là un truc gratuit et très puissant qui vous sera très utile (on peut demander à un user de lancer PSR et de faire normalement les manips “qui plantent”, il suffit ensuite de récupérer les fichiers de PSR pour “voir” ce qui a été fait. C’est donc parfait en local mais aussi pour du dépannage à distance comme si on était assis derrière l’utilisateur… Futé !).
Bien entendu, pour lever toute ambigüité, c’est dans Windows 7 et 8, c’est gratuit, et cela n’a rien à voir avec l’utilitaire de capture écran, pratique mais incapable de faire le reporting précis et automatique de PSR.
Les références de projet partagés
Tel que nous y allons là, la fleur au fusil, on va vite être déçu… En effet nous avons choisi dans la solution originale d’utiliser un projet partagé pour le code commun au lieu d’une PCL. Je reparlerais des différences mais les deux sont ok.
Seulement voilà, même avec tout bien installé, il est impossible d’ajouter la référence au projet partagé dans le projet Windows Phone… L’option n’existe pas et si on tente de bricoler à la main le fichier projet ça peut tourner à la catastrophe facilement.
Il faut savoir que les projets partagés de Xamarin.Forms se basent tout simplement sur les “Projets Universels” dont je vous ai déjà parlés (voir “Template d’applications universelles : convergence WinRT et Windows Phone” d’avril dernier).
De ce fait il est possible d’ajouter la référence comme on le ferait pour un projet d’application universelle. Mais cela n’existe pas encore dans VS. Mais il y a une solution : le Shared Project Reference Manager, extension gratuite pour Visual Studio qu’il suffit d’installer… Et Ô magie, une fois le projet Windows Phone ajouté à la solution il sera possible d’ajouter la référence au projet partagé comme d’importe quelle autre référence.
Vous ne pourrez pas dire que je ne vous mâche pas le travail !
En parlant de travail d’ailleurs si nous étions en temps réel, vous auriez connu une coupure de quelques heures entre les lignes précédentes et celles-ci… Certains l’ont vu, Dot.Blog s’est fait hacké et un billet en anglais sur la pilule abortive s’affichait… Comme Dot.Blog est souvent balayé par Google, c’était déjà dans ce dernier avant même que je ne m’en aperçoive ! Quelques lecteurs m’ont prévenu et je les en remercie. C’est normalement réparé mais ayant ce billet en cours je n’ai pas pris plus de temps pour comprendre quelle faille a été utilisée… Si quelqu’un à une idée (j’utilise BlogEngine en ASP.NET bien entendu) je suis preneur…
Bref, Dot.Blog remarche normalement semble-t-il, je peux reprendre le cours de l’article !
Phase 1 : Ouverture de l’ancienne solution
Toujours même principe, je fais un copier / coller de la solution d’hier et je renomme uniquement le répertoire de niveau supérieur. Aujourd’hui il s’appelle donc DotBlogTestXaml2.
Je me positionne sur la solution, clic droit, ajouter nouveau projet :
Je choisi le plus simple, “Blank app (Windows Phone Silverlight)”.
Notre solution ressemble donc maintenant à cela :
Je vais placer le projet Windows Phone en projet par défaut, et ajouter la référence au projet partagé grâce au petit plugin évoqué plus haut :
La référence est bien ajoutée avec une icône reconnaissable (deux losanges verticaux entrelacés) :
Phase 2 : supprimer le code de démonstration et charger notre page
Bien entendu le projet Windows Phone par défaut contient un peu de code démo ce qui permet de le compiler immédiatement et de tester l’environnement de développement. Il faut supprimer ce code, peu de chose, uniquement dans la page principale.
Nous allons tellement faire le ménage que nous n’allons rien garder du code XAML sauf l’enveloppe de la page :
<phone:PhoneApplicationPage
x:Class="DotBlogTest.Phone.MainPage"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:phone="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone"
xmlns:shell="clr-namespace:Microsoft.Phone.Shell;assembly=Microsoft.Phone"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
mc:Ignorable="d"
FontFamily="{StaticResource PhoneFontFamilyNormal}"
FontSize="{StaticResource PhoneFontSizeNormal}"
Foreground="{StaticResource PhoneForegroundBrush}"
SupportedOrientations="Portrait" Orientation="Portrait"
shell:SystemTray.IsVisible="True">
</phone:PhoneApplicationPage>
C’est sur il ne reste rien, juste la PhoneApplicationPage.
Faisons un tour dans le code-behind et de même, retirons tout pour juste ajouter le chargement de la page liste du projet partagé mais juste avant il nous faut installer via les packages Nuget “Xamarin.Forms” :
Nous pouvons maintenant ajouter les quelques lignes nécessaires :
using Microsoft.Phone.Controls;
using Xamarin.Forms;
namespace DotBlogTest.Phone
{
public partial class MainPage : PhoneApplicationPage
{
// Constructor
public MainPage()
{
InitializeComponent();
Forms.Init();
Content = DotBlogTest.App.GetMainPage().ConvertPageToUIElement(this);
}
}
}
On retrouve l’initialisation des composants, comme pour toute page XAML, puis un appel à Forms.Init() qui met en route les Xamarin.Forms et enfin nous fixons la propriété Content de la page XAML en appelant le GetMainPage() de notre projet partagé, le même appel que dans le projet Android (comparez vous verrez !). Toutefois ce que retourne cette méthode n’est pas tout à fait du XAML il faut ainsi utiliser ConvertPageToUIElement() pour parfaire le traitement.
Phase 3 : Quelle phase 3 ?
Je ne plaisante pas, de quoi vous voulez parler ? Il n’y a pas de phase 3 puisque nous avons ajouté le projet Windows Phone et que nous avons initialisé sa MainPage grâce à Xamarin.Forms et à notre projet partagé.
Que voulez-vous faire de plus ?
Juste un Run pour se prouver que ça suffit ? C’est bien parce que c’est vous, en GIF animé en plus, Dot.Blog c’est vraiment la crème du top du luxe ! 
Conclusion
Je vous laisse tirer la conclusion vous-mêmes… Je suis certain que parmi vous il y en avait qui se préparaient à quelque chose d’un peu plus … rugueux. Je suis navré même en blablatant un peu, je ne peux honnêtement pas faire plus long.
Non, pour créer une application Windows Phone quand on dispose du projet partagé il faut en effet moins d’une minute chrono en main… Pareil pour Android, pareil pour iOS etc.
Tout le travail se trouve dans le projet partagé (ou la CPL) et c’est tout. Bien sûr que ce travail là peut être long et même délicat ! Je ne connais pas de projets qui s’écrivent facilement dès qu’ils font quelque chose d’intelligent… Mais ça c’est notre métier.
Notre métier ne consiste pas à faire de la plomberie pendant 7h pour coder deux lignes efficaces. C’est tout le contraire.
Et grâce aux Xamarin.Forms il possible de se concentrer enfin sur le code sans se prendre la tête avec la portabilité car _même_ l’UI est portable.
Vous êtes bluffé un peu j’espère… ou alors vous êtes blasé ! Moi j’ai été bluffé.
On verra bien d’autres choses sur les Xamarin.Forms ces trois premiers billets ne font qu’effleurer la surface. Alors pour ça…
Stay Tuned !
PS : le code du projet