Découvrir la plateforme

Avec Windows Phone 7, les fondations du hardware des téléphones seront les mêmes.

Les tripes :

• Un processeur ARMv7 : Cortex, Scorpion, ou mieux
• 256Mo de RAM et 8 Go de ROM ou plus
• Un GPU qui supporte au moins DirectX9
• Des specs multimédia communes incluant une accélération hardware des codecs

Et l'enrobage :

• Un appareil photo 5MP avec flash et bouton hardware pour prendre la photo
• Des capteurs : A-GPS, Boussole, Luminosité et proximité
• 3 boutons hardware : Démarrer, Recherche, et Windows
• 2 résolutions : WVGA (800x480) et HVGA (480x320)
• Un écran capacitif supportant au moins 4 points de contacts

L'avantage de spécifier le matériel de cette façon est de diminuer au maximum la fragmentation du parc de terminaux : de cette façon les développeurs savent exactement à quoi s'attendre d'un Windows Phone 7 à un autre. Il est donc encouragé de se servir de toutes ces ressources quand vous construisez votre application. Vous les retrouverez dans tous les téléphones !

Le système d'exploitation est une base Windows Embedded CE 6.0 R3 modifiée en profondeur dans laquelle Microsoft a la responsabilité de la très grande majorité du code, y compris des drivers. La seule intégration qui est laissée au fabricant du terminal est la couche basse des drivers, celle directement en contact avec le silicium, qui peut varier d'un téléphone à l'autre (par exemple, tous les fabricants n'utilisent pas la même référence de capteur de mouvement : pourtant vu du système il doit s'adresser de la même manière). Cela permet d'avoir une API unifiée pour les capteurs, mais aussi pour les couches radios, graphiques, multimédia, etc.

Au-dessus de ce noyau (un véritable OS à part entière sans base de code commune avec Windows, avec gestion du paging de la mémoire, de la sécurité), on trouve le modèle d'application, avec la gestion des sandbox, des mises à jour, des installation/désinstallation et des licences des applications, etc.

On trouve également le shell et le modèle graphique, avec notamment un modèle de composition spécifique qui permet d'avoir une navigation intuitive, cohérente, et surtout, accélérée graphiquement ! Enfin, dernier composant de la couche applicative de l'OS, l'intégration avec les services dans le cloud, notamment les notifications en push, la géolocalisation, l'intégration avec les Windows Live ID, Bing, et le Xbox Live. Enfin, au-dessus de ça, on retrouve la couche applicative avec les deux frameworks de développement, XNA et Silverlight, et bien entendu les applications que l'utilisateur aura téléchargées sur Marketplace.

Sans rentrer dans les détails du système d'exploitation (la documentation Windows Embedded CE 6.0 R3 regorge de détails techniques), on peut dire que l'OS est un système temps-réel dur, entièrement multi-tâche, avec un modèle de sécurité, un modèle de drivers et une gestion de la mémoire qui lui sont propres et qui ont complètement été modifiés par rapport à Windows Embedded CE 5.0, qui servait de base pour Windows Mobile 6.x. La limitation à 32 processus n'existe plus, pas plus que la limitation de 32Mo de mémoire par processus. Les espaces kernel et user sont séparés et les drivers peuvent être isolés les uns des autres, procurant ainsi au système une modularité et une indépendance maximale entre les composants, ce qui réduit l'impact en cas de bug ou de faille de sécurité éventuelle.

La vie d'une application commence évidemment au moment de son développement. :-) Mais ce n'est pas le sujet, car on essaie ici de s'intéresser à la plateforme applicative : on va donc laisser les phases de design/développement/debuggage à d'autres articles. A ce stade l'application sera packagée sous forme d'un XAP et envoyée au processus de certification.

La phase de certification est une mise à l'épreuve, que ce soit en terme de stabilité mais aussi de fonctionnalités. En effet, le développeur devra spécifier quelles sont les fonctionnalités du téléphone auquel son application pourra accéder : cela permettra ensuite au système de calibrer la sandbox de cette application, afin d'autoriser l'accès aux différentes API du terminal, et ce point sera évidemment validé lors de la certification, par des tests directement menés directement sur l'IL (Intermediate Language), ce qui autorise l'obfuscation du code. A l'issue de cette certification, une signature et une licence seront émises par Microsoft :

• La signature permet de s'assurer que seul du code signé tourne sur le téléphone et qu'on ne peut pas altérer l'application directement sur le terminal
• La licence permet de gérer à la fois le mode « trial » d'une application (on en reparlera plus tard dans l'article) mais aussi à s'assurer qu'une application est associée à un terminal et donc qu'on ne peut pas simplement copier une application d'un terminal à un autre. C'est une garantie anti-piratage de plus pour le développeur. Enfin, la licence sert aussi à gérer la révocation d'une application sur des terminaux.

