développement application mobile sous Windows Phone 7

Avec l’arrivée de l’iPhone en 2007, Apple a fait exploser le marché des smartphones pour un usage grand public. Voyant le potentiel publicitaire que représentait ce nouvel usage, Google a proposé son propre système d’exploitation pour smartphone, Android, avec une philosophie opposée (code source disponible et système plus ouvert avec plus de fonctionnalités). Le premier modèle se vend fin 2008, presque un an après son annonce, aux États-Unis, sous le nom de HTC G1. Il faudra cependant attendre l’année 2010 pour voir s’envoler le système de Google et le voir prendre la tête des ventes. Fin 2010, un nouvel OS pour smartphones Estampillé Microsoft, Windows Phone 7, voit finalement le jour, après deux années de développement. Depuis 2007 Microsoft n’avait proposé qu’une nouvelle version de Windows Mobile (la 6.5), plus adaptée à un public professionnel. Avec Windows Phone 7, Microsoft propose enfin un système orienté grand public qui est donc directement en concurrence avec iOS et Android. Nous consacrons cet article à une présentation succincte du système ainsi qu’à une introduction au développement pour cette plateforme.

1. Présentation de Windows Phone 7

Avec WP7, Microsoft a choisi de proposer une interface se démarquant de ses deux principaux rivaux (Android et iOS). C’est ainsi qu’avec son interface nommée “Metro”, WP7 dispose d’une interface épurée, fluide et simple d’utilisation. Elle met l’accent sur la typographie et l’iconographie. L’interface Metro repose principalement sur deux principes, les “Tiles” et les “Hubs” :

- Les tiles (ou carreaux) qui composent l’écran d’accueil. Il s’agit de carrés animés qui peuvent se mettre à jour en temps réel. Le tile “Messages”, par exemple, affiche le nombre de SMS non lus. Les tiles présents sur l’écran d’accueil ainsi que leur ordonnancement est au choix de l’utilisateur. La figure 1 est un exemple de ce à quoi ressemble la page d’accueil des Windows Phone par défaut.

Figure 1. Écran d’accueil

- Les hubs (concentrateurs, ou lieux d’échange). L’interface Metro met également en valeur les hubs qui sont centrés sur l’information et le contenu, plutôt que sur l’application. A un hub correspond un univers thématique. On y retrouve ainsi regroupés de manière cohérente les applications, services et contenus présents sur le smartphone. Par exemple, le hub “contacts” (voir figure 2) regroupe pour une même personne les informations issues du répertoire téléphonique mais aussi de Facebook et de Windows Live.

Figure 2. Hub Contacts

Sur l’onglet “quoi de neuf”, on peut ainsi voir rassemblées les dernières nouvelles des contacts diffusés sur différents flux (Facebook et Windows Live). Pour le moment les types de comptes différents pour les contacts sont limités, mais Linkedin et Twitter notamment devraient être de la partie avec la prochaine version du système.

Par défaut, Microsoft propose 6 hubs : Contacts, Images, Jeux, Musique + Vidéo, Market Place et Office (Voir un aperçu en figure 3). Le hub Office représente d’ailleurs un gros avantage pour les utilisateurs d’Office sous Windows : il permet en effet d’afficher, de partager et même d’éditer des documents.

Figure 3. Différents hubs proposés sur les Windows Phone

Avec WP7, Microsoft propose un nouvel OS et non une nouvelle version de Windows Mobile. Les deux systèmes ne sont d’ailleurs pas compatibles. Les premiers téléphones tournant sous WP7 ont été commercialisés fin 2010. Au niveau du matériel, les pré-requis sont très précis pour faire tourner WP7 et très axés haut de gamme, de façon à proposer la meilleure expérience utilisateur possible. En contre partie, cela cantonne les WP (Windows Phone) aux parts de marché haut de gamme, en concurrence directe avec l’iPhone et les Android haut de gamme qui ont l’avantage de proposer plus de fonctionnalités et/ou d’applications. Ces prérequis extrêmement précis expliquent un faible nombre de modèles disponibles à la vente et font également que les premiers fabriquants, HTC, Samsung et LG, proposent peu ou prou le même téléphone. Dans ce contexte, il est difficile de se démarquer de ses concurrents.

