Silverlight et WPF

Écriture d'applications Silverlight et WPF en tenant compte du XAML Windows Runtime

Pete Brown

Le XAML Windows Runtime (WinRT) pour les nouvelles applications du Windows Store est le tout dernier membre de la famille XAML et C#/Visual Basic qu'un grand nombre d'entre nous apprécient. Tout a commencé officiellement en 2006 avec le Microsoft .NET Framework 3.0 et « Avalon » (ensuite nommé Microsoft Windows Presentation Foundation, ou WPF). Plusieurs révisions de WPF ont suivi, dont la dernière, WPF 4.5, parallèlement à sept versions nommées de Silverlight (dont 1.1 et 5.1), plusieurs versions de Windows Phone, etc. Vous trouverez même une partie de la pile XAML disponible sur les appareils .NET Micro Framework.

Vous vous interrogez peut-être sur l'utilité d'un si grand nombre de variations sur XAML et le NET Framework. Bien que la plupart des implémentations aient mené à des utilisations similaires (Silverlight pour écrire des applications de bureau, par exemple), chaque plateforme a été développée et optimisée pour divers scénarios et plateformes cibles. Par exemple, Silverlight a été conçu en vue d'une utilisation multiplateforme et d'un hébergement Web. XAML sur Windows Phone a été conçu pour du matériel et des cas de figure liés aux téléphones, et le XAML WinRT sur Windows 8 a été conçu pour des performances élevées sur les applications du Windows Store simples (x86.x64 et ARM) et tactiles d'abord (mais pas uniquement tactiles).

Toutefois, ces implémentations du XAML ont de nombreux points communs. Ces similitudes sont la raison pour laquelle les différences semblent tellement saillantes. Il est évident que de petites différences peuvent être à l'origine de nombreuses difficultés en matière de développement, j'en veux pour preuve mon expérience personnelle et des discussions avec d'autres développeurs. Toutefois, le fait même que nous puissions parler de compatibilité à un niveau détaillé illustre la similitude entre les langages, les bibliothèques et le balisage.

Au cours de cet article, je me concentrerai sur deux scénarios importants : le partage du code avec une application compagnon et la vérification future du développement en cours.

Application compagnon Il s'agit d'un scénario de partage de code, ou d'intercompilation, simultané destiné aux développeurs d'applications WPF et Silverlight qui souhaitent développer en parallèle des applications compagnon du Windows Store pour Windows 8.

Vérification future Dans ce cas de figure, les développeurs créent de nouvelles applications WPF et Silverlight aujourd'hui, sans cibler Windows 8. Lorsque l'organisation adopte Windows 8, les développeurs veulent être prêts, ils veulent garantir que des parties appropriées de leurs applications pourront être transférées aisément vers la nouvelle interface utilisateur Windows.

Des dizaines d'années d'expérience en matière de programmation nous ont enseigné que la réutilisation et la portabilité ne sont jamais gratuites. Toutefois, avec les techniques présentées ici, vous découvrirez qu'un effort minime doit être fourni par rapport à ce qui vous feriez normalement pour créer des applications bien conçues.

De l'importance d'une architecture réfléchie

Il est possible de diviser des applications de grande taille en applications plus petites uniquement si votre architecture initiale a été bien pensée. En fait, si votre application comporte un grand nombre d'interdépendances entre les modules de code, beaucoup de hiérarchies de classes lourdes ou si, inversement, elle semble confuse et donne l'impression d'un code inepte, la réutilisation ou le transfert seront extrêmement difficiles. Mais ne désespérez pas ! Le code peut être refactorisé et un nouveau code peut être écrit en tenant compte de l'architecture.

Lors de la conception de nouvelles applications, j'encourage les développeurs XAML à adopter quelques approches clés : la liaison, le modèle MVVM (Model-View-ViewModel) et les classes de service.

Liaison Plus vous intégrez la liaison de données lors de vos développements en XAML, plus il vous est facile de séparer la logique de l'interface utilisateur. Idéalement, vous définissez le DataContext pour l'interface utilisateur et tout le reste est géré par la liaison avec les données ou les commandes. Dans la pratique, seules quelques applications sont capables d'atteindre ce niveau de séparation, mais plus vous vous en approcherez, plus votre vie en sera simplifiée.

