[new:30/08/2012]Quand on connait déjà Silverlight, la question qui se pose tout de suite est de savoir comment réutiliser au mieux son savoir-faire sous WinRT, ce qui implique de comprendre et connaître les différences principales entre les deux plateformes. Dans cette première partie j’aborderai les déclarations des espaces de noms, car sans eux, rien ne tourne.
WinRT englobe la quasi totalité de Silverlight
C’est le premier point à savoir, et il est plutôt encourageant, WinRT englobe la quasi totalité de Silverlight. Comme je vous en ai parlé dans mon billet “De Silverlight à WinRT : Mesurez les différences grâce au “WinRT Genome Project” sur les 2189 classes de Silverlight (de base) on en retrouve 1582 dans WinRT, avec une différence de 607, absentes, qui pour beaucoup concernent des choses inutiles sous WinRT comme l’Out Of Browser par exemple.
Je renvoie le lecteur à ce billet pour plus de précisions et notamment pour l’adresse d’un site qui compare les équivalences Silverlight / WinRT au niveau des types et des membres communs ou non. Cela peut être d’une très grande aide lors d’un portage de code, ou simplement pour trouver une équivalence quand on développe.
La déclaration “classique” d’un espace de noms
Silverlight et WPF partage de ce point de vue une syntaxe similaire.
Pour déclarer un espace de noms “MaLib.dll” contenant l’espace de noms MaLib.MesOutils on écrit, en Xaml :
1: xmlns:local="clr-namespace:MaLib.MesOutils;assembly:MaLib"
On déclare de façon identique, mais simplifiée, l’accès à des espaces de noms contenant dans l’assemblage courant (celui qui contient le code Xaml dans lequel on veut ajouter la déclaration) :
1: xmlns:local="clr-namespace:MaLib.MesOutils"
On remarque que seule disparait la référence “assembly” qui point l’assemblage, la DLL ou l’exe en cours étant pris par défaut.
La déclaration sous WinRT
Même s’il semble que l’ancienne syntaxe puisse passer dans certains cas (ce n’est pas très clair puisque nous en sommes toujours à des bêta), WinRT impose une nouvelle syntaxe. Est-ce temporaire ? Nous le saurons bientôt...
Les grands différences sont :
- L’utilisation de “using” à la place de “clr-namespace”
- L’absence systématique du nom de l’assemblage
De fait, la déclaration précédente devient :
1: xmlns:local="using:MaLib.MesOutils"
Utiliser le même code Xaml ?
La proximité entre Silverlight et WinRT est telle qu’on est tenté de se demander comment est-il possible d’utiliser le même code pour les deux plateformes...
C’est légitime mais hélas les constructions #IF n’existent pas en Xaml...
Soit les déclarations à la Silverlight/WPF restent compatibles dans la version finale de WinRT et dans ce cas tout ira bien, soit il sera nécessaire de créer des fichiers Xaml légèrement différents.
Les déclarations dans le code
Les espaces de noms qui concernent l’UI ont été changés sous WinRT. Globalement, “System.Windows” a été remplacé par “Windows.UI.Xaml”. D’autres changements de ce type sont intervenus. Mais côté code nous disposons heureusement des constructions de type #IF et d’un marqueur spécifique à WinRT “NETFX_CORE”. Il devient donc très facile de construire un code C# pouvant s’adapter aisément aux deux plateformes, au moins en ce qui concerne les espaces de noms.
Une groupe Using fonctionnant aussi bien en Silverlight qu’en WinRT ressemblera ainsi à cela :
1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4: using System.Text;
5: using System.Threading.Tasks;
6: #if !NETFX_CORE
7: using System.Windows;
8: using System.Windows.Controls;
9: using System.Windows.Data;
10: using System.Windows.Documents;
11: using System.Windows.Input;
12: using System.Windows.Media;
13: using System.Windows.Media.Imaging;
14: using System.Windows.Navigation;
15: using System.Windows.Shapes;
16: #else
17: using Windows.UI.Xaml;
18: using Windows.UI.Xaml.Controls;
19: using Windows.UI.Xaml.Data;
20: using Windows.UI.Xaml.Documents;
21: using Windows.UI.Xaml.Input;
22: using Windows.UI.Xaml.Media;
23: using Windows.UI.Xaml.Media.Imaging;
24: using Windows.UI.Xaml.Navigation;
25: using Windows.UI.Xaml.Shapes;
26: #endif
Encore une fois il s’agit d’illustrer le propos, certains espaces de noms pouvant encore changer dans la version finale à venir.
On pourra aussi s’inspirer d’une documentation Microsoft qui traite de ces différences “Migrate/port a Windows Phone 7 app to a Metro Style App”.
Conclusion
Ne nous attachons pas trop à ces problématiques tant que nous ne disposons pas d’un produit final pour juger des vraies différences définitives.