Observons de façon plus détaillée la prise en main de WP7 par un utilisateur, et les particularités pour le développeur.

1. a. WP7 pour les utilisateurs

La jeunesse de WP7 se ressent rapidement au niveau des applications proposées et des fonctionnalités offertes aux utilisateurs. L’utilisation est très “contrôlée”, à l’image de ce que l’on trouve sous iOS. Par exemple, la synchronisation du contenu multimédia avec son ordinateur passe obligatoirement par “Zune”, un logiciel développé par Microsoft qui s’apparente à l’iTunes d’Apple (voir figure 4). Il n’est pas possible d’utiliser son Windows Phone à la façon d’un périphérique de stockage USB, comme il est par exemple possible de le faire avec Android ou Blackberry.

Figure 4. Zune

De la même façon, l’installation d’applications passe obligatoirement par le “Market Place”, équivalent de l’Apple Store. Il n’est pas possible d’installer une application téléchargée sur internet comme on le fait avec son ordinateur ou son téléphone sous Android, tout comme il n’est pas possible d’utiliser un magasin d’applications alternatif.

Hormis l’interface et le système innovant de hubs, il n’y a pas de réelles nouveautés par rapport à la concurrence. Sur bien des points, la comparaison est d’ailleurs en défaveur du WP, souvent à cause de la jeunesse du système. Ce qui entâche le plus l’expérience utilisateur est l’abscence du multi-tâches. Sur WP, il n’est en effet pas possible de surfer tout en continuant à recevoir les messages de ses contacts MSN. Lorsqu’on passe de Messenger à Internet Explorer, Messenger ne bascule pas en arrière plan. Ce dernier est tout simplement fermé, et on se retrouve donc déconnecté de MSN. Le multi-tâches existe pourtant, mais uniquement pour les applications système. Deuxième point négatif, crucial pour l’utilisateur et plaçant WP7 en deçà de ses deux principaux concurrents : le Market Place manque cruellement d’applications et les applications existantes sont souvent incomplètes ou de mauvaise qualité. Par exemple, Youtube n’est qu’une simple redirection vers le site mobile, Messenger by Miyowa est très bugué, on ne peut pas regrouper les mails par sujet, etc.

Ces points négatifs sont cependant à relativiser, car au delà des choix de restriction d’utilisation faits par Microsoft, les principaux défauts qui incombent à WP7 sont à mettre sur le compte de la jeunesse du système. Les plus grosses lacunes (multi-tâches, limitation des hubs, …) devraient d’ailleurs en partie être comblées à l’occasion de la diffusion de la prochaine version du système : WP7.1 MANGO . Cette nouvelle version n’est malheureusement pas attendue avant l’automne 2011. Notons par ailleurs qu’il est souhaitable que Microsoft ait revu son système de mise à jour des téléphones pour éviter de reproduire les couacs rencontrés avec les premières mises à jour mineures, avec notamment des téléphones rendus HS .

1. b. WP7 pour les développeurs

Pour les développeurs, le constat est plus positif. Il reste cependant les limitations imposées par Microsoft pour la mise à disposition des applications, qui sont d’ailleurs en grande partie les mêmes que pour le système d’Apple :

• comme vu précédemment, les applications doivent obligatoirement être publiées depuis le Market Place : les magasins d’applications alternatifs ne sont pas autorisés
• la mise à disposition directe sur un site internet n’est pas possible non plus

=> le développeur doit obligatoirement se créer un compte développeur et payer un abonnement annuel pour pouvoir publier des applications… et même simplement les utiliser sur son propre téléphone !

Autres points négatifs, les fonctionnalités laissées accessibles au développeur :

• pas de multi-tâches
• pas de services en arrière plan
• pas d’équivalent au système d’intent d’Android pour la communication entre applications
• pas de possibilité de surcharger les applications système : il est par exemple impossible de modifier l’interface du système

