Windows 8 : les applications Metro doivent restaurer la confiance

Il existe depuis longtemps un problème récurent sous Windows : le « winrot ». Littéralement « pourrissement de Windows », le terme recouvre le phénomène de ralentissement progressif du système pour de multiples raisons, la principale étant l’encrassement à chaque nouvelle installation d’application tierce. Microsoft compte se débarrasser de ce problème avec les applications Metro. Explications.

Le winrot

Chaque fois que vous installez le moindre élément dans Windows, des fichiers sont copiés, des paramètres sont modifiés, la base de registre est mise à jour. Le constat est également valable, si ce n’est davantage, avec les pilotes. Même lorsque vous désinstallez des applications, des traces restent en arrière. Petit à petit, le système s’encrasse, ralentit, phénomène accentué par nombre de produits jugeant utiles d’intégrer des éléments au démarrage du système.

Dans un billet sur son blog Windows 8, Microsoft parle de restaurer une « confiance » des utilisateurs en leurs applications. Évidemment, la recette magique est tout simplement de changer de base. Vista et Windows 7 ont mis en place certains mécanismes pour que la dégradation soit limitée, mais c’est l’architecture même de Windows qui permet actuellement le « winrot ». À nouvelle bases, nouvelles règles : plus question pour les applications de réclamer le pouvoir.

L’isolation des applications

Une application Metro est un univers indépendant. Elle est considérée comme un container au sein duquel elle réside, avec toutes les limitations que cela suppose. Ainsi, elle s’installe dans un espace dédié qui contient : l’application elle-même, les données relatives ainsi que les réglages. Si l’application est amenée à être supprimée plus tard, c’est tout cet espace qui disparaît sans laisser de trace.

L’indépendance de cette application a des conséquences dans ses capacités. L’application elle-même réside dans une sandbox, c’est-à-dire un espace mémoire isolé, et n’a droit par défaut à rien. Le développeur doit déclarer dans un manifeste à quoi son produit va devoir accéder. Ces déclarations recouvrent essentiellement trois domaines :

1. Les capacités de l’application : l’accès au matériel, aux données, et ainsi de suite
2. Les contrats, qui permettant de déclarer les liens avec les autres applications et le système. Par exemple, un client Twitter sera représenté dans les options de partage des autres applications.
3. Le FilePicker, qui permet de sélectionner un fichier précis sur l’ordinateur

Les capacités représentent sans doute le plus gros morceau. Elles se regroupent en quatre domaines :

• Les bibliothèques de données, telles que Musique, Vidéos, etc. Microsoft recommande l’utilisation du FilePicker, mais des applications tournées vers le multimédia par exemple, s'orienteront plutôt vers les bibliothèques.
• L’accès au matériel : dans le cadre d’une application Metro, l’accès direct au matériel est limité à seulement quatre cas : la webcam, le microphone, la géolocalisation et le matériel impliqué dans les communications de proximité, comme les puces NFC (Near Field Communication).
• L’accès au réseau : par défaut, les applications Metro ne peuvent accéder qu’à Internet. Pour accéder au réseau local ou d’autres possibilités plus précises, l’application doit en faire la déclaration.
• L’identité de l’utilisateur : la plupart des applications la demanderont, car elle permet de personnaliser le contenu. Dans la pratique, elle sera surtout utilisée par les applications professionnelles qui considèrent l’identité comme une clé pour débloquer par exemple un accès réseau d’entreprise.

L’intérêt direct de ces déclarations est qu’elles permettent au développeur de penser spécifiquement à ce que l’application va faire. Il ne suffit plus de viser une API pour accéder à tout un ensemble de fonctions. En outre, chaque déclaration se répercute sur le Windows Store : l’utilisateur est prévenu à l’avance des informations auxquelles accèdera l’application.

Du côté des développeurs

Microsoft recommande aux développeurs un certain nombre de points. L’un des plus importants est de ne déclarer que les éléments qui sont strictement nécessaires. Lors de la phase bêta, la firme a ainsi pu observer autant les retours utilisateurs que les habitudes prises par les développeurs lors des soumissions des applications au Store. Plusieurs erreurs courantes ont ainsi pu être notées.


Par exemple, la bibliothèque Documents était régulièrement utilisée à tort. Certaines applications y enregistraient ainsi leurs paramètres spécifiques alors que ça n’est pas leur place. Autre faute : y enregistrer par défaut les données générées par l’utilisateur, alors que ce dernier doit avoir le choix. Enfin, pour envoyer un document à une autre application : le contrat Partage est conçu pour ce type de cas.

Concernant la distribution de l’application, les développeurs n’ont en revanche plus à s’occuper du moindre installeur. Les capacités d’assemblage et de distribution sont laissées aux soins de Visual Studio et du Windows Store. Ce dernier concentre les téléchargements, les critiques, les notes, l’affichage des informations auxquelles l’application accède ainsi que l’ensemble des mises à jour et la gestion des paiements (quand l’application est payante).

En clair, si le Windows Store n’a rien de nouveau dans son concept, il s’agira de la première fois que les utilisateurs pourront gérer leurs applications à la manière d’une plateforme mobile. Car il ne faut pas s’y tromper : les containers d’applications héritent directement du modèle proposé par iOS, Android, Windows Phone et autres, lui-même basé sur ce qui existe depuis bien des années sous Linux.

Le fait est qu'il faudra dans la pratique du temps. Créer des applications Metro réclame les API WinRT. Or, ces dernières seront essentiellement adaptées à des usages de type tactile, même si Microsoft estime qu'elles seront pleinement utilisables au clavier et à la souris. Le Store gèrera également les applications actuelles, mais leur distribution et leur gestion manque pour l'instant de détails.

Source : Microsoft

Le 22 mai 2012 à 16:57 (20 795 lectures)

Tweeter

Actu Précédente Actu Suivante