INTRODUCTION AUX APPS UNIVERSELLES WINDOWS

INTRODUCTION AUX APPS UNIVERSELLES WINDOWS «UNIVERSAL WINDOWS APPS» POUR WINDOWS 8.1, WINDOWS PHONE 8.1 (ET XBOX ONE) La conférence Build de Microsoft est un évènement incontournable des développeurs depuis déjà quelques années. Microsoft profite toujours de cette conférence pour faire diverses annonces sur les nouveautés à venir et l édition 2014 n a pas dérogée à la règle. Parmi les annonces les plus marquantes de cette année, on notera qu une nouvelle version de Windows Phone, la version 8.1 est en cours de finalisation. Elle sera disponible sur tous les nouveaux smartphones commercialisé à partir de la fin Avril et arrivera sur les terminaux existants dans les mois à venir. Les Apps pour Windows Phone 8.1 pourront dorénavant être développées en ciblant la plateforme WinRT plutôt que d utiliser Silverlight. Avec l annonce de Windows Phone 8.1, un nouveau modèle de développement d Apps a également été annoncé : les Universal Windows Apps (UWA) permettant de développer une seule application ciblant différentes plateformes : Windows 8.1, Windows Phone 8.1 et Xbox One (dans un futur proche). GENERALITES MODELE DE PROGRAMMATION WINDOWS RT Ce nouveau modèle de développement UWA est disponible avec la deuxième mise à jour de Visual Studio 2013 et se base sur la plateforme WinRT. Figure 1 : Modèle de programmation Windows RT Avec cette uniformisation des plateformes Windows, les Apps pour Windows Phone 8.1 sont donc désormais développables en JavaScript / HTML, C# / XAML ou C++ / XAML! TEMPLATES DE PROJETS VISUAL STUDIO 2013 UPDATE 2 Lors de la création d un nouveau projet dans Visual Studio, la section «Store Apps», qui hébergeait précédemment les templates de projet Windows Apps, s est transformée pour contenir maintenant 3 sections de templates : Universal Apps : contient les différents types de projets permettant de créer des UWA Windows Apps : avec les templates pour des Apps Windows 8.1 Windows Phone Apps : comprend 2 groupes de templates de projet pour réaliser des Apps pour Windows Phone 8.1 : o Les projets ciblant la nouvelle plateforme de développement WinRT o Les projets ciblant l ancienne plateforme de développement Silverlight Figure 2 : Section «Store Apps» de Visual Studio 2013 Update 2 1

La section «Universal Apps» contient 4 templates de projet : Blank App : permet de créer un projet contenant une page vide Hub App : génère un projet contenant 3 pages et utilisant le contrôle Hub. Des données de tests sont également générées avec ce template. Class Library : crée une librairie Portable Windows Runtime Component : pour réaliser un projet de composants pour la plateforme WinRT. Figure 3 : Section «Universal Apps» de Visual Studio 2013 Update 2 CREATION D UN NOUVEAU PROJET UWA Lorsque vous créez un nouveau projet UWA, Visual Studio génère 3 projets dans un dossier de solution : Un projet correspondant à l application Windows Un projet pour l application Windows Phone Et enfin, un projet «Shared» ou partagé qui contiendra tous les fichiers communs aux projets Windows et Windows Phone. Figure 4 : Structure d'un projet UWA Avant d aller plus loin, certains points importants sont à noter dès maintenant. Tout d abord, les projets Windows et Windows Phone utilise le même espace de nom : Figure 5 : Fenêtres de propriétés, onglet Application, des projets Windows et Windows Phone 2