Au niveau des revenus générés par la vente des applications, le taux pratiqué est le même que pour les principaux concurrents, à savoir 30% pour Microsoft et 70% pour le développeur. Le prix minimum d’une application est de 0,99 dollars US (ce qui est plus élevé que chez les concurrents).

Là où Microsoft tire son épingle du jeu, c’est ce qui concerne les outils proposés pour le développement : ceux-ci sont complets et leur prise en main est aisée. Ce sera d’ailleurs approfondi dans un prochain article. Pour résumer, le développement se fait avec Silverlight pour les applications classiques ou XNA pour les jeux, tous deux étant exécutés sur le téléphone par .NET Compact Framework (environnement d’éxécution de code managé .Net pour appareil mobile). Les outils sont les mêmes que pour les autres types d’applications .Net : il s’agit de Visual Studio pour le développement et de Expression Blend pour les interfaces graphiques. Microsoft propose également un émulateur pour le débogage.

2. Développement d’applications : prérequis et première application

Le développement d’applications pour Windows Phone 7 requiert :

• Un ordinateur sous Windows 7 ou Windows Vista
• L’installation de Visual Studio Express 2010 for Windows Phone Development (version gratuite) ou de Visual Studio 2010 Pro avec les outils pour le développement Windows Phone 7 (version payante, plus complète). L’installation de ces outils est anormalement longue, problème malheureusement récurrent avec l’installation des outils de Microsoft.

Pour les développeurs qui ne le connaissent pas encore, Visual Studio est un IDE (atelier de développement intégré) simple à prendre en main et complet qui intègre de plus un outil d’édition graphique pour simplifier la phase de design des interfaces des différents types d’applications (Web, Windows, WP7…). On y retrouve les outils habituels des IDE évolués, permettant un débogage simple des applications, et un développement rapide (intellisence, immediate windows, snippets, …). La figure 5 offre un aperçu de l’interface de Visual Studio Express 2010, la version gratuite de Visual Studio.

Figure 5. Visual Studio Express 2010

Avant de présenter quelques spécificités du développement WP7, nous allons créer notre première application et regarder sa composition. Comme pour les autres types de solution (une solution dans Visual Studio correspond à un groupe de projets d’un même domaine), Microsoft propose un “template” de solution de type WP7 (une application de type “Hello World”). Une fois la solution générée, la première page de l’application, nommée “MainPage.xaml”, est ouverte dans l’éditeur comme le montre la figure 6. Les propriétés de la page et de ses objets peuvent être édités :

1. de façon graphique,
2. à l’aide de la fenêtre de propriétés
3. ou directement en éditant à la main le fichier “.xaml” ou “.xaml.cs” associé

Figure 6. Page principale de l’application vue dans l’éditeur de Visual Studio

L’application, bien que n’ayant aucune fonctionnalité à l’heure actuelle, peut d’ores et déjà être testée dans l’émulateur. Il suffit pour cela de lancer le mode debug par un simple appui sur la touche “F5”. La compilation débute et l’émulateur est chargé. L’application se lance automatiquement, le résultat est reproduit en figure 7. Il est alors possible de la tester et de la déboguer.

Figure 7. La première page de l’application qui s’exécute dans l’émulateur

Par défaut, la cible utilisée pour le déploiement est l’émulateur, comme le montre la figure 8, mais il est possible d’utiliser un Windows Phone. Pour cela, il faut malheureusement que le smartphone soit enregistré en tant que téléphone de développeur, c’est à dire qu’il faut un compte de développeur et un abonnement au Market Place en cours de validité. Impossible donc de tester ses applications sur son propre téléphone sans dépenser pour cela 100 dollars US, soit environ 70 euros, par an.

Figure 8. Cible de déploiement de l’application

L’émulateur permet de simuler un certain nombre de fonctionnalités des Windows Phone. On peut par exemple passer du mode portrait au mode paysage (boutons à droite de l’émulateur), et simuler des clics sur les différents boutons tactiles du téléphone (au bas de l’émulateur). Ces fonctionnalités sont visibles sur la figure 9.