A ce stade, le XAP signé peut-être publié sur Marketplace, disponible pour installation par l'utilisateur. L'utilisateur a la main sur l'installation, la désinstallation et l'exécution de l'application. Pas question qu'elle tourne de façon indépendante, et qu'il en reste des morceaux après une désinstallation. En revanche, c'est Marketplace qui a la main sur l'aspect révocation de l'application, par exemple en fin de période d'essai ou en cas de découverte d'un problème. Dans tous les cas, que ce soit pendant ou après l'installation, l'application n'a aucun contrôle sur sa vie dans le téléphone.

Chaque application dispose de sa propre sandbox, conçue selon les besoins d'accès aux API décrits par le développeur (et vérifiés à la certification). Chaque sandbox est associée à un compte utilisateur qui les rend complètement étanches les unes des autres. Enfin, des systèmes de gestion des ressources intégrés au système garantissent que c'est toujours l'application affichée au premier plan qui aura la main, et que le bouton Start répondra toujours quel que soit l'état de l'application affichée. Nous aborderons plus en détails ces notions une fois que nous serons passés sur les concepts de l'interface utilisateur. Chaque application dispose également de son propre espace de stockage (Isolated Storage).

Il appartient au développeur de choisir s'il autorise l'utilisation de son application sous forme de « version d'essai ». Dans le cas où cet usage serait autorisé, un bouton « Try » apparaitra dans la page de l'application sur Marketplace. Ensuite, dans l'application en elle-même, afin de détecter si l'utilisateur est en mode « essai » ou « version finale », il suffira de regarder la valeur de retour de la méthode « IsTrial() » : si elle retourne « true », c'est une version d'essai, sinon c'est une version finale. Attention, dans la CTP, cette méthode retourne toujours « true » !

Pas question ici de s'attarder sur la couleur des boutons ou les choix des designers, intéressons-nous plutôt à ce qui est utile pour le développeur à savoir comprendre la notion de session, d'application, de page, les différents éléments qu'on peut voir à l'écran, et les interactions qu'il peut y avoir avec les applications.

La notion de session est le fait que pour un utilisateur, la transition entre la page « start », les pages d'un hub, une ou plusieurs application(s), doit être transparente : il ne doit pas y avoir de notion de changement de contexte. C'est pourquoi on parle de « session » dans laquelle une ou plusieurs pages d'une ou plusieurs applications ou hubs peuvent intervenir. Chaque session démarre depuis la page « start ». Le système maintient une pile des pages qui ont été affichées et lorsque l'utilisateur presse le bouton « back » on revient systématiquement à la page précédente de la session, jusqu'à la page « start » qui marque la fin de la session. C'est un modèle de navigation cohérent à travers tout le téléphone, et quel que soit le contexte (hub, application native ou application tierce).

L'image ci-dessous nous explique les différentes couches qu'on peut retrouver à l'écran, et leur « z-order » (l'ordre de superposition) qui, au passage, est géré directement par le système et sur lequel nous n'avons pas la main :

Au-dessus de la surface Direct3D, on commence par retrouver l'expérience « Start » et, au-dessus de celle-ci, la page de l'application. Le clavier virtuel (Software Input Panel ou SIP) vient en overlay au-dessus de l'application, de la même manière que l'App-Bar, qui contient des icônes spécifiques à chaque page de l'application et qui peut même contenir un menu. Encore au-dessus de ça, on trouve les notifications, que ce soit le system tray, le contrôle du volume, ou les notifications d'appel.

L'application active est considérée comme au premier plan (foreground) et toutes les autres en arrière-plan (background). Seule l'application en foreground est autorisée à faire tourner du code : les autres sont figées. Lorsqu'on affiche une notification, l'application est dite « obscurcie » mais continue à tourner. En revanche, si l'on ouvre une autre application ou une autre session, l'application passe en background et dispose alors d'un temps limité pour sauvegarder son contexte : attention, une fois en background, une application peut être tuée sans en être notifiée, pour économiser la mémoire. Le système est donc responsable de savoir dans la session qu'est-ce qu'il garde en mémoire et qu'est-ce qu'il tue : dans le cas où il « tue » une page ou une application, il la relancera si l'utilisateur presse le bouton « back » pour y revenir, et c'est à ce moment-là au développeur de l'application d'avoir prévu de quoi restaurer l'état de l'application. D'où l'importance de bien comprendre le cycle de vie de son application.

Les concepts ci-dessus s'appliquent bien entendu aux jeux en XNA autant qu'aux applications Silverlight, à ceci près que les jeux n'ont ni SIP ni App-Bar…