Un détail me direz-vous ; cependant, cela va avoir son importance lorsque nous travaillerons sur des vues dans le projet «Shared». Nous verrons cela un peu plus tard. Deuxième élément d importance, des directives de compilations spécifiques à chaque plateforme (WINDOWS_APP et WINDOWS_PHONE_APP) ont été créées afin de faciliter le partage de code entre les plateformes tout en permettant du code spécifique à chaque plateforme : Figure 6 : Fenêtres de propriétés, onglet Build, des projets Windows et Windows Phone Les projets Windows et Windows Phone sont des projets d Apps classiques, mis à part qu ils ont une référence vers le projet Shared pour importer son contenu à la compilation. En revanche, le projet Shared est un nouveau type de projet (extension.shproj) : il ne se compile pas seul et ne produit aucun binaire : tous les fichiers qu il contient seront injectés dans chaque App à la compilation de ces projets. Il s agit plus d un conteneur de fichiers que d un projet à proprement parlé. Enfin, comme les Apps Windows et Windows Phone sont maintenant basées sur la plateforme RT, un espace de nom commun, regroupant, entre autre, tous les contrôles est disponible : Windows.UI.Xaml.*. DEVELOPPEMENT D UNE UWA Rentrons maintenant dans le vif du sujet : le développement d une UWA. STRUCTURE D UN PROJET : POINTS REMARQUABLES Lorsque vous créez un nouveau projet (Blank App), vous avez alors la structure de projets présentés en figure 4. Que peut-on constater dans cette architecture? 1. Le fichier d Application, App.xaml (et son code-behind) est dans le projet Shared : en effet le démarrage des 2 Apps se fait de manière très similaire et utilise les mêmes objets. Une petite nuance est apportée avec la gestion des transitions entre pages durant la navigation. Windows Phone gère les transitions entre pages légèrement différemment et nécessite du code qui lui est propre. Ce code est alors écrit en utilisant la bonne directive de compilation pour que les morceaux de code spécifique à la plateforme ne soient compilés que dans l application ciblant cette plateforme : #if WINDOWS_PHONE_APP // Code spécifique Windows Phone #endif 2. La première page de chaque application est dupliquée dans chaque projet d App. On pourrait se demander la raison derrière ce choix d autant que les 2 fichiers sont quasiment identiques. Peut-être que Microsoft a voulu démontrer que le type «MainPage», étant disponible dans les 2 projets d App, était alors connu du projet Shared sans restriction particulière. Si l on supprimait la page de démarrage d un des projets d App, le projet Shared ne reconnaitrait alors plus le type «MainPage» sans que le développeur ne le place dans un block utilisant la bonne directive de compilation. 3. Chaque projet d App contient son manifeste et ses icônes pour les différentes tailles de tuile. Ceci est normal, chaque projet cible un type d appareil différent : PC/Tablette ou Smartphone, et n a donc pas les mêmes caractéristiques. RENDRE UNE VUE COMMUNE Comment transformer la page de démarrage pour qu elle soit commune aux 2 projets d App? Rien de plus simple : 3

1. Copier un des 2 fichiers MainPage.xaml dans le projet Shared 2. Supprimer les fichiers MainPage.xaml des 2 projets d App 3. Compiler et le tour est joué! Avant : Après : Figure 7 : Rendre une vue présente dans les 2 projets d App commune Ceci m amène à vous parler de petites nouveautés que la mise à jour 2 de Visual Studio apporte au designer Xaml. NOUVEAUTES DESIGNER XAML Lorsqu un fichier Xaml est ouvert, de petites listes déroulants font leur apparition, juste au-dessus du code Xaml : Figure 8 : Nouveautés du designer Xaml Visual Studio 2013 Update 2 4

