introduction aux apps universelles windows

Transcription

Introduction Aux Apps Universelles Windows
Cécile Voissier
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
Cécile Voissier
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
Cécile Voissier
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.
2.
3.
Cécile Voissier
Copier un des 2 fichiers MainPage.xaml dans le projet Shared
Supprimer les fichiers MainPage.xaml des 2 projets d’App
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
Cécile Voissier
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
Phone
uniquement
APIs Windows
uniquement
Exemples :
- Contrat de recherche
- Charme Paramètres
- etc.
Exemples :
- Boutons physique « retour »
- Action Center
- etc.
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
Cécile Voissier
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 PLATEFORM ES
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


Cécile Voissier
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
Contrôles
Windows Phone
uniquement
Exemples :
- SearchBox
- SettingFlyout
- etc.
Exemples :
- AutoSuggestBox
- Pivot
- ...etc.
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
Cécile Voissier
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" />
</Grid>
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> 
<AutoSuggestBox x:Name="SearchText" />
<Button Style="{StaticResource IconButtonStyle}" Grid.Column="1" Content=""
x:Name="SearchButton" />
</Grid>
</StackPanel>
8
Cécile Voissier
Nous avons ici plusieurs techniques pour résoudre le problème tout en essayant de mutualiser un maximum de code Xaml.
1.
2.
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.
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écile Voissier
Côté Windows Phone :
<Grid Margin="12 0 0 0" Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
<RowDefinition Height="Auto" />
<StackPanel Orientation="Vertical">
<TextBlock x:Name="pageTitle" Text="Demo App"
Style="{StaticResource GroupHeaderTextBlockStyle}"
IsHitTestVisible="false" TextWrapping="NoWrap" VerticalAlignment="Bottom" />
<Grid> 
<AutoSuggestBox x:Name="SearchText" />
<Button Style="{StaticResource IconButtonStyle}"
Grid.Column="1" Content="" x:Name="SearchButton"/>
</Grid>
</StackPanel>
<local:HelloWorldControl Grid.Row="1" Margin="0 0 12 0"/>
</Grid>
Côté Windows :
<Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
<RowDefinition Height="140" />
<Grid>
<ColumnDefinition Width="120" />
<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" />
</Grid>
<local:HelloWorldControl Grid.Row="1" />
</Grid>
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
Cécile Voissier
Projet Shared
Page Partagée
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}">
<RowDefinition Height="Auto"/>
<RowDefinition Height="*"/>
<local:HeaderControl Grid.Row="0"/>
<local:HelloWorldControl Grid.Row="1" />
</Grid>
</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écile Voissier
Côté Windows Phone :
<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
<SolidColorBrush Color="Green" x:Key="AccentColor"></SolidColorBrush>
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"
<Application.Resources>
<ResourceDictionary>
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="CustomStyles.xaml" />
</ResourceDictionary.MergedDictionaries>
</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" />
</Grid>
Projet Shared
Page Partagée
Projet Windows
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
Cécile Voissier
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
Cécile Voissier
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
Cécile Voissier
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

introduction aux apps universelles windows

Transcription

Documents pareils

recrute - Neuilly

FDP Saitek X52 Flight Control System

IcProg 1.05C/ Windows_XP Alain le 27.08.06 Je viens de faire une

JOB VACANCY - monaco technologies

Revista de Prensa

Dial-a-fix pour corriger les mises à jour de Windows.

Se connecter a Windows xp automatique avec Auto logon

Le mode sans échec.

developpeur informatique alternance deux

Hasta La Vista, VISTA !