Modèle MVVM Le modèle MVVM va de pair avec la liaison de données. C'est au ViewModel que l'interface utilisateur se liera. Les informations sur le sujet ne manquent pas sur Internet (où vous les trouverez gratuitement) et dans les livres, au même titre que les kits de ressources sur lesquels je reviendrai plus tard, c'est pourquoi je ne m'attarderai pas sur ce point ici.

Classes de service Ne confondez pas cette approche avec les services Web. Il s'agit en effet de classes qui fournissent des fonctionnalités réutilisables sur le client. Dans certains cas, elles peuvent appeler des services RESTful ou autres. Dans d'autres cas de figure, elles peuvent jouer le rôle d'interface avec votre logique métier. Dans toutes les situations, elles encapsulent un code potentiellement volatile et facilitent la permutation des implémentations. Par exemple, à la figure 1, le ViewModel parle aux classes de service afin d'utiliser les deux services de plateforme et de résoudre les dépendances externes.

Figure 1 Relation entre le ViewModel et les classes de service

Je sais. Vous êtes en train de vous dire : « Oh non ! Encore un diagramme sur les couches ». Mais vous connaissez l'importance de ces concepts. Le but est de vous détacher de la plateforme sur laquelle vous vous trouvez autant que possible si l'on tient compte de vos contraintes de budget et de temps. En factorisant un code qui effectue par exemple des appels COM ou p-invoke dans des éléments de bureau tels que Windows Imaging ou DirectShow, vous pouvez remplacer plus facilement cette implémentation par l'API de caméra WinRT dans votre application du Windows Store. Les classes de service sont également idéales pour encapsuler d'autres différences de plateforme, telles que les implémentations de contrat : l'envoi d'un courrier électronique depuis votre application du Windows Store utilise un contrat mais, sur le bureau, cela implique généralement une automatisation d'Outlook ou une connexion à un serveur SMTP.

Il est bien évidemment facile de se laisser emporter lors de la conception de l'architecture et de ne jamais arriver au bout. Une bonne architecture doit faciliter le développement, pas le compliquer. Si votre équipe rencontre des difficultés avec les détails d'un modèle d'architecture particulier, cela indique que vous perdez probablement votre temps. Pour résoudre ce problème, cherchez à comprendre la nature des modèles et leurs avantages, puis prenez des décisions intelligentes et réfléchies sur les compromis à mettre en œuvre. Dans la plupart des cas, il vaut toujours mieux implémenter 85 % plutôt que 0 % d'une architecture exceptionnelle. De la même manière, il est souvent inutile d'engager les coûts impliqués dans l'implémentation des 15 % restants.

Une fois que vous avez séparé le code qui dépend de la plateforme, vous pouvez réutiliser une grande partie du reste du code, plus complexe.

Adoption de l'esthétique de la nouvelle interface utilisateur Windows

Lorsque les développeurs commencent à envisager la création de versions Windows Store d'applications WPF (Windows Presentation Foundation) et Silverlight, ils se précipitent immédiatement dans l'impasse qui consiste à repenser l'expérience utilisateur et la conception visuelle. La plupart des développeurs hésitent à remodeler le style de toute une application. Si vous pensez que les applications du Windows Store font partie de votre avenir, le travail minime qui vous est demandé aujourd'hui pour adopter la nouvelle esthétique et les nouvelles directives de conception d'une interface utilisateur Windows sera vraiment payant par la suite.

La nouvelle conception de l'interface utilisateur Windows offre une infrastructure qui guidera vos choix en la matière. Plusieurs vidéos BUILD 2011 sont consacrées à la conception d'applications du Windows Store. Vous pouvez les visionner sur le site MSDN Channel 9, depuis la page bit.ly/oB56Vf. En outre, tenez compte des points suivants si vous souhaitez adopter la nouvelle esthétique de conception de l'interface utilisateur Windows dans vos applications de bureau :