La première de ces listes déroulantes permet de changer le contexte de prévisualisation de la vue : c est-à-dire la plateforme que vous voulez utiliser pour voir le rendu de la vue : Windows ou Windows Phone. Cette liste de contextes n est disponible que dans le projet Shared. En effet, une vue présente dans un des projets d App n a qu un seul contexte : la plateforme ciblée par le projet. La deuxième liste déroulante contient l arbre Xaml de la vue, un peu plus succinct que la fenêtre «Document Outline», elle permet de naviguer rapidement dans son code Xaml en cliquant sur le contrôle qui nous intéresse. Enfin la troisième liste déroulante présente les propriétés qui ont été déclaré sur le contrôle sélectionné dans l arbre Xaml de la vue. Cliquer sur une de ces propriétés positionnera le développeur sur la propriété en question dans le code Xaml. Figure 9 : Affichage d'une vue dans le contexte «Windows Phone» GERER LES DIFFERENCES D API ENTRE PLATEFORMES Une autre nouveauté apportée par les UWA est un besoin de gérer les différences entre les plateformes Windows et Windows Phone. En effet, une base WinRT commune ne signifie pas que le développement d un App Windows est identique à celui d une App Windows Phone. Cela signifie seulement qu une large portion des API disponibles est compatible entre les 2 plateformes. WinRT Windows 8.1 Windows Phone 8.1 APIs communes APIs Windows uniquement Exemples : - Contrat de recherche - Charme Paramètres - etc. Exemples : - Boutons physique «retour» - Action Center - etc. APIs Windows Phone uniquement Figure 10 : Répartition des APIs dans le monde des UWA Certaines APIs seront les mêmes entre les 2 plateformes et se comporteront de manière identique, ici pas de problème. Certaines APIs peuvent faire partie du socle commun, mais elles auront un comportement différent selon l application. Prenons par exemple les notifications Toast, les 2 plateformes ont des tailles de tuiles représentant l application différentes. De ce fait, l affichage des notifications va devoir varier entre les deux plateformes. Certaines APIs sont spécifiques à Windows ou Windows Phone. Prenons un exemple : supposons que vous voulez gérer un écran de paramètres dans vos Apps. 5

La plateforme Windows possède un Charme «Paramètre» qui contiendra les écrans de paramètres de l application. La plateforme Windows Phone ne possède pas ce Charme et une vue «Paramètres» doit donc être créée comme n importe quel autre écran. Le Charme «Paramètre» se manipule en utilisant la classe SettingsPane mais comme Windows Phone ne possède pas cette fonctionnalité et donc la classe SettingsPane, Visual Studio va vous informer de la compatibilité des objets que vous manipulez via l IntelliSense. Figure 11 : Différences entre plateformes avec IntelliSense C est là que les directives de compilation prennent tout leur sens : #if WINDOWS_APP Windows.UI.ApplicationSettings.SettingsPane.Show(); #else this.frame.navigate(typeof(mysettingsflyout)); #endif L exemple de code ci-dessus pourrait être exécuté lorsque l utilisateur clique sur un bouton permettant d accéder à l écran de paramètres de l application. Lors de la compilation, l application Windows ouvrira le Charme «Paramètres» alors que l application Windows Phone naviguera vers un écran de paramètres créé par le développeur. Les boutons «physique» d un Windows Phone et leur gestion sont un autre exemple de fonctionnalités spécifiques à une des 2 plateformes. Ajouter la gestion du bouton de retour d un Windows Phone nécessitera également un bout de code spécifique : Figure 12 : Gestion du bouton physique «Back» d'un Windows Phone GERER LES DIFFERENCES UI ENTRE PLATEFORMES Comme mentionné dans le chapitre 1.3 les Apps Windows et Windows Phone d une UWA sont basées sur la plateforme RT et un espace de nom, regroupant les éléments d interface communs aux deux plateformes, est disponible : Windows.UI.Xaml.*. Ainsi le développement Windows Phone évolue avec, en particulier, de nouveaux contrôles remplaçant leurs homologues Silverlight (par exemple, le contrôle Hub remplace le contrôle Panorama, le SemanticZoom remplace le contrôle LongListSelector, etc.). Comme pour les APIs, une base WinRT commune ne signifie pas que tous les contrôles sont communs. Il faut même aller plus loin dans ce résonnement et séparer la logique d un contrôle de son rendu visuel. Ainsi certains contrôles communs auront le même comportement, mais un rendu visuel totalement différent. Nous avons donc 3 catégories de contrôles : Communs, rendu identique 6

Communs, rendu différent Spécifiques à chaque plateforme WinRT Windows 8.1 Windows Phone 8.1 Contrôles communs Rendu identique Exemples: - Button, ToggleSwitch - ProgressBar - etc. Rendu Différent Exemples: - DatePicker, TimePicker - AppBar - etc. Contrôles Windows uniquement Exemples : - SearchBox - SettingFlyout - etc. Exemples : - AutoSuggestBox - Pivot -...etc. Contrôles Windows Phone uniquement Figure 13 : Répartition des contrôles dans le monde des UWA Certaines personnes vont même jusqu à considérer une 4 ème catégorie : les contrôles communs aux 2 plateformes, mais qui auront la plupart du temps un contenu différent selon la plateforme. En effet, une App sur tablette et une App sur smartphone a rarement la même utilité ou le même besoin en contenu. Il suffit de regarder les Apps de Météo des 2 plateformes pour se rendre compte de cette différence : Figure 14 : Différences de contenu entre une App Windows et une App Windows Phone 7