Figure 9. Les boutons de l’émulateur

La prise en main de ces outils est simple, nous allons maintenant nous attarder plus particulièrement sur les premiers pas et les spécificités du développement sous Windows Phone 7 par rapport aux applications Web ou aux applications Windows classiques.

3. Les fichiers d’un projet WP7

Lors de la création de la solution par défaut, un certain nombre de fichiers ont été placés dans l’application. On retrouve les images de l’application (“ApplicationIcon.png”, “Background.png” et “SplashScreenImage.jpg”), ainsi que deux fichiers “.xaml” avec leur code behind (correspond dans les projets .Net Silverlight au traitement associé aux objets de l’interface utilisateur) associé : un pour l’application (“App.xaml” qui contient principalement l’initialisation de l’application) et un pour la page d’accueil (“MainPage.xaml”, unique page de l’application lors de sa création). Le fichier “.xaml” contient la description de la page (la partie graphique), et le fichier “.xaml.cs” associé contient toute la logique de l’application, l’implémentation des actions associées aux différents évènements. Nous détaillons le fonctionnement des pages sous WP7 dans la section consacrée à Silverlight.

Contrairement à Android, il n’y a pas d’arborescence prédéfinie pour le projet. Les ressources par exemple (images, …) sont placées à la racine dans le projet template comme représenté en figure 10. Le développeur choisit donc l’arborescence qui lui sied, mais on se repère en contrepartie un peu moins facilement dans une application que l’on ne connait pas.

Figure 10. Les fichiers de la solution WP7 par défaut

Dans cette première partie, nous avons découvert l’interface de Windows Phone 7 ainsi que les outils proposés aux développeurs pour la réalisation d’applications. Nous avons créé un projet “type” Windows Phone 7 que nous avons lancé en mode “debug” dans l’émulateur, et nous avons découvert les différents fichiers entrant dans la composition du projet. La suite de cet article sera bientôt mise en ligne et permettra de présenter Silverlight pour Windows Phone 7 de façon à pouvoir se lancer dans le développement de ses propres applications. Stay tuned

4. Principes de programmation

Le développement des applications s’effectue en Silverlight, ou XNA suivant qu’il s’agisse d’applications standards ou de jeux. Les APIs XNA sont d’ailleurs celles utilisées pour développer des jeux pour Zune, Windows et XBox 360, mais nous n’aborderons pas l’utilisation de XNA dans cet article.

La conception des interfaces peut en partie s’effectuer graphiquement depuis l’éditeur de Visual Studio ou avec un outil dédié : Expression Blend. Pour peaufiner le tout, il est bien sûr possible d’éditer les fichiers “.xaml” à la main.

Pour voir son application publiée sur le Market Place, le développeur doit respecter un certain nombre de contraintes. Notons par exemple que le code non managé (code directement exécuté par le processeur par opposition au code managé, exécuté sous le contrôle de la machine virtuelle) n’est pas autorisé. Pour toutes les informations relatives aux points à respecter pour publier sur le market place, ne pas hésiter à consulter le site officiel.

La suite de cette section est consacrée à Silverlight pour WP7 ainsi qu’au fonctionnement des pages XAML.

4. a. Silverlight

A la base, Silverlight est un framework basé sur WPF (Windows Presentation Foundation) permettant de développer des applications Web riches. C’est en quelque sorte une version simplifiée de WPF, qui s’exécute directement dans un navigateur (moyennant l’installation d’un plugin embarquant l’environnement d’exécution). WPF propose aux développeurs des APIs permettant d’utiliser toute la puissance de la carte graphique pour dessiner des interfaces graphiques à forte valeur ajoutée et proposer aux utilisateurs un meilleur rendu. WPF et donc Silverlight permettent de séparer la partie graphique de l’application de la partie contenu. Pour la conception de l’interface, c’est XAML qui est utilisé, celui-ci s’apparentant à un HTML aux possiblités accrues. Nous le présentons brièvement dans la section suivante. Pour la partie développement, C# comme VB peuvent être choisis. Microsoft propose une documentation complète en ligne.