• Soyez véritablement numérique. En règle générale, évitez de concevoir l'interface utilisateur comme une fausse analogie d'objets physiques (skeuomorphisme). Évitez non seulement de recréer des objets physiques, mais également des techniques dérivées telles que des boutons brillants, des ombrages 3D, des ombres réalistes et des arrière-plans transparents.
• Créez une hiérarchie de caractères lisible. N'utilisez pas des milliers de polices différentes et adoptez uniquement quelques tailles principales et facilement différenciables pour les polices que vous choisissez. Il doit être facile de différencier les titres des libellés de champ et du texte d'aide.
• Personnalisez l'application. Utilisez vos couleurs, logos, caractères, etc., à votre guise. N'hésitez pas à demander l'aide de vos développeurs et concepteurs Web à ce stade car ils peuvent apporter une expérience plus pratique de la personnalisation.
• Utilisez une métaphore de navigation basée sur les pages. Cela semblera naturel aux développeurs Silverlight (l'infrastructure de navigation est presque identique), mais les développeurs WPF devront peut-être fournir un peu plus de travail pour s'éloigner de l'approche de bureau multifenêtre et avec boîtes de dialogue traditionnelle.
• Concentrez-vous sur les tâches. L'interface utilisateur doit être focalisée sur les tâches ; ne tentez pas non plus d'utiliser un écran par fonction à la dernière minute. Malheureusement, les utilisateurs pensent souvent qu'il est judicieux d'intégrer chaque fonction sur une seule page, ce qui devient difficile à utiliser, à gérer et à apprendre avec le temps. Dans certains cas, il est conseillé de diviser des applications de grandes tailles en applications plus petites, concentrées sur les tâches.
• Évitez les ornements inutiles. Votre interface utilisateur doit rester simple. Il est important d'attirer le regard de l'utilisateur vers le travail sur lequel il doit se concentrer, et non vers les menus, éléments de navigation, bordures de fenêtre ou autre chrome.

Ces concepts sont similaires aux anciennes instructions de conception des interfaces utilisateur Windows. À ce titre, il est recommandé de les suivre si vous souhaitez que l'utilisateur se sente à l'aise avec votre application et que cette dernière s'intègre à la nouvelle interface utilisateur Windows. L'intérêt de ces conseils ne se limite pas à ce que je viens d'écrire, c'est pourquoi je vous recommande vivement de visionner les vidéos BUILD et d'étudier des exemples d'applications qui ont été conçues par d'autres développeurs et concepteurs.

Pour gagner du temps avec l'utilisation des styles de l'interface utilisateur, vous pouvez notamment copier les ressources de style des applications du Windows Store dans vos applications de bureau. Vous trouverez de nombreuses ressources de styles dans le dossier Windows Kits. Sur mon ordinateur, ce dossier se trouve sous C:\Program Files (x86)\Windows Kits\8.0\Include\winrt\xaml\design.

Certains styles et ressources peuvent être utilisés tels quels. Certains seront inutilisables en raison de contrôles plus récents (par exemple, ListView et GridView) et d'autres auront parfois besoin d'être modifiés de façon conséquente. Cela reste toutefois une excellente solution pour obtenir une application d'apparence moderne et promouvoir une transition aisée entre les styles des applications de bureau et ceux du Windows Store. Même lorsqu'un style ou un modèle ne peut pas être utilisé directement, il peut vous inspirer pour le style que vous souhaitez donner à votre application.

Vous devrez encore travailler sur votre interface utilisateur lorsque vous la transférerez dans le Windows Runtime, mais si vous adoptez ces concepts dans vos applications dès maintenant, vous mettrez toutes les chances de votre côté pour garantir une transition aisée entre la nouvelle interface utilisateur du Windows Store et les applications de bureau pour les utilisateurs ou les développeurs.

En ce qui me concerne, moins il y a de travail à fournir, mieux c'est. Créez le style de votre application une fois, facilitez la transition et obtenez une apparence moderne en prime.

Réutilisation du code et des composants

Windows Runtime est au cœur de l'attention dans les nouvelles applications du Windows Store. Il est nouveau, rapide et propose un grand nombre de fonctionnalités intéressantes. Cependant, nous oublions parfois qu'il n'est pas le seul élément que vous devez utiliser. En effet, les applications du Windows Store créées avec le XAML utilisent beaucoup le .NET Framework 4.5 avec le Windows Runtime. En fait, le .NET Framework 4.5 comporte des mises à jour importantes, un grand nombre d'entre elles permettant son utilisation en parallèle avec le Windows Runtime. Cela reste toutefois la technologie .NET, ce qui signifie que le partage du code source, voire des binaires compilés, avec des implémentations .NET ne présente pas de difficultés majeures.

Lorsque vous partagez du code avec des applications WPF, la meilleure solution à ce stade consiste à écrire votre code WPF de façon à ce qu'il soit compatible avec le .NET Framework 4.5. Les applications du Windows Store utilisent un sous-ensemble sûr de .NET 4.5 avec le Windows Runtime. Lorsque le .NET Framework offre les mêmes fonctionnalités que le Windows Runtime (XAML en est un excellent exemple), le profil .NET pour les applications du Windows Store utilise la version WinRT. Si vous restez aussi proche que possible de ce sous-ensemble, les possibilités de transfert de votre code seront très élevées. Cela vous sera particulièrement utile lorsque vous travaillerez avec des services et du code asynchrone.

Le partage avec Silverlight est légèrement plus limité en ce sens que Silverlight n'utilise pas le .NET Framework 4.5 ni, pour la plus grande partie, la bibliothèque parallèle de tâches (TPL). Toutefois, grâce au pack de ciblage asynchrone pour Silverlight 5, les utilisateurs de Visual Studio 2012 qui écrivent des applications Silverlight ont accès à une partie de la fonctionnalité Task<T> et async/await. Notez toutefois que le code Ajouter une référence de service ne générera pas de code côté client asynchrone. Si vous en avez besoin, vous pouvez transférer le code proxy généré dans Silverlight. Une meilleure approche consiste à encapsuler les interactions du service Web dans les classes de service locales, et ce à l'aide de l'architecture que je propose ici.

Comment procéder lorsque le code est identique ? C'est notamment le cas des classes Model, et souvent des classes ViewModel. Dans le cas présent, vous avez deux possibilités : les projets de la bibliothèque de classes portables (PCL) et les projets liés.

Projets PCL La bibliothèque PCL est une excellente façon de partager les DLL compilées entre différentes cibles .NET. Elle vous permet de partager des assemblys entre .NET, .NET pour les applications du Windows Store, Silverlight, Windows Phone, etc. Pour utiliser la bibliothèque PCL, vous devez limiter les références de l'assembly à celles de la liste de compatibilité. Pour en savoir plus sur cette bibliothèque, consultez bit.ly/z2r3eM.

Projets liés avec code source partagé et compilation conditionnelle Une fonctionnalité Visual Studio vous permet d'avoir plusieurs projets, chacun d'entre eux ciblant différentes plateformes, mais avec une seule copie partagée de code source. Dans le passé, j'ai eu recours à cette approche essentiellement lorsque je devais partager du code entre ASP.NET sur le serveur et Silverlight sur le client. Vous trouverez des exemples sur mon blog, sur la page bit.ly/RtLhe7. 

Bien que j'utilise traditionnellement des projets liés pour la plupart de mes scénarios de réutilisation, la bibliothèque PCL s'est véritablement étendue dans les versions récentes. Si vous ciblez WPF et le XAML WinRT, la bibliothèque PCL vous permettra d'utiliser presque tout ce qui se trouve dans le profil .NET 4.5 pour les applications du Windows Store. En cas de doute, commencez par la bibliothèque PCL.

Dans l'approche de projet lié, j'apprécie de pouvoir fournir des fonctionnalités supplémentaires propres à la plateforme via des classes partielles et la compilation conditionnelle. Les symboles de la compilation conditionnelle sont définis dans l'onglet Build de la page de propriétés du projet, comme illustré à la figure 2.

Figure 2 Page des propriétés du projet affichant les symboles de compilation

Par défaut, un certain nombre de symboles de compilation conditionnelle sont définis pour vous, comme illustré à la figure 3.

Figure 3 Symboles de compilation conditionnelle

Notez que le .NET Framework complet ne définit aucun symbole de compilation, il est considéré comme la plateforme par défaut. Si cela ne vous convient pas, vous pouvez ajouter vos propres symboles de compilation. Le cas échéant, veillez simplement à effectuer cet ajout pour tous les projets .NET Framework de votre solution.

La compilation conditionnelle correspond également à la façon dont vous pouvez extraire différents espaces de noms du code, selon la plateforme cible :

#if NETFX_CORE
using Windows.UI.Xaml;
#else
using System.Windows.Xaml;
#endif

Dans toute application complexe, vous serez amené à utiliser des projets PCL et liés pour partager le code. Le partage du XAML est cependant plus compliqué.

Partage des interfaces utilisateur et des ressources XAML

Pour diverses raisons, il est plus difficile de partager du XAML que du code. Pour effectuer cette opération, l'étape la plus importante consiste à personnaliser l'interface utilisateur pour le facteur de forme et la plateforme que vous ciblez. Lisez l'article consacré à l'adoption de la nouvelle esthétique de conception des interfaces utilisateur Windows pour avoir quelques indications en la matière. Dans la plupart des cas, il est préférable de vous assurer que le code est réutilisable plutôt que de consacrer votre temps de développement à autre chose, les résultats seront bien meilleurs pour des efforts moindres. Toutefois, il y aura à la fois un désir et une tendance à partager le XAML entre les projets.

Le XAML ne comporte pas le concept de compilation conditionnelle. Les différences d'espaces de noms sont donc plus difficiles à gérer que dans le code. Outre les espaces de noms eux-mêmes, la façon dont vous les importez dans le XAML a changé entre le XAML WinRT et les autres versions.

Prenons l'exemple du XAML .NET Framework suivant :

xmlns:localControls="clr-namespace:WpfApp.Controls"

Et de ce XAML WinRT :

xmlns:localControls="using:WindowsApp.Controls"

Au lieu de l'instruction « clr-namespace », XAML WinRT utilise l'instruction « using » lors de l'importation des espaces de noms. Pourquoi les équipes produit ont-elles fait ce choix ? Les espaces de noms importés dans le XAML peuvent provenir d'un code autre que CLR, en C++ par exemple. Aujourd'hui, vous pouvez non seulement bénéficier du support XAML en C++, mais également écrire des assemblys d'extension en C++ et les utiliser dans votre code .NET. Cela signifie que le terme « clr-namespace » n'est plus exact.

Pour traiter ces différences, vous pouvez notamment charger le XAML dynamiquement. À l'époque glorieuse de Silverlight 1.1, les contrôles utilisateurs étaient générés de la façon suivante : le XAML était chargé dynamiquement et traité lors de l'exécution. Cette approche est utilisée depuis cette époque par les développeurs d'applications afin de garantir la flexibilité entre toutes les plateformes.

Lorsque vous chargez dynamiquement du XAML, vous utilisez des chaînes. Cela signifie que vous pouvez remplacer ou réduire le texte à votre guise avant de le charger dans l'arborescence visuelle. Par exemple, supposons que vous ayez une définition du contrôle utilisateur vide dans votre projet WPF ou Silverlight. Le contrôle utilisateur est un simple shell qui définit les espaces de noms et la classe. Vous avez ensuite un shell équivalent dans le projet XAML WinRT.

Voici le XAML .NET :

<UserControl x:Class="WpfApp.Controls.AddressControl"
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml">
  <Grid x:Name="LayoutRoot">
  </Grid>
</UserControl>

Et voici le XAML WinRT :

<UserControl x:Class="WindowsApp.AddressControl"
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml">
  <Grid x:Name="LayoutRoot">
  </Grid>
</UserControl>

Les deux contrôles utilisateur XAML sont une sortie de modèle toute simple comme vous en avez l'habitude. J'ai apporté une seule modification en donnant un nom à l'élément Grid racine et en supprimant certains espaces de noms inutilisés pour avoir un code court. Le code-behind des contrôles peut être partagé à l'aide des techniques de partage de code, bien que je recommande la partition du code en classe partagée distincte dès que possible.

Ensuite, pour charger le XAML lors de l'exécution, vous pouvez utiliser un code similaire à celui de la figure 4.

Figure 4 Code pour charger le XAML dynamiquement

public partial class AddressControl : UserControl
{
  public AddressControl()
  {
    InitializeComponent();
    LoadXaml();
  }
  private void LoadXaml()
  {
    string xaml =
    "<Grid xmlns=\"https://schemas.microsoft.com/winfx/2006/xaml/presentation\" " +
      "xmlns:x=\"https://schemas.microsoft.com/winfx/2006/xaml\">" +
      "<Grid.RowDefinitions>" +
        "<RowDefinition Height=\"Auto\" />" +
        "<RowDefinition Height=\"30\" />" +
      "</Grid.RowDefinitions>" +
      "<TextBlock Text=\"Address\" Grid.Row=\"0\" FontSize=\"10\" />" +
      "<TextBox x:Name=\"t1\" Grid.Row=\"1\" FontSize=\"15\" />" +
    "</Grid>";
    var reader = new StringReader(xaml);
    var xmlReader = XmlReader.Create(reader);           
    LayoutRoot.Children.Add((UIElement)XamlReader.Load(xmlReader));
  }
}

Le code à charger dans le XAML WinRT est même plus simple en raison du support de chargement de chaîne direct :

string xaml = "..."
LayoutRoot.Children.Add((UIElement)XamlReader.Load(xaml));

Afin de simplifier les choses, j'ai chargé le XAML depuis une chaîne codée en dur ici et j'ai utilisé le XAML qui est déjà transférable et ne requiert aucune manipulation de chaîne. Pour le premier, si vous souhaitez le support d'un concepteur, rédigez le code de façon à ce qu'il charge du texte à partir d'un fichier de ressources XAML. Incluez ensuite toutes les définitions habituelles de classe et de xlmns pour prendre en charge le concepteur, mais évincez-les lors de l'étape de chargement du XAML.

Quelle que soit la façon dont le XAML est intégré à l'arborescence visuelle, si vous souhaitez connecter les événements dans le XAML chargé dynamiquement, vous pouvez également le faire dans le code :

LayoutRoot.Children.Add((UIElement)XamlReader.Load(xaml));
var t1 = FindName("t1") as TextBox;
if (t1 != null)
{
  t1.TextChanged += t1_TextChanged;
}

Au même titre que vous pouvez charger l'interface utilisateur XAML, vous pouvez charger des ressources lors de l'exécution. Vous pouvez les créer totalement ou bien, à l'aide des approches illustrées ici, les charger depuis le code source XAML :

private void LoadResources()
{
  string xaml =
    "<Style xmlns=\"https://schemas.microsoft.com/winfx/2006/xaml/presentation\" " +
      "TargetType=\"TextBox\">" +
      "<Setter Property=\"Margin\" Value=\"5\" />" +
    "</Style>";
  // Implicit styles use type for key
  var key = typeof(TextBox);
  App.Current.Resources.Add(key, XamlReader.Load(xaml));
}

Veillez à effectuer le chargement dynamique des ressources avant que celles-ci ne soient référencées. Dans le cas de styles implicites, ils ne s'appliqueront pas à tout ce qui se trouve déjà dans l'arborescence visuelle lors de la création de la ressource.

Pour être clair, toute cette approche n'est pas très orthodoxe et elle ne fonctionnera pas sans heurts dans tous les scénarios. Il peut arriver que la manipulation de chaînes finisse par entraîner plus de travail que d'avantages. Toutefois, si vous souhaitez une réutilisation maximale entre les plateformes, il s'agit de la seule méthode disponible pour y parvenir. Personnellement, je ne l'utiliserais que pour les composants d'interface utilisateur critiques qui sont amenés à être beaucoup modifiés ou qui sont trop complexes ou trop nombreux pour être simplement copiés-collés régulièrement.

Il est évident que vous pouvez également créer une action de build personnalisée ou une autre extension Visual Studio pour gérer automatiquement le traitement lorsque les fichiers sont enregistrés, extraits, créés, ou bien pour toute autre étape.

La dernière solution consiste à éviter totalement le XAML et à créer à la place toute votre interface utilisateur à partir du code. Je mets généralement en garde contre cette approche pour la plupart des applications car elle implique beaucoup de travail supplémentaire et vous ne bénéficiez d'aucune aide de concepteur. Cependant, cette approche convient parfaitement aux interfaces utilisateur pilotées par les données. Si vous pouvez créer une interface en XAML, vous pouvez la créer dans le code, comme dans le cas du XAML WinRT illustré à la figure 5.

Figure 5 Création d'une interface utilisateur avec le XAML WinRT

private void CreateControls()
{
  Grid g = new Grid();
  RowDefinition r1 = new RowDefinition();
  RowDefinition r2 = new RowDefinition();
  r1.Height = new GridLength(1, GridUnitType.Auto);
  r2.Height = new GridLength(30.0);
  g.RowDefinitions.Add(r1);
  g.RowDefinitions.Add(r2);
  TextBlock t = new TextBlock();
  t.Text = "Address";
  Grid.SetRow(t, 0);
  TextBox tb1 = new TextBox();
  Grid.SetRow(tb1, 1);
  g.Children.Add(t);
  g.Children.Add(tb1);
  LayoutRoot.Children.Add(g);
}

Ce code, à l'exception des paramètres de police (pour être bref), équivaut au XAML chargé dynamiquement qui ajoute un TextBlock et un TextBox à la grille LayoutRoot, contenu dans une grille.

Les kits de ressources Open Source

La plupart des meilleurs kits de ressources XAML/C# sont Open Source. Dans un projet Open Source actif, vous verrez probablement des personnes intéressées prendre et ajouter les types de fonctionnalités qui permettent une portabilité entre Silverlight, WPF et Windows Runtime.

Il existe par exemple un certain nombre de kits de ressources MVVM qui sont globalement transférables entre les diverses variantes de XAML. Ils vous permettent de réduire le nombre de modifications à apporter à votre code source lorsque vous le partagez ou que vous le transférez. De le même manière, vous trouverez des contrôles, des bases de données locales et d'autres kits de ressources disponibles pour une utilisation multiplateforme.

Il existe toujours un risque que les développeurs Open Source ne ciblent pas les nouvelles versions des plateformes, mais en accédant au code source, vous pouvez le détourner et le modifier à votre guise. N'oubliez pas de communiquer le code que vous aurez créé une fois que vous aurez terminé.

Comment déterminer ce qui peut devenir une application d'interface utilisateur Windows Store

Lors de la création de votre application du Windows Store, gardez à l'esprit que certains aspects de certaines applications de bureau ne peuvent pas être transposés directement dans les applications du Windows Store. Par exemple, une grande application qui comporte 300 écrans et effectue toute une série de fonctions diverses pour différents utilisateurs n'est pas nécessairement adaptée à la nouvelle interface utilisateur Windows. En effet, les applications du Windows Store doivent se concentrer sur les tâches et être conçues pour une utilisation spécifique.

Prenons l'exemple d'une application d'assurance. Vous pouvez avoir une application qui est partagée par un grand nombre d'utilisateurs au sein de la compagnie. Elle est responsable des fonctions de supervision permettant de gérer la sécurité des utilisateurs. Elle permet de recevoir les réclamations en cas de sinistres relatifs à des bris de glace, par téléphone ou bien à l'aide d'un ordinateur portable sur le terrain. Elle comporte une fonctionnalité intégrée de création de nouvelles polices, etc.

Si vous divisez l'application en un certain nombre d'applications plus petites concentrées sur les tâches (ou sur l'utilisateur), elle conviendra mieux à la nouvelle interface utilisateur Windows. Par exemple, il peut être préférable d'avoir une application distincte consacrée aux sinistres et qui se concentre sur le relevé des informations liées à l'accident sur place. Étant donné qu'elle est spécifique à un point particulier, elle comprend le support de la prise de photographies et de l'enregistrement de vidéos, ainsi que la mise en cache locale des données pour les zones déconnectées ou avec un signal faible. Cette application partage probablement beaucoup de code avec d'autres applications au sein de l'entreprise, mais grâce à sa focalisation, elle est mieux adaptée aux scénarios pour lesquels elle a été construite.

Pour résumer

XAML WinRT, Silverlight et WPF ont été créées en pensant à divers objectifs, mais elles sont plus similaires que différentes. Il est facile de partager du code entre eux et le partage du XAML est possible. Vous pouvez avoir recours à de nombreuses techniques supplémentaires pour cibler les trois plateformes et passer du bureau à la nouvelle interface utilisateur du Windows Store. J'adorerais poursuivre cette conversation sur Twitter et sur mon blog, à l'adresse 10rem.net. Si vous avez utilisé d'autres techniques pour transférer le code vers le Windows Runtime ou le rendre multicible, n'hésitez pas à me faire part de vos commentaires.

Pete Brown est l'expert en XAML Windows 8 et en gadgets chez Microsoft. Il est également auteur de « Silverlight 5 in Action » (Manning Publications, 2012) et de « Windows 8 XAML in Action » (Manning Publications, 2012). Son blog et son site Web se trouvent sur 10rem.net, et vous pouvez le suivre sur Twitter, à l'adresse twitter.com/pete_brown.

Merci à l'expert technique suivant d'avoir relu cet article : Tim Heuer