Comment gérer ces différences UI concrètement? Pour ce qui est des contrôles communs, pas de problème particulier : ils peuvent s utiliser sans restriction dans les projets d application ou dans le projet Shared. Les différences entre plateformes peuvent alors être gérées dans des dictionnaires de ressources. Vous allez d ailleurs rapidement être confronté à des problèmes de styles ou plus particulièrement des problèmes de règles de design imposées par Microsoft pour le développement d Apps «ModernUI». Les choses se compliquent également lors de l utilisation des contrôles spécifiques ou gérer des différences en terme de contenu dans une page partagées entre les 2 plateformes. Le langage XAML ne supportant pas les directives de compilation comme C#, une alternative doit donc être trouvée. Prenons un exemple simple, la zone de titre d une page. Sur tablette, Microsoft demande à ce que l application ait une marge de 120px à gauche et que la zone contenant le titre de la page mesure 140px de haut. Cette zone peut éventuellement contenir un bouton de retour à la page précédente et une zone de recherche. <Grid> <Grid.RowDefinitions> <RowDefinition Height="140" /> <RowDefinition Height="*" /> </Grid.RowDefinitions> <Grid.ColumnDefinitions> <ColumnDefinition Width="120" /> <ColumnDefinition Width="*" /> <ColumnDefinition Width="Auto" /> </Grid.ColumnDefinitions> <Button x:name="backbutton" Margin="39,59,39,0" Command="{Binding NavigationHelper.GoBackCommand, ElementName=pageRoot}" Style="{StaticResource NavigationBackButtonNormalStyle}" VerticalAlignment="Top" AutomationProperties.Name="Back" AutomationProperties.AutomationId="BackButton" Grid.Row="0" AutomationProperties.ItemType="Navigation Button" /> <TextBlock x:name="pagetitle" Text="Demo Page" Margin="0,0,30,40" Grid.Column="1" Style="{StaticResource HeaderTextBlockStyle}" TextWrapping="NoWrap" IsHitTestVisible="false" VerticalAlignment="Bottom" Grid.Row="0" /> <SearchBox Grid.Column="2" Height="35" Width="270" Margin="0,25,25,0" Grid.Row="0" /> Maintenant sur smartphone, toutes les pages doivent respecter une marge gauche de 12 ou 24px, tout contenu doit être aligné à gauche. Il ne doit pas y avoir de bouton de retour à la page précédente, le téléphone ayant déjà un bouton physique à cet effet. Enfin, le contrôle utilisé pour la zone de recherche n existe pas sur Windows Phone, mais un contrôle appelé AutoSuggestBox pourrait servir d équivalent si besoin. On voit tout de suite que le bout de code XAML, représentant la zone de titre d une App pour tablette ci-dessus, n est pas du tout adapté aux règles de design pour smartphone. Le code ci-dessous serait plus adapté : <StackPanel Orientation="Vertical" Margin="12 0 0 0" > <TextBlock x:name="pagetitle" Text="Demo App" VerticalAlignment="Bottom" TextWrapping="NoWrap" Style="{StaticResource HeaderTextBlockStyle}" IsHitTestVisible="false"/> <Grid> <!-- SearchBox --> <Grid.ColumnDefinitions> <ColumnDefinition Width="*" /> <ColumnDefinition Width="Auto" /> </Grid.ColumnDefinitions> <AutoSuggestBox x:name="searchtext" /> <Button Style="{StaticResource IconButtonStyle}" Grid.Column="1" Content=" " x:name="searchbutton" /> </StackPanel> 8