Microsoft a choisi d’utiliser Silverlight pour le développement des applications sur Windows Phone. On peut donc par exemple utiliser l’objet “WebClient” pour gérer les appels de l’application à un serveur Web. Pour s’adapter à cette nouvelle plateforme, Silverlight dispose de quelques ajouts par rapport à la version Windows, lui permettant de gérer le matériel des Windows Phone et les particularités logicielles. Cela concerne entre autres :

• l’appareil photo
• l’accéléromètre
• le GPS
• la vibration
• la radio FM
• l’écran tactile
• les notifications
• …

Il permet également de :

• gérer la navigation au sein de l’application (naviguer entre les pages de l’application)
• transférer des données d’une page à une autre
• sauvegarder l’état d’une page (PhoneApplicationService)
• etc.

Les différences entre Silverlight pour Windows et Silverlight pour Windows Phone sont listées dans l’aide en ligne de Microsoft.

Une application WP7 est découpée en pages, composées de différents contrôles (ou objets graphiques), avec lesquels l’utilisateur interagit. Ce dernier déclenche différents évènements qu’utilise le développeur pour définir le comportement de l’application. Il s’agit d’une programmation dite évènementielle. Comme pour un développement Web ASP .Net, chaque page est représentée par deux fichiers dans la solution, pour la séparation entre l’interface de l’application et le contenu :

• NomDeLaPage.xaml : pour l’interface graphique principalement, codé en XAML
• NomDeLaPage.xaml.cs (ou NomDeLaPage.xaml.vb) : appelé Code Behind, pour la logique de l’application, codé en C# (ou en VB), et qui fait appel aux différentes APIs proposées par Silverlight

Remarque : dans un souci de simplification de lecture, dans le présent article, nous ne présentons que la version C# pour le Code Behind, sachant que les deux technologies C# et VB sont proposées au choix pour le développeur.

4. b. XAML

Comme nous l’avons déjà évoqué brièvement, les pages qui composent une application WP7 sont décrites dans des fichiers XML écrits en XAML (eXtensible Application Markup Language), semblables aux vues Android en de nombreux points. Un fichier XAML permet donc de décrire l’apparence générale de la page et des contrôles qui la composent, mais pas seulement. En effet, XAML permet aussi aux développeurs d’effectuer des opérations supplémentaires comme l’ajout d’animations, le Data Binding (association entre contrôles et données), … qui sont autant de fonctions en moins à implémenter.

Le code C# lié à la page a directement accès aux éléments de la page XAML associée. Il n’y a rien de spécial à écrire pour lier une page XAML à son fichier C# associé. La page est en réalité une seule classe partielle partagée entre les deux fichiers :

• le .xaml :

<phone:PhoneApplicationPage

   x:Class="MonApplication.MainPage"
       ...  

</phone:PhoneApplicationPage>

• et son Code Behind associé (le .xaml.cs) :

namespace MonApplication
{

   public partial class MainPage : PhoneApplicationPage
   {
       ...
   }

}

Avec ces principes en tête, nous pouvons présenter de façon très intuitive un exemple succinct d’utilisation de ces outils pour l’ajout d’un contrôle (objet graphique) et d’un handler (intercepteur) sur un évènement.

4. c. Les premiers pas en tant que développeur WP7

Les premiers pas dans le développement d’une application WP7 sont simples même si l’on ne connaît pas encore les technologies Microsoft car Visual Studio nous simplifie la vie. De plus, Internet regorge de tutoriels et de documentations. Tout comme pour les applications WebForms ou WPF, on peut placer les différents composants de l’interface de l’application via un éditeur graphique et générer automatiquement les stubs de méthodes (méthodes provisoires permettant d’avancer dans le développement avant d’avoir codé leur contenu) à exécuter lors de la levée des évènements voulus.

Voici un exemple simple d’ajout d’un bouton et de génération du stub de la méthode à exécuter lors du clic de celui-ci :

