Embed Size (px)
Citation preview
Cahier de vacances – Windows Phone 7
1
Sommaire
1 Introduction .......................................................................................................................... 2
2 Les guides pour les développeurs ........................................................................................ 2
3 Comprendre la plateforme .................................................................................................... 3
3.1 Le Hardware.................................................................................................................. 3
3.2 Le système d'exploitation .............................................................................................. 4
3.3 Le cycle de vie d'une application sur le terminal ............................................................ 5
3.4 Le mode "version d'essai" d'une application .................................................................. 6
3.5 Les concepts de l’interface utilisateur et les différents états d’une application ............... 7
3.6 Les interactions avec le reste du système et avec le cloud ............................................ 8
3.7 Le stockage local ou Isolated Storage ........................................................................... 9
3.8 Les capteurs et le vibreur .............................................................................................. 9
3.9 Les fonctionnalités multimédia ...................................................................................... 9
3.10 Les interactions avec les applications natives du téléphone .......................................... 9
3.11 Les interactions avec les applications natives du téléphone ........................................ 10
3.12 La géolocalisation ....................................................................................................... 10
3.13 Les notifications en push ............................................................................................. 11
3.14 Les services du Xbox Live (Gamer Services) .............................................................. 12
3.15 Conclusion .................................................................................................................. 12
4 Développer pour Windows Phone 7 ................................................................................... 12
5 Les ressources indispensables ........................................................................................... 13
5.1 Silverlight .................................................................................................................... 13
5.2 XNA ............................................................................................................................ 13
6 Liens utiles ......................................................................................................................... 13
1 Introduction Windows Phone 7 repense entièrement la manière dont on interagit avec son téléphone et
propose une expérience utilisateur unique, naturelle et fluide.
La plateforme applicative Windows Phone 7 ouvre la porte à :
Des applications et des jeux fantastiques. Utilisez les Frameworks Silverlight et XNA
pour concevoir des applications et jeux interactifs de haute-qualité pour les téléphones
Windows Phone 7. (Avec XNA Game Studio 4.0, il est possible de créer un jeu pour
Windows Phone 7, Windows 7 et Xbox 360)
Des applications rapides et incroyablement riches. La combinaison de Visual Studio
2010 et Expression Blend avec les spécifications matérielles standards Windows Phone
7 permet de gagner du temps pour faire de la vision de chacun une réalité sur chaque
téléphone.
Plus d’opportunités et de partenariats. Concevez des applications et des jeux
innovants avec vos compétences actuelles et les outils disponibles pour Windows Phone
7, et touchez de nombreux clients, indépendamment du matériel qu'ils utilisent. Vous
n’avez pas à vous soucier des ventes et de la distribution, le Marketplace Windows
Phone s’en charge. Développez et recueillez-en les fruits !
2 Les guides pour les développeurs Vous voulez développer votre première application Windows Phone 7 mais vous ne savez pas
comment procéder ? Le mieux est de suivre le(s) guide(s) :
Comprendre la plateforme
Le but de cet article de référence est d’expliquer les concepts qui structurent Windows
Phone 7 et son SDK.
« Hello Windows Phone »
Apprenez pas-à-pas les bases du développement Windows Phone 7.
Créez votre premier jeu !
Apprendre à développer votre premier jeu pour Windows Phone 7 à l'aide du Framework
XNA, ça vous tente ?
Navigation et Contrôles
Cet atelier vise à présenter le système de rendu de Windows Phone et le système de
navigation, notamment les principes de base de la navigation entre les écrans (pages)
d’une application Silverlight pour Windows Phone.
Utiliser les notifications de type Push
3
Cet atelier introduit les notifications de type Push et l’utilisation de services HTTP dans
Silverlight.
Ci-dessous le guide pour comprendre la plateforme.
Pour plus d’information consultez les guides pour les développeurs
3 Comprendre la plateforme Avec Windows Phone 7, la plateforme applicative mobile de Microsoft a été remise à zéro. Cela
signifie une nouvelle manière d’aborder le hardware, mais aussi l’architecture logicielle de l’OS,
le modèle applicatif ainsi que la couche de présentation, et bien entendu l’intégration avec des
services “dans le cloud”. Quand on aborde le développement d’une application pour la
plateforme Windows Phone 7 il est important d’avoir bien compris toutes ces couches avant de
se lancer, afin de tirer le meilleur parti possible du téléphone. Le but de cet article est d’expliquer
les concepts qui structurent l’OS et le SDK.
3.1 Le Hardware
Avec Windows Phone 7, les fondations du hardware des téléphones seront les mêmes.
4
Les tripes :
Un processeur ARMv7 : Cortex, Scorpion, ou mieux
256Mo de RAM et 8 Go de RAM 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 !
3.2 Le système d'exploitation
5
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.
3.3 Le cycle de vie d'une application sur le terminal
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.
6
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).
3.4 Le mode "version d'essai" d'une application
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 » !
7
3.5 Les concepts de l’interface utilisateur et les différents états d’une
application
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.
8
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…
3.6 Les interactions avec le reste du système et avec le cloud
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.
9
3.7 Le stockage local ou Isolated Storage
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.
3.8 Les capteurs et le vibreur
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. :-)
3.9 Les fonctionnalités multimédia
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.
3.10 Les interactions avec les applications natives du téléphone
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),
10
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 :
Launchers Choosers
BingMapsTask CameraCaptureTask
MarketplaceLauncher EmailAddressChooserTask
MediaPlayerLauncher EmailComposeTask
PhoneCallTask PhotoChooserTask
SaveEmailAddressTask PhoneNumberChooserTask
SavePhoneNumberTask
SearchTask
SMSComposeTask
WebBrowserTask
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.
3.11 Les interactions avec les applications natives du téléphone
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.
3.12 La géolocalisation
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
11
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).
3.13 Les notifications en push
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 ;
12
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.
IMPORTANT : Il est prévu que les notifications soient distribuées en mode « best effort » : bien que l’infrastructure des serveurs Microsoft soit évidemment dimensionnée pour supporter la charge, il n’y a aucune garantie quant au temps de propagation de cette notification jusqu’au terminal (qui est par ailleurs soumise à d’autres contraintes comme par exemple la possibilité pour le terminal d’accéder à une connexion de données).
3.14 Les services du Xbox Live (Gamer Services)
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.
3.15 Conclusion
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.
4 Développer pour Windows Phone 7 Pour ceux qui n’ont jamais fait de développement Windows Phone mais qui connaissent déjà
Visual Studio ou le Framework .NET, commençons par un petit détail qui a son importance : vos
13
compétences actuelles vous permettront de réaliser très rapidement vos premières
applications mobiles. Si vous n’êtes pas familier de l’environnement .NET, pas de problème :
nous vous proposons des ressources techniques gratuites qui vous permettront, de manière
ludique et didactique, d’apprendre à développer en douceur pour la plateforme Windows
Phone 7.
5 Les ressources indispensables Pour aller plus loin
Les ressources clés fourmillent d’information immanquable et d’exemples concrets. Mais, pour
aller plus loin, vous aurez peut-être besoin d’exemples additionnels, de conseils d’experts pour
approfondir tel ou tel point, de tutoriaux, ou de trucs et astuces. La liste ci-dessus compile des
ressources en français de qualité, là encore 100 % gratuites. N’hésitez pas à me suggérer de
nouveaux articles.
5.1 Silverlight
Eléments d'ergonomie et de design de Windows Phone 7 : l'Application Bar (Pierre
Cauchois)
Le Framework de Navigation dans Windows Phone 7 (Pierre Cauchois)
Des contrôles Panorama de partout (Pierre Cauchois)
Mini-tutoriel : recréez en Silverlight le client Twitter basique de Scott Guthrie du MIX
2010 (David Rousset)
Deux manières de simuler l'accéléromètre dans l'émulateur (Pierre Cauchois)
Multithreading et traitement des événements Pause et Resume dans une application
(Pierre Cauchois)
5.2 XNA
Portage du Platformer Starter Kit XNA 3.1 vers XNA 4.0 pour Windows Phone 7 (David
Rousset)
Trucs et astuces pour le développement XNA sur Windows Phone 7 (XNA-France)
6 Liens utiles Téléchargement :
Windows Phone 7 developer tools
14
Ressources :
Comprendre la plateforme
Les guides pour les développeurs
ReMIX 2010 - « Développer pour Windows Phone 7 »
Pour voir plus d’articles, d’astuces ou de vidéos
Vous êtes anglophone ?
Si la langue de Shakespeare ne représente pas un obstacle pour vous, voici quelques
ressources supplémentaires que nous vous recommandons de consulter.
Training Kit Windows Phone 7
Exemples de codes
Windows Phone 7 Panorama & Pivot Control (par Stéphane Crozatier)
Les vidéos et les slides du MIX 2010
Preview du livre de Charles Petzold sur le développement pour Windows Phone 7
Vue d’ensemble de la plateforme
Des experts, pour vous
Toutes les ressources techniques que nous vous proposons ne seraient rien sans la
communauté d'experts qui oeuvrent tous les jours pour la plateforme Windows Phone et sont là
pour compléter les informations que nous délivrons régulièrement en vous proposant des
actualités et en répondant à vos questions sur les forums. Même si ces liens ne sont pas
exhaustifs, voici quelques liens utiles à ajouter à vos favoris :
Les forums MSDN : pour poser toutes les questions qui vous viennent à l'esprit et
échanger avec d'autres développeurs
Le blog de Pierre Cauchois, responsable des relations techniques avec les développeurs
CodePPC