Nous avons ici plusieurs techniques pour résoudre le problème tout en essayant de mutualiser un maximum de code Xaml. 1. La page est propre à chaque plateforme (créée dans les projets d Application) et contient les éléments spécifiques à chaque environnement mais utilise des contrôles partagés dès que possible. 2. La page est partagée entre les 2 plateformes, mais elle est découpée en zones qui sont remplies par des contrôles (User Control) adaptés à la plateforme utilisée lorsque cela est nécessaire. Suite aux différents tests que j ai pu faire avec les UWA pour la préparation de cet article, je peux difficilement trancher entre les 2 techniques, cela dépend des cas, des projets. Une page de type Hub? il y a de fortes chances que vous optiez pour la technique 2 : la page est partagée et chaque section sera un user control (soit spécifique soit également partagé). Une page contenant une GridView? vous voulez probablement partager la GridView entre les 2 plateformes : le contrôle va automatiquement s adapter selon la plateforme et aura donc un rendu satisfaisant sur tablette et sur smartphone. Quant à la page, si elle a une zone de titre comme celle que j ai présenté ci-dessus (bouton retour + zone de recherche), je pense que j opterais soit pour une page partagée mais une zone de titre spécifique à chaque plateforme, soit pour une page dédiée. Deux éléments importants et somme toute très simples sont à comprendre ici : 1. Tout ce qui est placé dans le projet Shared est connu des 2 projets d application. De ce fait, je peux créer un contrôle dans mon projet Shared et l utiliser comme bon me semble dans une vue côté App : Projet Windows Phone Projet Shared Page Spécifique User Control Partagé Projet Windows Page Spécifique Figure 15 : Page spécifique, contrôle partagé 9

Côté Windows Phone : <Grid Margin="12 0 0 0" Background="{ThemeResource ApplicationPageBackgroundThemeBrush}"> <Grid.RowDefinitions> <RowDefinition Height="Auto" /> <RowDefinition Height="*" /> </Grid.RowDefinitions> <StackPanel Orientation="Vertical"> <TextBlock x:name="pagetitle" Text="Demo App" Style="{StaticResource GroupHeaderTextBlockStyle}" IsHitTestVisible="false" TextWrapping="NoWrap" VerticalAlignment="Bottom" /> <Grid> <!-- SearchBox --> <Grid.ColumnDefinitions> <ColumnDefinition Width="*" /> <ColumnDefinition Width="Auto" /> </Grid.ColumnDefinitions> <AutoSuggestBox x:name="searchtext" /> <Button Style="{StaticResource IconButtonStyle}" Grid.Column="1" Content=" " x:name="searchbutton"/> </StackPanel> <local:helloworldcontrol Grid.Row="1" Margin="0 0 12 0"/> Côté Windows : <Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}"> <Grid.RowDefinitions> <RowDefinition Height="140" /> <RowDefinition Height="*" /> </Grid.RowDefinitions> <Grid> <Grid.ColumnDefinitions> <ColumnDefinition Width="120" /> <ColumnDefinition Width="*" /> <ColumnDefinition Width="Auto" /> </Grid.ColumnDefinitions> <Button x:name="backbutton" Margin="39 59 39 0" Command="{Binding NavigationHelper.GoBackCommand, ElementName=pageRoot}" Style="{StaticResource NavigationBackButtonNormalStyle}" VerticalAlignment="Top" AutomationProperties.Name="Back" AutomationProperties.AutomationId="BackButton" AutomationProperties.ItemType="Navigation Button" /> <TextBlock x:name="pagetitle" Text="Demo App" Style="{StaticResource HeaderTextBlockStyle}" Margin="0 0 30 40" IsHitTestVisible="false" TextWrapping="NoWrap" VerticalAlignment="Bottom" Grid.Column="1" /> <SearchBox Grid.Column="2" Height="35" Width="270" Margin="0,25,25,0" /> <local:helloworldcontrol Grid.Row="1" /> 2. Dans le chapitre 1.3, j ai mentionné que les 2 projets d application partageaient le même espace de nom. Cela va permettre de faire l exact inverse : créer des contrôles dans les projets d applications et les utiliser dans une vue partagée. Dans chaque contrôle représentant nos zones de titre, on retrouve les deux morceaux de code spécifique à chaque plateforme (avec les bonnes marges, la SearchBox côté Windows et l AutoSuggestBox côté Windows Phone, etc.) 10