1. Le choix du contrôle se fait dans la boite à outils (cf. figure 11).

Figure 11. Boîte à outils – rassemble les contrôles disponibles pour les pages

2. Son placement dans la page XAML étant alors simplement effectué par un glisser-déposer (cf. figure 12).

‘Figure 12. Placement d’un bouton dans la page »

3. Le code XAML est automatiquement modifié en conséquence, on y retrouve notre contrôle nouvellement ajouté :

<Button Content="Button" Height="72" HorizontalAlignment="Left" Margin="281,138,0,0" Name="button1" VerticalAlignment="Top" Width="160" />

4. Une fois le contrôle placé, on se lie à l’évènement souhaité grâce à la fenêtre “Propriétés” (cf. figure 13).

Figure 13. Fenêtre des propriétés du bouton

5. Sur l’onglet “Évènements”, on double clique sur l’évènement souhaité pour générer le stub de la méthode qui sera exécutée lors de la levée de l’évènement :

.xaml.cs :

   private void button1_Click(object sender, RoutedEventArgs e)
   {
    
   }

.xaml :

   <Button Content="Button" Height="72" HorizontalAlignment="Left"
   Margin="281,138,0,0" Name="button1" VerticalAlignment="Top"         Width="160"
   Click="button1_Click" />

6. Il ne reste alors que le principal à faire… à savoir implémenter l’action souhaitée lors du clic sur le bouton ! Et là encore la tâche est simplifiée, grâce à l’Intellisense (complétion de code), aux snippets (génération automatique de squelettes de code), etc…

Pour une plus grande souplesse, on peut bien sûr éditer tous les fichiers manuellement. Même si le principe derrière WPF et donc Silverlight est de séparer la présentation de la page de la partie code, tout peut être fait dans le code behind en C#, y compris la conception de l’interface graphique de l’application.

Cet exemple très basique nous a permis de présenter l’utilisation de Visual Studio pour créer simplement les pages de son application et générer les stubs des handlers qui nous intéressent. Pour les informations concernant les différentes APIs de Silverlight permettant l’utilisation de toutes les capacités des Windows Phone, il est possible de se référer :

• à la documentation en ligne de Microsoft
• aux forums

Un dernier point, la réalisation d’une application complexe ne peut bien sûr pas se faire en plaçant toute la logique du fonctionnement dans le code behind des pages. Il faut créer les librairies nécessaires et les faire communiquer avec les pages du projet Silverlight. Pour un modèle de développement adapté aux applications Silverlight, on peut se documenter sur le pattern MVVM en commençant par exemple par la visite de ce site : http://www.galasoft.ch/mvvm.

4. d. Expression Blend et la conception graphique de l’application

L’élément principal de l’application, qui peut faire son succès ou provoquer son échec, est certainement l’expérience utilisateur avec en première ligne l’interface graphique. Microsoft a bien compris ce point, et propose l’outil de conception d’interface graphique Expression Blend.

Figure 14. Une page XAML vue dans l’éditeur d’interface, Microsoft Expression Blend

Plus complet que l’éditeur graphique dans Visual Studio, Expression Blend permet de se concentrer sur la conception de l’interface de l’application. Il n’est cependant pas nécessaire de lancer Visual Studio en parallèle si l’on souhaite ajouter un évènement, implémenter une méthode, ou simplement consulter le code C#. Expression Blend permet en effet de faire tout ceci. Il est même possible de déployer l’application vers l’émulateur (ou un téléphone de développeur). Le point négatif d’Expression Blend est le nombre de menus / onglets / composants présents à l’écran : il faut cliquer partout. Les adeptes de Notepad et de la ligne de commande préféreront s’en passer. Expression blend est donc plus particulièrement destiné aux designers qui n’ont pas nécessairement d’expérience en programmation. Il permet en effet une séparation plus aisée entre le travail du développeur et celui du concepteur de l’interface utilisateur.

