Migration de vos applications de la version Developer Preview vers la version Consumer Preview

Blog des développeurs d'applications Windows 8

Indications sur la conception d'applications de style Metro pour Windows 8, par l'équipe d'ingénierie de Windows 8

Migration de vos applications de la version Developer Preview vers la version Consumer Preview

  • Comments 0

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 !

Un nouveau départ

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 !)

  1. Créez un nouveau projet dans Visual Studio et choisissez le modèle qui ressemble le plus à l'interface utilisateur de votre application existante.
  2. Si les nouveaux modèles d'éléments prennent en charge les contrats et les fonctionnalités dont vous avez besoin, tels que le contrat du sélecteur de fichiers ou le contrat de recherche, utilisez-les au lieu d'essayer de réutiliser votre code existant.
  3. Après avoir reconstruit les éléments élémentaires de votre interface utilisateur à l'aide des nouveaux modèles, migrez vos ressources visuelles et audio de votre ancien projet vers le nouveau. Limitez le code supplémentaire que vous intégrez au projet à la seule logique métier personnalisée qui était au cœur de votre application.
  4. Enfin, commencez à assembler votre nouvelle interface utilisateur (structurée avec les nouveaux modèles) à vos ressources visuelles et audio et à votre logique principale.

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.

Modifications générales affectant tous les langages

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.

Modifications appliquées au manifeste

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.

Modèle asynchrone de démarrage à chaud

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.

Gestion de la durée de vie déterministe des objets Windows Runtime (IClosable)

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.

Modèle de thread WinRT simplifié

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 :

  • La durée de vie de l'objet est liée au cloisonnement dans lequel il a été créé.
  • Le comportement de marshaling automatique enfreint le principe de moindre surprise.
  • Les rappels d'événement s'exécutent souvent sur un thread inattendu.
  • Les délégués sont incohérents dans C++ / C#.

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 :

  • La durée de vie d'un objet est désormais liée aux références ouvertes. L'objet demeure valide jusqu'à la sortie de la dernière référence.
  • La plupart des objets sont agiles. Les appels aux méthodes sur ces objets se produisent directement sur le thread actuel.
  • Les événements les plus récents sont réacheminés vers le thread dans lequel l'événement a été inscrit. Il existe toujours des cas où les rappels d'événement peuvent se produire sur un thread de travail. Mais ils sont moins courants.
  • Les délégués C++ sont maintenant agiles par défaut, tout comme l'étaient les délégués C# dans la version Developer Preview. Les délégués peuvent toujours remarshaler vers le thread dans lequel ils ont été créés si vous spécifiez CallbackContext::Same lors de la création du délégué.

Modifications apportées à Windows.ApplicationModel (contrats)

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.

Combinaisons des protocoles URI

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.

Modifications importantes appliquées aux applications de style Metro HTML/CSS/JS

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.

Modifications appliquées aux contrôles

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.

Navigation au sein du document de haut niveau

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.

Modèle de page et chargement de fragments WinJS

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.

Arrêt des applications lors d'exceptions non gérées

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.

Modifications importantes appliquées aux applications de style Metro XAML

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.

Prise en charge de la liaison de données C++

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.

API de navigation

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.

Contrôle AppBar

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.

Zoom sémantique

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.

Voie à suivre

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

  • Loading...
Leave a Comment
  • Please add 6 and 3 and type the answer here:
  • Post