Projet Shared User Control Partagé Page Partagée Projet Windows Phone Projet Windows Zone de titre Spécifique Zone de titre Spécifique Figure 16 : Page partagée, contrôles spécifiques Dans le projet Shared, on trouve notre page avec un code grandement simplifié et utilisant un contrôle partagé et un contrôle spécifique qui sera appliqué pour chaque plateforme : <Page x:class="demo.mainpage" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:local="using:demo" xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" mc:ignorable="d" Background="{ThemeResource ApplicationPageBackgroundThemeBrush}"> <Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}"> <Grid.RowDefinitions> <RowDefinition Height="Auto"/> <RowDefinition Height="*"/> </Grid.RowDefinitions> <local:headercontrol Grid.Row="0"/> <local:helloworldcontrol Grid.Row="1" /> </Page> On notera également ici que le contrôle de titre et le contrôle «Hello World» sont dans le même espace de nom bien qu ils soient dans les projets différents. Ceci est simplement dû au fait que le projet Shared n est qu un conteneur et que chaque App, à la compilation, va injecter le contenu de ce projet partagé dans son projet d App et donc l espace de nom du projet Shared et des projets d Apps sont identiques. De manière similaire, les dictionnaires de ressources peuvent être spécifiques et/ou partagés. Pour cela, il suffit d ajouter 2 dictionnaires de ressource, un dans chaque projet d application. Ces dictionnaires doivent avoir le même nom et être dans le même espace de nom. Chaque dictionnaire peut alors avoir des ressources portant le même nom, mais définissant différents rendus selon la plateforme. Côté Windows : <ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:local="using:demo"> <SolidColorBrush Color="Blue" x:key="accentcolor"></solidcolorbrush> </ResourceDictionary> 11

Côté Windows Phone : <ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:local="using:demo"> <SolidColorBrush Color="Green" x:key="accentcolor"></solidcolorbrush> </ResourceDictionary> Le dictionnaire est alors déclaré dans le fichier App.xaml dans le projet Shared : <Application x:class="demo.app" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:local="using:demo"> <Application.Resources> <ResourceDictionary> <ResourceDictionary.MergedDictionaries> <ResourceDictionary Source="CustomStyles.xaml" /> </ResourceDictionary.MergedDictionaries> </ResourceDictionary> </Application.Resources> </Application> Enfin la ressource est utilisée, par exemple sur le contrôle Hello World : <Grid Background="{StaticResource AccentColor}"> <TextBlock Text="Hello World!" TextWrapping="WrapWholeWords" Style="{StaticResource HeaderTextBlockStyle}" VerticalAlignment="Center" HorizontalAlignment="Center" /> Projet Shared User Control Partagé Page Partagée Projet Windows Projet Windows Phone Accent Color Dictionnaire de ressources spécifique Accent Color Dictionnaire de ressources spécifique Figure 17 : Utilisation de styles spécifiques La gestion de l interface est plutôt flexible avec ce nouveau type d App. Cependant, cette flexibilité a aussi un coût : la désorganisation! Durant le développement d une UWA, il faudra être particulièrement vigilant à la structure des projets et rester consistant dans les choix entre vues, contrôles, styles partagés ou spécifiques. 12

GESTION DES REFERENCES Le projet Shared ne se compile pas, il ne produit pas de dll, il ne s agit que d un conteneur. Comment fait-on alors pour ajouter des références et pouvoir les utiliser dans ce projet Shared? Et bien, tout comme un contrôle spécifique doit exister dans les 2 projets d application, une référence à un système tiers doit être ajoutée aux 2 projets d application. Cela signifie donc que les UWA ne peuvent utiliser des systèmes tiers (dans le projet Shared) que s ils existent en version Windows et en version Windows Phone. Prenons MVVMLight de Laurent Bugnion comme exemple. Cette API est très largement utilisée et est compatible Windows 8, Windows Phone, WPF et Silverlight. L API doit être ajoutée aux 2 projets d applications : Figure 18 : Ajout d'une référence dans une UWA Si les API sont différentes ou n existent que pour une des 2 plateformes, il faudra utiliser les directives de compilation. Mais si les 2 versions de l API utilisent les mêmes espaces de nom et les mêmes objets, alors l utilisation dans le projet Shared de cette API se fait de manière transparente : using GalaSoft.MvvmLight; namespace Demo.ViewModel { public class MainViewModel : ViewModelBase { [...] // Propriétés coupées pour brièveté public MainViewModel() { HelloWorldText = "Hello World!"; } } } 13