Bien qu'elle soit sandboxée, une application peut évidemment interagir avec certaines parties du système : un espace de stockage qui leur est réservé (l'isolated storage) par exemple, mais aussi les capteurs, ou encore certaines applications natives qui donnent accès aux données contenues sur le téléphone comme la liste des contacts ou des titres stockées dans la collection de musique. L'accès à ces API est soumis à déclaration dans le manifest de l'application des « capabilities » de l'application. Celles-ci sont testées au moment de la certification, et sont au nombre de 9 :

• Gamer Services – l'accès au Xbox Live
• Location Services – pour la géolocalisation
• Media Library – pour accéder aux media locaux
• Microphone – pour capturer un flux audio
• Networking – pour accéder à la connexion de données
• Place Phone Calls – pour autoriser le déclenchement d'appels téléphoniques
• Push Notifications – pour recevoir des notifications poussées depuis un serveur tiers
• Sensors – pour accéder aux capteurs du terminal
• Web Browser – pour permettre la navigation sur le web à l'intérieur de l'application.

L'utilisateur sera averti des capacités de l'application au moment de l'achat, et seulement à ce moment-là. S'il accepte et installe l'application, la sandbox de celle-ci sera dimensionnée en fonction de ces capabilities, ce qui interdira l'accès aux API qui n'ont pas été déclarées.

Dans Windows Phone 7, il n'est pas possible d'accéder directement au système de fichiers. Pour autant, il est important qu'une application puisse stocker des données, et c'est le rôle de cet espace de stockage qu'on appelle isolated storage. Il est qualifié d'isolé car il est unique pour chaque application, et abstrait du système de fichiers. L'isolated storage pour Windows Phone 7 est le même que pour Silverlight 3.

L'usage des capteurs permet deux choses différentes : placer l'information dans un contexte (dans le cas du GPS par exemple) ou servir de périphérique d'entrée (l'accéléromètre par exemple). Avec Windows Phone 7, l'accès aux capteurs se fait avec les mêmes API d'un terminal à un autre. Il existe deux manières de communiquer avec un capteur :

• De façon asynchrone : c'est le capteur qui nous envoie au fur et à mesure les informations : le développeur enregistre alors une fonction de rappel (callback) auprès du système qui sera appelée à chaque fois que le capteur détectera un changement de son état (changement de position pour le GPS par exemple)
• De façon synchrone : dans ce cas c'est le développeur qui demande son état au capteur quand bon lui semble : on appelle ça le polling.

En fonction des cas d'utilisation on préfèrera une méthode plutôt qu'une autre. Dans tous les cas, il faut avant de se lancer regarder quelles sont les méthodes disponibles en fonction du capteur.

En plus de cela, il sera possible de faire vibrer le terminal : c'est un feedback discret et utile pour l'utilisateur, mais consommateur de batterie : à utiliser, donc, avec intelligence. :-)

Windows Phone 7 donne accès par l'intermédiaire des API media à la bibliothèque de musique, de vidéos et d'image mais également au tuner FM. Les codecs sont accélérés en hardware, ce qui permet de soulager le CPU et d'optimiser la consommation de batterie. Deepzoom et SmoothStreaming sont supportés et du côté du support DRM, on retrouve WMDRM et PlayReady. La liste des codecs supportés est disponible à la page suivante : http://msdn.microsoft.com/en-us/library/ff462087(VS.92).aspx.

Il est également possible avec Windows Phone 7 d'accéder à la caméra, la liste de contact, et de nombreuses fonctions du terminal. Cet accès se fait de deux manières différentes, en fonction de la tâche qu'on cherche à accomplir : lancer une fonction du téléphone (launcher), ou choisir dans une liste afin de remplir un champ de notre application (chooser). Un exemple simple :

• Je veux lancer l'application SMS ou le dialer (en mode « fire & forget ») c'est un launcher.
• Je veux prendre une photo puis revenir à l'application, ou charger l'email d'un contact dans mon application en le choisissant dans le répertoire, c'est un chooser.

Voici un tableau listant les launchers et choosers disponibles :

Le kit de développement donne également accès aux API pour contrôler la lecture de musique : ce sont des API héritées du Zune. Cela permet de lire de la musique stockée sur le téléphone par exemple pendant que l'utilisateur joue à un jeu. Ces API sont exposées dans XNA, mais seront également accessibles depuis Silverlight. Elles contrôlent le player natif du téléphone qui tourne en tâche de fond, donc pas besoin de se compliquer la vie à gérer un thread pour ça dans l'application par exemple. L'autre avantage que cela présente est que cela rend la lecture de la musique indépendante de l'application.

Enfin, une autre fonction du téléphone, le browser, peut être inclue directement dans un contrôle de votre application. C'est le contrôle WebBrowser, hérité de Silverlight 4. L'avantage de ce contrôle est qu'il permet des interactions entre les scripts de la page web que l'on charge et votre application en Silverlight : cela peut donner lieu à des scénarios d'interfaces graphiques mixtes Silverlight/HTML riches.