Conjointement à Expression Blend, Microsoft propose un certain nombre de normes à respecter pour une conception cohérente d’interfaces d’applications WP7 . En effet le développement pour mobiles impose quelques particularités au niveau de l’interface. Il ne faut pas oublier par exemple que le téléphone peut être tenu horizontalement comme verticalement, ce qui impose deux vues différentes pour une même application.

5. Persistance des données

Dans une application, la persistance des données est un élément clé. Elle permet de conserver la configuration de l’application ainsi que les données de l’utilisateur d’une exécution à l’autre de l’application.

Contrairement à Windows Mobile ou Android, les applications sous Windows Phone 7 n’ont pas un accès direct au système de fichiers. A l’instar de Silverlight sous Windows, il faut passer par l’Isolated Storage. Chaque application dispose de son espace de stockage individuel, ce qui rend impossible par ce biais le partage des informations entre différentes applications.

Toute la gestion de la persistance se trouve dans le namespace “System.IO.IsolatedStorage”

La classe IsolatedStorageFile s’utilise comme la classe File du framework .Net, tandis que la classe IsolatedStorageFileStream s’utilise comme la classe FileStream. On retrouve donc, mais cantonné à un espace reservé à l’application, la possibilité de vérifier la présence de fichiers ou de répertoires, de supprimer, d’ajouter ou de modifier des fichiers.

Pour ce qui est du cas particulier de la sauvegarde de la configuration de l’application, on peut utiliser l’ IsolatedStorageSettings qui est en fait tout simplement un dictionnaire stocké sur l’IsolatedStorage. La clé est une chaîne de caractères au choix, et la valeur est l’objet à mémoriser :

Exemple : IsolatedStorageSettings.ApplicationSettings["Clé"] = Objet;

A l’heure actuelle, l’IsolatedStorage est la seule solution de stockage d’information directement sur le téléphone. Il n’y a pas pour l’instant de version WP7 de SQL Compact Edition, version allégée de SQL Server disponible sur Windows Mobile.

6. Conclusion

Actuellement, WP7 souffre de sa jeunesse et de la concurrence directe avec iOS et Android. La faible quantité de téléphones proposés ainsi que le manque d’applications et de fonctionnalités l’empêche pour le moment de briller au combat. Cependant, ce nouveau système propose une interface originale et le principe des hubs permet de mettre en avant le contenu sans être obligé de lancer plusieurs applications. L’interface est pensée pour gagner du temps et avec la mise à jour de son système prévue pour l’automne 2011, le retard devrait se combler sérieusement par rapport à ses concurrents. De plus, l’intégration parfaite avec Visual Studio (Designer et Emulateur) et la facilité de prise en main de Silverlight fait de WP7 une plateforme alléchante pour les développeurs. Autre atout, Nokia a choisi d’abandonner Symbian au profit de WP7 comme système d’exploitation pour ses smartphones, et le premier téléphone WP7 estampillé “Nokia” devrait être proposé à la vente cet automne. Ceci devrait augmenter considérablement à court terme les parts de marché de l’OS de Microsoft. Par contre, s’il souhaite convaincre et revenir dans la bataille, Microsoft n’a plus le droit à l’erreur. Ceci est d’autant plus vrai que le géant de Redmond n’est pas encore présent sur un nouveau marché en plein essor, où Apple mène encore la danse pour le moment, et où Android aimerait se tailler une part du gâteau : le marché des Ardoises (oui, nous aussi, on préférait le terme “Tablette”) !

Avantages :

• Interface épurée, agréable et réactive
• Système original des hubs
• Les outils proposés au développeur (Expression Blend et Visual Studio 2010 : Emulateur, Designer, Debogueur)
• La stratégie future de Nokia axée sur Windows Phone

Inconvénients :

• Pas de multitâches à ce jour
• Manque d’applications
• Mises à jour laborieuses et nécessitant la connexion à un ordinateur (et l’utilisation de Zune)
• Des restrictions qui cumulées deviennent pesantes (pas de debug sur téléphone sans payer, obligation d’utiliser Zune pour la synchronisation, carte sim obligatoire pour démarrer le téléphone alors que seuls les appels et SMS devraient être impossibles sans carte…)