MIGRER UN PROJET EXISTANT EN UWA Dans ce dernier petit chapitre je vais vous parler de migration. Supposons que vous avez un projet Windows 8.1 existant et que vous souhaitez le transformer en UWA. Microsoft fournit une option de migration qui va générer le projet Shared vide et le projet Windows Phone 8.1 RT contenant quelques images, un fichier App.xaml et un première page. Figure 19 : Migration d'un App Windows 8.1 en UWA Figure 20 : Structure de la solution après migration Si vous avez un projet Windows Phone existant, les choses se compliquent un peu : Si le projet utilise WinRT (Windows Phone 8.1 RT), alors la migration en UWA, se passe exactement de la même manière (clic droit sur le projet : «Ajouter Windows 8.1»), un projet Shared vide et un projet basique ciblant Windows 8.1 seront alors créés. Si en revanche le projet utilise Silverlight, aucune migration automatique n est disponible et ceci est somme toute bien normal : une App utilisant Silverlight n utilise pas la même API, n a pas le même cycle de vie etc. Une fois la migration effectuée, il ne reste plus qu à choisir quels fichiers, quelles vues seront partagés en copiant / déplaçant / modifiant vos fichiers existants. 14

CONCLUSION Les Universal Windows Apps sont une grande avancé vers l uniformisation des plateformes d Apps Microsoft. L industrialisation dans le développement d Apps apporté par cette annonce implique un développement sur plusieurs plateformes plus rapide. Mais il faut être rigoureux, bien cerner le projet dès le départ, donc potentiellement plus faire d analyse et de design avant d attaquer le développement : - Vues / User Controls / Styles / Rendu visuel etc. : partagés? spécifiques? - Les APIs tiers voulues sont-elles compatibles avec toutes les plateformes? Autant de questions à se poser très tôt pour avoir un projet structuré, pas de surprise dans l exécution et le rendu quel que soit la plateforme et un projet maintenable et évolutif. Le développement d une UWA donc ciblant plusieurs plateformes est désormais quasiment aussi facile que de développer une App pour une seule de ces plateformes. Les stores vont donc probablement se remplir, l audience étant cumulée. De plus, l arrivée prochaine du support Xbox One ne devrait qu amplifier cette tendance. Une excellente nouvelle pour tout possesseur d équipements Microsoft. TABLE DE LEGENDE Figure 1 : Modèle de programmation Windows RT... 1 Figure 2 : Section «Store Apps» de Visual Studio 2013 Update 2... 1 Figure 3 : Section «Universal Apps» de Visual Studio 2013 Update 2... 2 Figure 4 : Structure d'un projet UWA... 2 Figure 5 : Fenêtres de propriétés, onglet Application, des projets Windows et Windows Phone... 2 Figure 6 : Fenêtres de propriétés, onglet Build, des projets Windows et Windows Phone... 3 Figure 7 : Rendre une vue présente dans les 2 projets d App commune... 4 Figure 8 : Nouveautés du designer Xaml Visual Studio 2013 Update 2... 4 Figure 9 : Affichage d'une vue dans le contexte «Windows Phone»... 5 Figure 10 : Répartition des APIs dans le monde des UWA... 5 Figure 11 : Différences entre plateformes avec IntelliSense... 6 Figure 12 : Gestion du bouton physique «Back» d'un Windows Phone... 6 Figure 13 : Répartition des contrôles dans le monde des UWA... 7 Figure 14 : Différences de contenu entre une App Windows et une App Windows Phone... 7 Figure 15 : Page spécifique, contrôle partagé... 9 Figure 16 : Page partagée, contrôles spécifiques... 11 Figure 17 : Utilisation de styles spécifiques... 12 Figure 18 : Ajout d'une référence dans une UWA... 13 Figure 19 : Migration d'un App Windows 8.1 en UWA... 14 Figure 20 : Structure de la solution après migration... 14 15