Aujourd'hui, nous allons parler des tailles d'écran et pourquoi elles sont importantes dans le développement pour Windows 8. Dans la première partie de cet article, nous allons parler d'orientation, et des choses simples que vous allez pouvoir ùettre en place pour rendre vendre application utilisableu peu importe la manière dont vos utilisateurs tiennent leur appereil. Dans la seconde partie, nous verrons comment "snapper" votre application et comment adapter son interface à une taille d'écran réduite.

L'orientation et le snapping sont deux notions très importantes car si vous ne les traitez pas dans votre application, celle-ci peut se voir refuser sur le Windows Store. Si l'on regarde de près les prérequis pour la certification d'applications Windows 8 dans la section 3.6, on peut lire :

Your app must support a snapped layout. In landscape orientation, your app's functions must be fully accessible when the app's display size is 1024 x 768. Your app must remain functional when the customer snaps and unsnaps the app.

Ce qu'il est dit, c'est que votre application doit supporter trois états visuels au minimum :

• 1024px par 768 (résolution minimal) ;
• 320px par 768 (snapped) ;
• Votre résolution par défaut, généralement 1366px par 768.

Voici un exemple d'une application en plein écran qui passe à un été snapped :

Comme vous pouvez le voir, nous avons réorganisé le contenu pour s'adapter à l'espace réduit de mode snapped.

Heureusement, il y a des moyens simples pour reconnaitre quel est l'état de notre application. Dans le reste de l'article, nous allons étudier comment réaliser ces étapes.

Avant de commencer avvec le support des rotations et du snapping, nous allons découvrir comment exécuter et déboguer nos applications. Si vous êtes comme moi, vous aimez développer sur une machine quatres coeurs, peut être entre 8 et 12 Go de RAM, deux écrans 27 pouces, souris, clavier, ... Malheureusement, ces machines non pas de capteur d'orientation, et changer l'orientation de votre écran n'y fera rien. Heureusement, il y a trois moyens différents pour exécuter votre application : votre machine locale, un simulateur (inclus) ou une machine distante (non incluse) :

L'option Ordinateur local est certainement celle que vous avez déjà essayée. Votre application compile puis est déployée sur votre machine. Le débogueur de Visual Studio s'attache l'application. Comme nous l'avons dit avant, cette option est limitée du fait du type de matériel sur lequel vous développez.

Le simulateur. Comme son nom l'indique, c'est bien un simulateur et non un émulateur comme pour Windows Phone. Cela signifie qu'il simule uniquement que la machine sur laquelle vous travaillez et non pas un autre appareil. Votre machine ne dispose pas de capteur de mouvements ? Vous aurez besoin d'une autre machine. Quel est donc l'intérêt de l'émulateur ? Tous simplement car vous pourrez effectuer plus de choses comme des gestes multitouch, la rotation de l'écran et des tests avec plusieurs résolutions d'écran.

Enfin, mon option favorite : l'ordinateur distant.