Windows Phone 7 va proposer un framework de géolocalisation complet qui aidera le développeur à proposer la meilleure expérience possible à l'utilisateur. Différents moyens de localisation géographique existent sur un téléphone, avec toujours un compromis entre précision et rapidité de réponse. Il y a 3 niveaux :

• Localisation par l'identifiant de la tour cellulaire : très rapide, mais peu précis : l'erreur peut atteindre 1km ! Néanmoins suffisant pour montrer une carte vue de haut ou un plan de quartier par exemple ;
• Localisation par réseau wifi et triangulation : rapide, et nettement plus précis, mais sujet à l'imprécision de la base de données des points d'accès géolocalisés : une localisation à quelque dizaines de mettre près, mais dont la précision varie en fonction du quartier. C'est une bonne solution pour la localisation en intérieur, quand il n'y a pas de couverture GPS par exemple ;
• Localisation par GPS : précision maximale, à quelque mètres près, mais lente, car il faut parfois attendre le « temps de fix » qui peut aller jusqu'à une minute. Heureusement les Windows Phone 7 sont tous équipé d'A-GPS (A pour « Assisted ») qui utilise une base connue de coordonnées de stations fixes au sol et de la position des satellites pour réduire le temps de fix à quelques secondes.

Pour simplifier la vie du développeur sur cet aspect essentiel de bon nombre d'applications, Windows Phone 7 propose une API unifiée pour accéder aux données de localisation et s'abonner à l'événement qui signale un changement de localisation, en lui permettant de spécifier la précision désirée.

En plus de ça, le service de localisation est couplé à Bing et au Cloud pour proposer des services comme de la résolution d'adresse (et de la résolution d'adresse inversée).

Un service de notification permet d'émuler, dans une certaine mesure, un comportement multitâche. Le principe est le suivant : plutôt que de laisser une application en background à l'écoute d'un événement extérieur, le système autorise l'application à enregistrer une « notification », qui avertira l'utilisateur de l'événement s'il se produit, et éventuellement permettra de relancer l'application afin de la traiter.

On retrouve plusieurs types de notification en push, notamment les notifications qui vont mettre à jour les « Tiles » de la page d'accueil, mais également les notifications qui apparaitront en surimpression sur l'écran (les « Toasts »). Dans les deux cas, l'architecture pour pousser ces notifications est la même :

• L'application enregistre une notification et obtient une URI qu'elle peut enregistrer auprès de son serveur. Elle peut à ce moment-là passer en pause, voire s'arrêter ;
• Quand le serveur doit réveiller l'application il envoie cette URI au serveur Microsoft qui pousse ces notifications vers les terminaux. Il est possible à ce moment-là de spécifier une priorité pour cette notification, qui conditionnera, toujours en mode « best effort », l'envoi de cette notification vers le terminal ;
• Le serveur Microsoft pousse la notification vers le terminal, qui l'affiche, offrant à l'utilisateur le choix de la traiter ou de la laisser passer.

Ce système oblige donc à passer par un serveur Microsoft pour joindre le téléphone, ce qui garantit la sécurité du canal vers ce dernier.

Il sera possible pour le développeur d'accéder à un certain nombre de fonctionnalités du Xbox Live depuis des jeux en XNA pour Windows Phone. Récupérer l'image de l'avatar et le profil du joueur, notamment, mais aussi accéder aux succès (achievements) et au système de points qui y sont associés. Pour le moment et pour maintenir la cohérence dans le comptage des scores et des achievements, chaque jeu sera limité à 20 achievements et 200 points.

Si on regarde le système et la plateforme applicative dans son intégralité, on comprend ce qui a motivé son architecture :

• Pour l'utilisateur, une homogénéité, et une intégration intelligente des applications dans les différents usages qu'il a de son téléphone. Avec Windows Phone 7, c'est avant tout l'utilisateur qui est au centre de toutes les attentions, qu'elles soient de la part de Microsoft, des opérateurs, des fabricants de téléphones ou des développeurs d'applications tierces.
• Pour le développeur, simplicité et rapidité de développement. Les API sont intuitives, abstraient volontairement la complexité de certains traitement (comme la géolocalisation par exemple) et garantissent que quel que soit l'état du téléphone, il se comportera correctement, c'est-à-dire de façon fiable et prévisible, ce qui est la garantie de la meilleure expérience possible pour l'utilisateur.

Nombre de ces API ne sont pas accessibles dans la CTP : elles arriveront petit à petit avec les différentes versions du SDK et au fur et à mesure que l'émulateur progressera, afin d'atteindre la maturité au plus vite, et avant le lancement sur le marché des Windows Phone 7.