Conception de Windows 8
Blog Windows Store pour les développeurs
IEBlog Français
Blog Visual Studio
Blogs de l'équipe Windows
Blog Windows Live
Télécharger Windows 8 Release Preview
Centre de développement : applications de style Metro
Suivez-nous @windevs
Conférence BUILD de Windows //build/
Développement d’applications Metro
Bonjour, je m'appelle John Sheehan, architecte partenaire de l'équipe de développement Windows.
Nous sommes vraiment heureux que vous conceviez des applications pour les versions d'aperçu. Vos commentaires nous aident à rendre Windows 8 formidable. Évidemment, concevoir des applications à partir d'une version d'aperçu signifie que vous devez mettre à jour vos applications à chaque nouvelle version d'aperçu. C'est de cela que traite ce billet, de la migration de vos projets de la version Developer Preview vers la version Consumer Preview. Je vais présenter ici certaines des modifications, mais pour obtenir le guide détaillé des modifications, vous pouvez télécharger le livre blanc sur la migration des applications de //Build vers la version Windows 8 Consumer Preview dans le Centre de développement.
Je suis certain que lorsque vous pensez à la migration de vos applications vers la version Consumer Preview, certains d'entre vous se demandent pourquoi nous avons choisi d'effectuer certaines de ces modifications. Je peux personnellement vous assurer que nous prenons chaque modification très au sérieux. Certaines améliorations sont apportées en fonction des commentaires directs que nous recevons : si une fonctionnalité est déroutante, nous la simplifions et il peut arriver que certaines fonctions nécessaires ne sont pas présentes. De même, après avoir terminé une fonctionnalité et avoir commencé à l'utiliser nous-mêmes, nous réalisons parfois qu'elle ne correspond pas exactement à nos attentes, alors nous en tirons les leçons et l'améliorons. De nombreux facteurs sont à prendre en compte. Rassurez-vous, nous prenons chaque décision avec soin en ayant comme objectif la création d'une plateforme extraordinaire pour vos applications de style Metro.
J'ai dû suivre le processus de migration avec l'application Connect 4 que j'ai conçue dans la version Developer Preview. Je sais que la migration demande quelques efforts. Mais si vous suivez les étapes indiquées dans le billet et le document, vous serez opérationnel assez rapidement.
Alors, allons-y !
Bien qu'il puisse être tentant de conserver votre projet existant et d'essayer de le migrer vers la version Consumer Preview, suffisamment de changements ont eu lieu depuis la version Developer Preview pour qu'il soit préférable de recommencer avec un nouveau projet. Par exemple, plusieurs modifications ont été apportées aux fichiers de définition de projet dans Visual Studio : l'extension de projet JavaScript a été renommée en .jsproj et l'instruction d'importation modifiée en fichiers .csproj/.vbproj. Votre projet existant ne s'ouvrira même pas en raison de ces changements. Après avoir recommencé un nouveau projet, vous pouvez transférer des parties de votre ancien projet dans le nouveau.
Ces étapes sont appropriées à la migration de votre code. Vous pouvez également les trouver, ainsi que bien d'autres détails sur la migration, dans le document //Build vers Windows 8 Consumer Preview. (Je le mentionnerai encore plusieurs fois avant que vous n'ayez terminé la lecture de ce billet !)
En suivant ces étapes, vous incorporerez naturellement un grand nombre des modifications dans le code de votre application. Discutons maintenant de certaines modifications spécifiques susceptibles d'affecter votre code lorsque vous le transférez dans les nouveaux modèles.
D'abord, j'aimerais décrire certaines modifications apportées au modèle de programmation de base qui affectent les développeurs, quel que soit leur langage de programmation.
Le manifeste est l'identité de votre application. Lorsque nous apportons des modifications à la plateforme, celles-ci ont souvent un impact sur la structure du manifeste. Étant donné le nombre de modifications apportées au manifeste, il sera probablement plus simple d'utiliser le nouveau manifeste qui est créé lorsque vous créez un nouveau projet et de faire appel à l'éditeur de manifeste pour le modifier, au lieu d'essayer de transférer votre manifeste existant.
Dans la version Developer Preview, toutes les méthodes asynchrones bénéficiaient d'un démarrage à froid. Lorsque vous appeliez une méthode asynchrone, vous obteniez en retour un objet d'opération asynchrone. Vous vous inscriviez pour des rappels d'achèvement et de progression (le cas échéant) sur cet objet d'opération, puis appeliez IAsyncInfo.Start. Le problème de ce modèle était que l'appel à Démarrer était redondant. En tant que développeur, vous pouviez raisonnablement vous attendre à ce que l'opération asynchrone démarre lors de l'appel de méthode initial.
Pour rendre le modèle asynchrone plus intuitif, nous l'avons transformé en modèle de démarrage à chaud. Dans la version Consumer Preview, lorsque vous appelez une méthode asynchrone, vous recevez un objet d'opération asynchrone, mais vous n'avez pas besoin d'appeler Démarrer. En revanche, l'opération démarre implicitement lorsque la méthode asynchrone est appelée. Comme nous n'avons plus besoin de Démarrer, nous l'avons supprimé de IAsyncInfo.
Si vous avez déjà utilisé .then() (JavaScript) ou await (C#), cette modification ne vous concerne pas.
Nous avons en outre ajouté des tâches PPL pour simplifier la programmation asynchrone en C++. Je vous recommande de consulter le didacticiel //Build vers Windows 8 Consumer Preview et de migrer votre code asynchrone vers le modèle PPL.
Les API Windows Runtime peuvent permettre à votre application d'accéder aux ressources systèmes, telles que les descripteurs de fichiers et les sockets réseau. Ces ressources sont limitées et il arrive souvent que l'utilisateur ou d'autres applications ne puissent pas les utiliser lorsque votre application y accède. Votre application est responsable de la libération de ces ressources après avoir fini de les utiliser. Dans la version Developer Preview toutefois, il était difficile de libérer explicitement ces ressources et par conséquent, de nombreuses applications s'y maintenaient rivées plus longtemps que de raison.
Dans la version Consumer Preview, les API Windows Runtime qui accèdent à ces ressources système peuvent contrôler leur durée de vie. Par exemple, dans JavaScript ces objets WinRT exposent une méthode Close et implémentent en C# l'interface IDisposable. Avec la gestion de la durée de vie exposée directement sur ces API WinRT, il est maintenant beaucoup plus facile de libérer les ressources système lorsque votre application a fini de les utiliser. Utilisez ces nouvelles fonctions de gestion de la durée de vie pour réduire la consommation des ressources de votre application et vous assurer que vos clients ont toujours accès à leurs ressources système (comme les fichiers) lorsque votre application ne les utilise pas.
Vous nous avez indiqué par le biais de vos commentaires que le modèle de thread COM sous-jacent à WinRT était déroutant, car il introduisait des considérations qui n'existent pas dans d'autres environnements de programmation. Certains des problèmes étaient les suivants :
Pour résoudre ces problème, nous avons modifié le modèle de thread pour les objets WinRT. À haut niveau, les modifications sont les suivantes :
Nous avons appliqué de nombreuses améliorations aux contrats dans la version Consumer Preview. Plus précisément, il s'agit de modifications intégrées aux API, aux fonctionnalités, aux inscriptions du manifeste et à l'interface utilisateur. Les contrats, tels que les contrats de recherche, de partage, de paramètres et du sélecteur de fichiers ont tous été modifiés d'une façon ou d'une autre. Nous avons par exemple ajouté un nouveau contrat du sélecteur de fichiers, FileSavePickerActivatedEventArgs, qui permet à votre application d'agir comme cible de l'opération Enregistrer sous. Cette fonctionnalité est extrêmement puissante. Avec elle, vous pouvez créer un sélecteur qui permet aux utilisateurs d'ouvrir et d'enregistrer des fichiers dans votre cloud aussi facilement que s'ils utilisaient le disque local. Pour s'adapter à cette modification, nous avons renommé le contrat du sélecteur de fichiers dans la version Consumer Preview en FileOpenPickerActivatedEventArgs.
Pour les contrats pris en charge dans Visual Studio, la façon la plus simple d'incorporer ces modifications est d'utiliser le nouveau modèle d'élément pour créer intégralement le contrat. Vous pouvez ensuite ajouter votre code existant qui prend en charge le contrat dans le nouveau modèle.
Un certain nombre d'API s'appuyaient sur les combinaisons des protocoles URI pour accéder au contenu du package de l'application ou des emplacements d'état ApplicationData de l'application. Ces API incluent des balises de ressources dans les applications de style Metro écrites en HTML/CSS/JS, des mosaïques dynamiques, les API ResourceLoader, le contrôle XAML WebView et les API de stockage de fichiers.
Nous avons actualisé les noms des protocoles pour les rendre homogènes dans les applications de style Metro et dans les points d'intégration de Windows 8. Nous avons également renommé ces combinaisons des protocoles :
Combinaison Developer Preview
Combinaison Consumer Preview
ms-wwa://
ms-appx://
ms-wwa-web://
ms-appx-web://
localfolder://
ms-appdata://
En outre, les applications XAML ne peuvent maintenant qu'utiliser les combinaisons des protocoles prises en charge, telles que ms-appx://, pour accéder aux ressources.
Plusieurs modifications intégrées à la version Consumer Preview sont spécifiques aux applications de style Metro écrites en HTML/CSS/JS. Voici certaines des modifications les plus notables.
Les contrôles JavaScript et HTML disponibles dans la version Developer Preview ont subi quelques changements, en réponse à vos commentaires. Il est maintenant plus simple d'ajouter des contrôles à votre application et les méthodes permettant d'accrocher des contrôles à votre contenu sont plus intuitives. Certains des contrôles importants qui ont changé et qui nécessiteront une mise à jour sont ListView, AppBar et FlipView. Par exemple, vous ne pouvez plus utiliser ArrayDataSource pour renseigner un contrôle ListView. En revanche, vous pouvez maintenant utiliser WinJS.Binding.List pour renseigner vos contrôles ListView. Binding.List facilite la gestion de votre contrôle ListView dans les données chargées en mémoire.
Je vous renvoie à nouveau au document //Build vers Windows 8 Consumer Preview qui décrit toutes les modifications appliquées aux contrôles.
Vous pouviez auparavant naviguer au sein du document de haut niveau de votre application à partir de la page de démarrage du package local vers une URL Web. Cela empêchait votre application d'interagir avec les notifications importantes, telles que les interruptions et les reprises, parce que ces événements sont des événements Windows Runtime et que, pour des raisons de sécurité, les objets WinRT sont inaccessibles dans le contexte Web. Dans la version Consumer Preview, vous ne pouvez plus accéder à un contenu autre que celui qui se trouve dans le contexte local. En d'autres termes, le contenu doit provenir du package de votre application et doit être référencé via la combinaison des protocoles ms-appx://.
Par conséquent, vous devrez peut-être réorganiser la logique de votre application afin de vous appuyer sur un élément iframe pour charger votre contenu Web en gardant toujours en mémoire un document de haut niveau unique et persistant à partir du contexte local.
Dans la version Developer Preview, le modèle de navigation des applications de style Metro HTML/CSS/JS reposait sur les API de chargement de fragments pour la navigation vers différentes pages au sein d'une application. Ce modèle était fragile et vous obligeait à écrire beaucoup de code pour gérer l'initialisation des contrôles et l'état des pages.
Dans la version Consumer Preview, nous avons introduit un contrôle de page de haut niveau dans la bibliothèque Windows pour JavaScript (WinJS) afin de charger le contenu au sein d'une page. Nous avons en outre actualisé les modèles Visual Studio pour utiliser ces contrôles de page. Dans la plupart des cas, les contrôles de page contournent la nécessité de gérer directement les API de chargement de fragments. Cela rend la navigation dans vos fragments HTML beaucoup plus facile.
Contrôles de page reposant sur le dispositif de chargement de fragments. Ils fournissent un objet réel qui confirme les fragments rendus, vous donnent un endroit où stocker l'état et gère le parentage du fragment pour vous. Il existe un contrôle WinJS qui confirme votre fragment (associé à un élément DOM apparenté) et qui lui fournit un cycle de vie bien défini. Vous pouvez également ajouter des méthodes arbitraire ou un état à cet objet de contrôle.
JavaScript est très tolérant en ce qui concerne les exceptions non gérées. Il arrête l'exécution de tout code supplémentaire dans la fonction contenant l'exception, mais sinon il continue d'une façon qui passe souvent inaperçue. Lorsque cela se produit, votre application n'est plus dans un état prévisible. Cela signifie que les données sur lesquelles repose votre application peuvent ne pas être valides, ou votre interface utilisateur peut se retrouver dans un état défectueux. Dans un navigateur Web, cela peut être acceptable, car l'utilisateur a la possibilité de réactualiser la page. Mais dans une application de style Metro, l'utilisateur doit être en mesure d'exécuter votre application sans jamais avoir besoin de la fermer pour la rouvrir.
Ainsi, une exception JavaScript non gérée consigne maintenant un message d'erreur dans le journal des événements et arrête l'application.
Si vous avez développé des applications de style Metro XAML, vous remarquerez des changements dans la version Consumer Preview qui sont spécifiques à vos langages de programmation.
Dans la version Consumer Preview, nous avons apporté d'importantes modifications pour les développeurs C++ afin de rendre beaucoup plus simple la liaison de données de l'interface utilisateur XAML sur les classes C++ personnalisées. Lorsque vous utilisez l'annotation dans votre classe via l'attribut Windows.UI.Xaml.Data.Bindable, votre classe devient visible pour le moteur de liaison et vous n'avez plus besoin d'implémenter l'interface dans cette classe. Cela réduit de façon significative la quantité de code.
Si votre application de style Metro XAML utilise des API de navigation, telles que Windows.UI.Xaml.Controls.Frame.Navigate ou Windows.UI.Xaml.Navigation.NavigationEventArgs.Type, vous devrez effectuer quelques modifications rapides. Ces API acceptent désormais un objet Type comme cible, au lieu de la représentation du nom de chaîne de la classe. Consultez le document //Build vers Windows 8 Consumer Preview pour obtenir la liste complète des API affectées.
Nous avons appliqué de nombreux changements à la fonctionnalité Windows.UI.Xaml.Controls.ApplicationBar pour la rendre plus cohérente avec l'expérience utilisateur des applications de style Metro. Ces changements vous évitent en outre de vous soucier de l'implémentation des détails pour qu'elle corresponde à l'expérience de style Metro.
Une des modifications majeures est que vous pouvez insérer un contrôle AppBar au sein de votre application à l'aide des nouvelles propriétés Windows.UI.Xaml.Controls.Page.TopAppBar et BottomAppBar. Nous vous recommandons d'utiliser ces nouvelles propriétés au lieu d'insérer vos contrôles AppBar directement au sein de la disposition de votre application. Nous avons ajouté, renommé ou supprimé plusieurs autres propriétés AppBar.
Le zoom sémantique est le terme utilisé sur la plateforme Windows 8 lorsque l'utilisateur peut effectuer un zoom avant ou arrière sur le contenu et changer son contexte. Par exemple, un zoom avant sur une collection de photos peut transformer des photos sous forme de petites miniatures en aperçus de grande taille, complétés par des noms, des dates, etc. Le contrôle JumpViewer activait le zoom sémantique dans la version Developer Preview. Il a été renommé en contrôle SemanticZoom. Le nouveau nom reflète mieux l'expérience utilisateur que vous proposez lorsque vous implémentez un de ces contrôles dans votre application.
Outre les modifications indiquées dans ce billet, de nombreuses API dans Windows Runtime et dans la bibliothèque Windows pour JavaScript ont changé. Dans Windows Runtime par exemple, des modifications ont été appliquées à la mise en réseau, au multimédia, au système, à l'interface utilisateur, au stockage, aux périphériques, au modèle d'application, à la globalisation, aux graphismes et aux espaces de noms des données. Bien qu'un grand nombre de ces modifications soient mineures, vous devrez être prudent lors de la migration de votre code afin de réaliser tous les ajustements nécessaires dans votre application. Ce billet a pour but de vous permettre de démarrer, mais il ne couvre qu'une petite partie des modifications que nous avons apportées à la plateforme de développement. Comme je le suggère tout au long du billet, consultez le document //Build vers Windows 8 Consumer Preview dans le Centre de développement pour obtenir des informations détaillées sur la migration de votre application vers la version Consumer Preview.
J'ai hâte de lire vos commentaires. Si vous avez des questions détaillées sur les procédures, je vous suggère de les poser sur les forums de développement et nous vous guiderons.
-- John Sheehan, architecte partenaire, Développement Windows