Ce vendredi, à la pause déjeuner, 13h30 – 14h, retrouvez moi pour un petit livemeeting de 20 minutes + 10 minutes de questions/réponses sur le thème des animations et des transitions. Ces dernières sont un point clef pour rendre votre application fluide aux yeux de l’utilisateur, le guider dans l’expérience, et c’est souvent un des détails qui font la différence entre une bonne et une excellente application.
Voici le lien pour s’inscrire et suivre l’évènement!
Pensez à être là 5 minutes en avance pour vérifier que la connectivité est bonne, il s’agit d’un livemeeting! et si vous ne pouvez être là, sachez que ce livemeeting sera webcasté, et accessible avec ce même lien!
Petite astuce qui gagne à être partagée évoquée lors d’une discussion avec David Catuhe ce matin : la possibilité de récupérer les stacktraces des crashes de votre application après l’avoir publiée (c’est à dire les crashes que subissent vos utilisateurs)! petit guide pour trouver cette fonctionnalité (un peu planquée, et en béta) de Marketplace.
Quand vous êtes loggés, accédez à votre dashboard Windows Phone 7
Dans le dashboard, il y a la case “App Highlights” dans lequel vous avez les downloads récents, ainsi que les crashs:
Et là, si vous cliquez sur le nom de l’application, ça vous emmène sur les détails (reviews, etc)…. mais si vous cliquez sur le nombre de crash vous arrivez sur un joli graph de reporting:
observez que vous avez un bouton en haut à droite, qui permet de télécharger un fichier excel avec les dernières stacktraces (c’est une fonctionnalité en beta)
Voici un exemple de crash report détaillé, avec la stack trace et la fonction qui pose problème
(bien entendu le bug qui cause ce crash a été créé uniquement dans le but d’écrire cet article, et pas du tout à cause d’une erreur de débutant dans le code de votre serviteur… )
Si vous voulez plus de détails, il faudra vous tourner vers une solution d’instrumentation plus précise, comme par exemple BugSense (petit article dessus de l’ami Fabien).
Voici les slides du Livemeeting d'u 20/12/2011, organisé dans le cadre de l’Accélérateur Windows Phone 7. Le webcast devrait être disponible rapidement, j’updaterai ce post quand ça sera le cas!
Le but de ce livemeeting était de fournir des trucs pratiques tout au long du cycle de développement d’une application, que ce soit des outils de mockup, des petits toolkits et des librairies à connaitre… le slide deck n’est pas bien long car il y a eu beaucoup de démonstrations sur Visual Studio 2010 et Expression Blend, mais vous retrouverez dedans tous les liens utiles.
A bientôt pour d’autres livemeeting dans le cadre de l’accélérateur!
Il y aura aux Techdays cette année une douzaine de sessions sur Windows Phone, la plus grande majorité concernant le développement d’applications. Le parcours va s’intéresser aux arguments qui font les “bonnes” applications… celles qui plaisent à leurs utilisateurs et qui se comportent particulièrement bien.
On va retrouver un mix de sujets “classiques”, comme l’analyse de performances, ou l’architecture et la communication d’une application avec un backend, et des sujets plus exotiques, sur des cas d’utilisations qui ont été ouverts avec Mango, comme la réalité augmentée, l’utilisation d’une base de donnée locale… Le but étant de pouvoir proposer aux nouveaux développeurs de connaitre dès le démarrage les bonnes pratiques de développement, et aux développeurs chevronnés de parfaire leur application ou leur art en partageant avec leurs pairs.
Le parcours n’oublie pas les clients “entreprise” dont les besoins en applications métiers vont croissant et qui, avec Windows Phone 7.5, ont maintenant la possibilité de créer et déployer des applications pour leurs collaborateurs.
Voici la liste des sessions:
Comme promis (bien qu’avec un peu de retard) voici les slides du Windows Phone 7.5 Design Day du 8 Novembre, au campus Microsoft. Une journée pendant laquelle Arturo Toledo (@arturot) et Corrina Black (@corrinab) sont venus présenter les méthodes et les outils de conception d’une expérience Windows Phone 7.5. Durant cette journée, nous avons accueilli plus de monde qui prévu, ce qui nous aura conduit à aménager une deuxième salle en parallèle pour la matinée, durant laquelle j’aurai présenté ce slide deck là, aussi sur Metro.
Merci beaucoup à tous d’être venus aussi nombreux, et sachez que nous allons annoncer très bientôt, pour début janvier, une autre journée sur le thème de l’ergonomie et du design!
Vous pouvez également retrouver un post d’Arturo sur son blog qui parle de son expérience pendant sa tournée d’Europe!
Les techdays commencent à pointer le bout de leur nez… dans l’équipe on y passe déjà beaucoup de temps. Une des tâches principales est l’organisation des parcours et des sessions dans chaque parcours (track).
Un parcours sur un sujet se doit d’être cohérent, et d’avoir un bon équilibre entre les sessions: sujets, niveau technique… L’an dernier par exemple, le parcours Windows Phone 7 concrétisait un retour d’expérience complet sur les différentes phases du développement d’une applications: bonnes pratiques pour démarrer, application du design Metro, collaboration avec les designers, industrialisation, optimisation des performances… à l’époque j’étais parti du principe que le SDK était mature, que les participants des Techdays y avaient déjà surement jeté un oeil, et qu’il fallait répondre non pas à des débutants, mais plutôt à des développeurs avec des problématiques concrètes sur des projets menés au quotidien. Priorité à la pratique, et au pragmatisme.
Cette année, cette expérience n’a fait qu’augmenter. Il faut donc hausser le niveau d’un cran, tout en proposant à la fois des sujets techniques de tous niveaux, sur les différentes parties du développement d’une application. L’idée du parcours de cette année sera donc “les plus belles applications”. Différentes, bluffantes, inspirantes… je souhaite que chaque développeur, indépendamment de son niveau et de son implication dans Windows Phone 7, ressorte de chacune des sessions auxquelles il assistera avec des étoiles dans les yeux et l’opinion que les applications sont plus belles sur Windows Phone 7 que n’importe où ailleurs.
Le portail de proposition des sessions est déjà ouvert, mais maintenant, vous savez quels seront les ingrédients des sessions qui feront leur chemin dans le parcours Windows Phone 7: n’hésitez donc pas à en proposer plein, et à me faire vos retour d’idées ou de “commandes de sessions” dans les commentaires!
Une petite info est en train de faire le tour de la toile des développeurs Windows Phone ce matin et je ne peux m’empêcher de la relayer, car la question sort assez souvent: il s’agit d’un feature documenté (j’insiste sur l’importance de chacun de ces deux mots) qui permet de passer le codage des couleurs de 16 à 32 bits quand une application en a besoin. Sans plus attendre, le truc:
<App xmlns="" BitsPerPixel="32" ...>
Dans le fichier WMAppManifest.xml de l’application (là ou il y a les capabilities, la définition des background agents etc) il y a une propriété BitsPerPixel de la balise App qui peut prendre les valeurs 16 ou 32 !
Cette fonctionnalité est documentée sur la page de doc qui concerne le manifest de l’application sur MSDN et est disponible uniquement dans Mango (Windows Phone 7.5).
Impacts? plus de “bandes” sur les gros aplats/dégradés de couleurs dans les photos et dans l’application (même si l’utilisation des dégradés est rarement “metro compliant”). Ca peut servir dans certains cas comme les jeux ou les applications à fort caractère graphique. La majorité ne devrait pas en avoir besoin… Et sachez que la différence est largement plus visible sur les écrans AMOLED que Super-LCD…
N’importe quel ingénieur en architecture de microprocesseur vous dira que le passage en 32 bits charge la mémoire, la mémoire graphique, le CPU, le bus du contrôleur vidéo. Ca va donc logiquement impacter la batterie et les performances du téléphone (CPU, mémoire, potentiellement framerate…). Est-ce que l’impact est visible à vous de me le dire, ça dépend du cas d’usage… Quant à la question “pourquoi on est pas en 32 bits par défaut?” la réponse la plus sensée qui me vient en tête (mais je ne suis pas dans le groupe produit…) c’est “parce qu’on en a pas besoin! (merci Metro!)”
Avec Mango, le SDK Windows Phone 7.1 s’est enrichi de 2 launchers à dimension “sociale” : ShareStatusTask, et ShareLinkTask. Ces launchers permettent de publier sur Facebook, Windows Live, Twitter, des statuts ou des liens en utilisant le compte de l’utilsateur configuré sur le téléphone, sans avoir à passer par l’authentification du SDK Facebook. Ca rend le développement de composants sociaux de l’application beaucoup plus simple. Idée du jour: utiliser ces launchers pour que vos utilisateurs puissent partager leur usage de votre application, et le lien vers l’application elle-même !
L’application qui va nous servir d’exemple est Klout Kikimeter. c’est une application que j’ai développé pour cet article (il fallait avoir quelque chose à partager!)… et qui permet de mesurer votre “influence en ligne” en utilisant Klout. Pas de jugement de valeur ici, mais bon, moi j’appelle ça “mesurer son kiki”.
On va voir 2 usages différents de l’application: le premier, le plus simple, partager un statut. le deuxième: partager le lien, et en l’occurrence je vous propose de partager un lien directement vers l’application… L’utilisateur partageant ainsi le lien vers votre application, et ses contacts pourront directement lancer la version web de marketplace sur son PC, ou directement l’application Marketplace du téléphone (qui marche même depuis le hub people!)
Rien de plus facile: il suffit de faire appel à ShareStatusTask, c’est juste 3 lignes de code:
ShareStatusTask sst = new ShareStatusTask(); sst.Status = "Somebody measured a Kiki! " + TwitterScreenName + " scores " + Score.ToString() + " on Klout!"; sst.Show();
Ce qui nous donne l’expérience suivante :
Jusqu’ici c’est enfantin.. la partie suivante se corse un peu: nous allons essayer de partager un hotlink de notre application depuis le téléphone.
Pour cela, on utilise la ShareLinkTask, qui ressemble beaucoup à la ShareStatusTask:
ShareLinkTask slt = new ShareLinkTask(); slt.Title = "klout kikimeter"; slt.Message = "I use this app to measure my kiki online! check it out! "; slt.LinkUri = new Uri("http://www.windowsphone.com/s?appid=2d2a85b1-d6ee-43f4-a302-4ada9fc606ea", UriKind.Absolute); slt.Show();
et voila!
En plus d’un message, vous pouvez voir qu’il faut un lien, et un titre. Hors au moment de la conception de l’application, le deeplink permettant d’ouvrir l’application Marketplace sur la bonne page n’existe pas encore (puisque votre application n’est pas publiée! Il faut donc procéder en 2 temps… Une première publication de l’application, en mode cachée, créera l’ApplicationId qui permettra de publier une mise à jour après… et passer l’application en mode public. Ca crée un petit overhead, mais peu importe, car l’application n’a même pas besoin d’être complète! juste certifiable, car au fur et à mesure des mises à jour l’ApplicationId ne change plus.
Voila, 2 petits trucs rapides pour rendre votre application un peu plus “sociale” et profiter du phénomène des réseaux sociaux pour faire votre pub!
Nokia, qui vient de lancer ses Lumia 710 et 800, se lance dans un roadshow à travers toute la France, pour rencontrer les développeurs mobiles. L’occasion de se rencontrer et de se former en une journée (9h30 – 17h) au développement Windows Phone 7.5.
Les dates!
>> Inscrivez-vous! <<
Cet article est le troisième et dernier d’une série qui constitue une introduction à la réalité augmentée avec Windows Phone 7.5 (Mango). Voici les liens vers les articles précédents:
Dans le dernier article, nous avons appris à récupérer la position de l’utilisateur. Il faut aussi récupérer la position GPS de ces points d’intérêt, mais ce n’est pas le but de cet article que de détailler les API de foursquare. Une fois qu’on a ces coordonnées, il faut commencer par calculer la direction de ces derniers par rapport à la position de l’utilisateur et du téléphone, afin de savoir si on doit les afficher ou pas à l’écran quand l’utilisateur pointe son téléphone dans une direction ou une autre :
foreach (Venue v in ViewModel.Venues) { // Calcul du cap de la Venue en fonction de la position du téléphone double Bearing = Math.Round(ARHelper.CalculateBearing(v.Location, ViewModel.MyLocation ), 0); // Calcul de la position de la Venue en fonction de l'angle, et de la distance, dans le repère XNA Vector3 RelativeVenuePosition = ARHelper.AngleToVector(Bearing, (WCSRadius * v.Distance / Radius)); AddVenue(RelativeVenuePosition, v); }
Le code ci-dessus calcul pour chaque point d’intérêt le cap en fonction de la position de l’utilisateur, et instancie un Vector3 représentant les coordonnées du point d’intérêt relativement à l’utilisateur. C’est de ce point dont on se servira par la suite pour calculer s’il doit être affiché ou pas !
Vous remarquerez que le bout de code ci-dessus utilise quelques méthodes qui ne sont pas dans le framework. Ce sont des méthodes développées pour ne pas charger le code en calculs mathématiques de position : en voici le code :
public static class ARHelper { public static double CalculateBearing(GeoCoordinate Venue, GeoCoordinate MyPosition) { ARHelper.DegreeToRadian(MyPosition.Latitude - Venue.Latitude); double num1 = ARHelper.DegreeToRadian(MyPosition.Longitude - Venue.Longitude); double num2 = ARHelper.DegreeToRadian(Venue.Latitude); double num3 = ARHelper.DegreeToRadian(MyPosition.Latitude); double angle = Math.Atan2(Math.Sin(num1) * Math.Cos(num3), Math.Cos(num2) * Math.Sin(num3) - Math.Sin(num2) * Math.Cos(num3) * Math.Cos(num1)); return ARHelper.RadianToDegree(angle) + 180.0; } public static Vector3 AngleToVector(double inAngle, double inRadius) { double num = ARHelper.DegreeToRadian(inAngle - 90.0); return new Vector3((float)Math.Round(inRadius * Math.Cos(num)), 0.0f, (float)Math.Round(inRadius * Math.Sin(num))); } public static double DegreeToRadian(double angle) { return 3.14159265358979 * angle / 180.0; } public static double RadianToDegree(double angle) { return angle * 57.2957795130823; } }
Il ne reste plus qu’à afficher les points à l’écran ! Comme dit plus tôt, on va rafraichir l’affichage à chaque changement de position du téléphone on va donc écrire le restant du code dans la méthode qui sert de handler pour l’évènement de changement de position du spatial framework. C’est ici qu’on va faire tous les calculs de projection des points sur l’écran, en fonction de leur position relative qu’on a calculé plus tôt. On va donc retrouver toutes nos matrices… Allons-y petit à petit :
D’abord, on calcule la position du téléphone dans l’espace :
Matrix attitude = Matrix.CreateRotationX(MathHelper.PiOver2) * motionReading.Attitude.RotationMatrix;
Le telephone étant tenu horizontalement, il faut appliquer une rotation e 90° sur l’axe des X sur la matrice de position u téléphone qui nous est renvoyée directement par le Spatial Framework.
Ensuite, pour chacun des points, il va falloir créer une matrice qui décrit sa position en 3D dans le repère utilisé pour faire la projection :
Matrix world = Matrix.CreateWorld(points[i], Vector3.UnitZ, Vector3.UnitX);
Il ne reste plus qu’à projeter le point sur l’écran:
Vector3 projected = viewport.Project(Vector3.Zero, projection, view, world * attitude);
Une fois la projection faite, si le point est dans le champ de vision on les affiche, sinon on les masque:
if (projected.Z > 1 || projected.Z < 0) { AugmentedLabels[i].Visibility = System.Windows.Visibility.Collapsed; } else { AugmentedLabels[i].Visibility = System.Windows.Visibility.Visible; // Centrage du contrôle sur le point TranslateTransform tt = new TranslateTransform(); tt.X = projected.X - (AugmentedLabels[i].RenderSize.Width / 2); tt.Y = projected.Y - (AugmentedLabels[i].RenderSize.Height / 2); AugmentedLabels[i].RenderTransform = tt; }
Ici le tableau AugmentedLabels contient les éléments graphiques à afficher (en l’occurrence, un UserControl avec une icône, un nom, et une distance.
Et voilà ! Nous savons maintenant comment marche la réalité augmentée en mode « viewfinder » dans Windows Phone 7.5.
Pour ceux qui souhaiteraient industrialiser leurs développements, il est possible de dériver un petit framework de tout ça… ou alors d’en utiliser un existant, comme celui-ci : Geo Augmente Reality Toolkit.
Vous pouvez retrouver l’intégralité de ce tutorial au format word ainsi que l’application d’exemple sur le skydrive suivant:
Happy coding !
Cet article est le deuxième d’une série qui constituent une introduction à la réalité augmentée avec Windows Phone 7.5.
Voyons maintenant les API qui nous permettent d’utiliser les différents composants utiles du téléphone, à savoir la caméra, le spatial framework qui permet d’avoir la position du téléphone et les APIs XNA permettant de réaliser les transformations.
C’est la partie la plus simple ! en effet avec Mango on dispose de 2 APIs différentes : la classe PhotoCamera, spécifique à Windows Phone, permettant de contrôler la caméra, qu’elle soit frontale ou au dos du téléphone, le flash, le bouton de prise de photo, etc… Une autre API existe, l’API héritée de Silverlight 4, qui garantit la compatibilité avec les applications Desktop, dont nous n’avons cure…
Pour afficher le flux de la caméra à l’écran il faut définir une zone d’affichage, qui sera rectangulaire : pour cela, il suffit de définir un rectangle, dont nous définirons la source du contenu en code :
<Rectangle> <Rectangle.Fill> <VideoBrush x:Name="viewfinderBrush" /> </Rectangle.Fill> </Rectangle>
Et pour le code behind :
PhotoCamera camera = new PhotoCamera(CameraType.Primary); viewfinderBrush.SetSource(camera);
Ces quelques lignes suffisent à afficher le flux vidéo à l’écran. Il faut savoir qu’on peut intercepter chacune des frames de la caméra pour y appliquer un traitement, mais cela ne nous intéresse pas dans cet article. C’est en revanche un élément clef pour l’autre type de réalité augmentée, qui nécessite d’appliquer un traitement à l’image pour détecter un tag par exemple.
Maintenant que nous sommes en mesure d’afficher le code de la camera, il nous faut récupérer la position du téléphone. Pour cela nous allons utiliser un spatial framework, c’est-à-dire une API qui permet d’intégrer les fonctionnalités des différents capteurs du téléphone (accéléromètre, boussole, et éventuellement gyroscope), et d’y appliquer un certain nombre de traitements (des filtres par exemple) pour lisser le signal. Comme tous les capteurs dans Windows Phone 7 ce spatial framework dispose d’une interface asynchrone : on va donc l’instantier, le configurer pour recevoir un certain nombre de positions par seconde, et s’abonner à l’évènement de changement de position, avant de le lancer. C’est dans la méthode associé à cet évènement qu’on écrira le code permettant d’afficher les points d’intérêt à l’écran, étant donné que la position de ces points d’intérêt sur l’écran change en fonction de la position du capteur !
Motion motion = null; if (!Motion.IsSupported) { MessageBox.Show("Motion API Not supported :("); return; } if (motion == null) { motion = new Motion(); motion.TimeBetweenUpdates = TimeSpan.FromMilliseconds(66); // 15 FPS, largement suffisant motion.CurrentValueChanged += new EventHandler<SensorReadingEventArgs<MotionReading>>(motion_CurrentValueChanged); try { motion.Start(); } catch (Exception ex) { MessageBox.Show("Impossible de démarrer l'API Motion! " + ex.Message); } }
Vous remarquerez qu’avant toute chose, on teste si l’API Motion est supportée : en effet, pour fonctionner le spatial framework a besoin au moins d’un accéléromètre et d’une boussole… hors cette dernière est optionnelle dans les chassis Windows Phone 7 (de même que le gyroscope). En tout état de cause, sans boussole, impossible de connaitre l’orientation du téléphone et donc de l’utiliser pour faire de la réalité augmentée… Le gyroscope quand il est présent amène quant à lui une bien meilleure précision dans la captation des mouvements du téléphone.
Notre application exige qu’on connaisse la position de l’utilisateur afin de situer les points d’intérêt autour de lui. C’est chose très facile avec Windows Phone 7, grace à l’API GeoCoordinateWatcher. Encore une fois elle est asynchrone : il faut donc l’instancier, s’abonner à l’évènement de changement de position et démarrer le capteur :
GeoCoordinateWatcher gcw = new GeoCoordinateWatcher(GeoPositionAccuracy.High); if (gcw.Permission == GeoPositionPermission.Granted) { gcw.MovementThreshold = 20; gcw.PositionChanged += new EventHandler<GeoPositionChangedEventArgs<GeoCoordinate>>(gcw_PositionChanged); gcw.Start(); } else { MessageBox.Show("You denied location permission - please enter a location in the textbox"); }
Attention à bien vérifier que l’utilisateur a bien autorisé sa géolocalisation avant !
Nous avons étudié les concepts mathématiques dans la partie 1, les APIs dans la partie 2, il ne reste plus qu’à utiliser tout cela ensemble pour obtenir une application! c’est l’objectif de la partie 3….
Avec la version 7.1 du SDK Windows Phone (Mango), l’intégration de la réalité augmentée dans les applications mobiles va devenir beaucoup plus facile : de nouveaux composants font leur apparition et sont conçus pour rendre très simple le développement de ce type d’interface. Mais d’abord, intéressons-nous à ce qu’est la réalité augmentée, et aux concepts qu’il faut maitriser avant de s’attaquer au code.
Le principe de base de la réalité augmentée est d’afficher en surimpression d’une image « réelle » (issue d’une caméra par exemple) des informations purement digitales. Les deux usages les plus courant de la réalité augmentée sont :
Dans cet série d’articles, nous allons nous intéresser au premier cas d’utilisation, à savoir le téléphone en mode « viewfinder ».
La première chose à comprendre, c’est qu’il nous faut appliquer un certain traitement aux points d’intérêts : en effet nous voulons représenter dans un espace 2D (l’écran du téléphone) un certain nombre d’informations liées à des coordonnées 3D (le monde réel : latitude, longitude, distance, etc). Il faut donc projeter ces points sur l’écran. Et finalement, projeter dans un espace en 2D des points d’un monde en 3D, on le fait depuis longtemps dans le monde des jeux vidéos. On va donc reprendre le vocabulaire de ce monde :
Lorsqu’un objet sera contenu dans le frustum alors il sera projeté sur le viewport dans la direction de l’œil de l’utilisateur.
Pour simplifier un schéma pas forcément trivial, on considérera que l’œil de l’utilisateur est �� une distance fixe du viewport, dans l’axe de la normale à son centre (le vecteur qui part du centre du rectangle, perpendiculairement au plan du rectangle). Il n’existe de toute façon pas de moyen simple de savoir où se trouve l’œil de l’utilisateur par rapport à l’écran… A moins de faire du face tracking avec la caméra frontale, ce qui n’est pas l’objectif de cet article.
Tout cela peut se résumer à ce schéma :
Cette projection doit bien entendu également tenir compte de la position du téléphone : en effet, dans une localisation d’un objet en 3D (donc potentiellement, plus haut ou plus bas que l’utilisateur) il faut tenir compte de la position du téléphone (qu’il faut de toute façon connaitre pour savoir dans quel sens l’utilisateur regarde !!).
Pour symboliser la position de la caméra, du téléphone, des points d’intérêt, et les transformations qu’il faut y appliquer pour les projeter sur l’écran, un seul outil… les matrices.
Pas besoin de se replonger dans un cours d’algèbre linéaire pour faire de la réalité augmentée cependant ! il faut juste accepter le fait qu’une position peut être codée par un vecteur 3D (donc composé des 3 coordonnées x, y et z) auquel on adjoint en général une 4ème composante nécessaire pour les calculs qu’on appellera w. Par ailleurs il est possible de coder dans une matrice 4x4 à la fois des rotations, des translations, des mises à l’échelle (scaling), et des projections. Encore une fois pas besoin de comprendre pourquoi et comment ça marche (même si c’est très intéressant… si vous voulez en savoir plus, rendez-vous dans les ressources au bout de ce document, nombre d’articles intéressant y figurent pour avoir plus de contexte).
Si on résume tout ça : je prends des points en 3D symbolisés par des vecteurs, que je multiplie par des matrices symbolisant des transformations, pour avoir de nouveaux vecteurs, dans un repère 2D : l’écran du téléphone. Nous verrons dans la suite que les API de Windows Phone 7 notamment dans XNA permettent de faire ça très simplement.
Le prochain article de cette série sera consacrée aux APIs de Windows Phone dont on va se servir, à savoir la Caméra, la classe Motion (aussi appelée Spatial Framework) et le GPS
Voici les liens vers les articles suivants:
Le 8 novembre, sur le Campus Microsoft à Issy-les-Moulineaux, on vous invite à rencontrer un des “Senior UX Designer” à l’origine de l’interface Metro de Windows Phone 7: Arturo Toledo.
L’agenda est le suivant:
Voila quelques formations au design metro et quelques sessions sur le sujet auxquelles je participe, mais jamais encore je n’avais vu un planning d’évènement sur le sujet aussi bien gaulé (gauler étant un terme technique, bien entendu ). Que vous soyez développeur Windows Phone 7 ou pas, je pense que vous allez en prendre plein la vue… il faudra vraiment y être!
L’inscription c’est par ici!
L’Accélérateur Windows Phone, c’est une série de moyens mis à votre disposition, vous, les développeurs, pour vous aider tout au long de votre parcours sur la plateforme Windows Phone 7: formation, conception de l’application, compréhension du marketplace et de l’app-hub, jusqu’à la publication!
Derrière ce programme se cache une “vraie personne” (pas un robot quoi) qui voue ses journées à vous aider, et qui va tacher de répondre à toutes vos requêtes:
Les friday labs, c’est tout simplement les portes de Microsoft France qui s’ouvrent tous les vendredis entre 10h et 18h pour les développeurs Windows Phone 7 qui souhaitent rencontrer des experts du développement Windows Phone 7, que ce soit pour du support technique, des feedbacks avisés sur une application, passer la certification… Bref, c’est l’occasion d’échanger, au sein du Microsoft Technology Center, sur le développement Windows Phone 7. N’oubliez pas de vous inscrire sur le site avant de passer!
Chaque mois les après-midi du développement vous propose sur le campus Microsoft à Issy-les-Moulineaux une demi-journée technique, du niveau débutant à avancé, et le prochain rendez-vous est le 10 novembre: au programme, Javascript et JQuery!
Le programme est le suivant:
Javascript est un langage qui prend de plus en plus d’importance dans les modèles de développement: C’est bien entendu le langage que l’on va retrouver derrière tout site en HTML5, depuis l’accès au donnée jusqu’à l’animation des éléments graphiques, mais aussi dans le monde du mobile, et dans le futur jusque dans les applications!
>> Cliquez ici pour vous inscrire <<
J’aurai le plaisir d’animer demain Jeudi 6 octobre un atelier autour du .NET Microframework et des différentes plateformes qu’on peut utiliser pour prototyper des objets connectés, et mes amis d’Ucaya vont animer l’atelier sur Kinect!
Afin de bien se préparer à ces ateliers, les prérequis techniques sont les suivants:
C’est encore une annonce sur le blog développeurs Windows Phone 7 qui nous l’apprend, le SDK Windows Phone 7.1 (pour Mango) est arrivé en version finale (RTW: Release To Web). Il est disponible en version multilingue, c’est à dire que vous pouvez l’installer en Français! Il vous suffit de choisir votre langage dans la liste déroulante sur la page de téléchargement.
Quelques points qui me paraissent intéressants à souligner:
Pour ce qui est du processus de mise à jour…
Par ailleurs, le déploiement de la mise à jour Mango est en cours depuis hier! vos utilisateurs vont donc s’attendre à trouver une version de votre application pour Mango C’est le moment de soumettre vos mises à jours!
Pour l’instant, la dernière version 7.0 restera disponible pour les terminaux 7.0 et vos mises à jours avec le SDK 7.1 seront déployées sur les terminaux Mango. D’ici la fin octobre on vous offrira un contrôle encore plus fin de vos mises à jours et vous pourrez faire évoluer en parallèle la branche 7.0 et la branche 7.1. il n’y a donc plus aucune raison d’attendre pour mettre vos applications à jour!
Happy updating!
Une bonne nouvelle annoncée hier sur le blog développeurs Windows Phone 7, qui fait suite à un post sur ce qui arrive quand on met une application à jour vers Mango. Le premier scénario était qu’à partir du moment ou on met à jour une application vers Mango, il n’est plus possible de mettre à jour la version 7.0. Le groupe responsable de l’App-Hub a travaillé dur pour faire sauter cette limitation, et c’est avec plaisir que je relaie la nouvelle : il sera maintenant possible de faire des mises à jour à la fois pour la version 7.0 et pour la version 7.1. Cette possibilité sera offerte dès fin Octobre et devrait débloquer pas mal de développeurs qui attendaient pour poster la mise à jour “Mango” de leur application.
L’API Mapping tool, déjà présenté sur ce blog est un outil proposé par l’équipe interopérabilité de Microsoft qui permet aux développeurs iPhone et Android, et à partir d’aujourd’hui Symbian (Qt) de retrouver l’équivalent de leurs API favorites dans le kit de développement Windows Phone 7.
En plus de l’API Mapping Tool, l’équipe d’interop a aussi publié un guide “Windows Phone 7 Guide for Symbian Qt application developers” qui permet de comprendre comment faire évoluer sa compréhension de la plateforme Nokia vers Windows Phone 7, en parlant de l’environnement de développement, des langages de programmation, de l’ergonomie, de Metro, etc.
Tout ce contenu est annoncé aujourd’hui même sur le blog développeurs Windows Phone 7, en kickoff de la tournée Nokia / Windows Phone 7 qui débute par l’évènement parisien aujourd’hui!
Annoncé à Maker Faire ce week end à New York City, c’est le retour (tant attendu!) de Microsoft Robotics Developer Studio, dans sa version 4, avec son paquet de nouveautés et un post très intéressant du patron de la robotique chez Microsoft, Stathis Papaefstathiou, sur le blog de son équipe!
Voici les principales informations qui y sont distillées:
Tout ceci devrait vous permettre d’exercer votre créativité dans un nouveau concours de robotique: Robotics@Home !
Les après-midi du développement repartent de plus belle en cette rentrée, et le programme de l’année va être… chargé!
Mercredi 30 septembre, rendez-vous au centre de conférence Microsoft à Issy-les-Moulineaux, pour une demi-journée de formation sur Azure. Comme d’habitude avec les après-midi du développement, nous allons démarrer avec les bases de la plateforme Azure, et rapidement faire monter le niveau technique : on va parler des rôles, des services, d’interopérabilité… des ingénieurs du support vont venir expliquer des techniques de trace et de debugging, et quelque soit votre background de développeur, et votre niveau de connaissance de la plateforme si vous voulez comprendre comment on travaille dans le cloud et ce qu’on peut en tirer, c’est _la_ demi-journée à ne pas louper!
Agenda :
13h30 : Accueil
14h00 : Sessions
18h00 : Apéro
En bonus, et parce que c’est la rentrée, le programme ne s’arrête pas là. Après une pause Pizza-Bière, la soirée continue avec ZeCloud, et un azure camp dédié à l’utilisation du cloud pour la robotique, avec une guest star, Nao, d’Aldebaran Robotics!
Voici le lien d’inscription, et n’oubliez pas de partager sur Facebook, sait-on jamais, si vous voulez venir avec des amis
La tournée des Microsoft Days reprend, comme chaque année, avec un tour de France pour venir voir clients et partenaires et parler de l’actualité du développement, et de l’IT en entreprise. Cette année, je vous propose qu’on se retrouve autour de 2 sessions sur Mango au cours de la journée:
A l’attention des utilisateurs, des décideurs et des responsables d’infrastructure:
Windows Phone « Mango » en Entreprise
« Mango » est le nom de code de la version 7.5 de Windows Phone, et c’est une mise à jour majeure, à la fois pour les utilisateurs et les entreprises.
Encore plus simple et intuitif, Windows Phone « Mango » améliore l’expérience du Smartphone autour des communications, de la productivité, des applications et du Web. En plus d’une expérience utilisateur peaufinée, de nombreuses nouvelles fonctionnalités ont été ajoutées, rendant le téléphone plus efficace, et plus facilement intégrable en Entreprise : Le support d’Exchange, de Sharepoint, l’intégration avec Office365, la possibilité de déployer des applications métiers… toutes ces fonctionnalités vous seront présentés dans une session factuelle et riche en démonstrations.
A l’attention des développeurs:
Nouveaux scénarios d’applications avec le SDK Windows Phone 7 « Mango »
Avec l’arrivée de la mise à jour « Mango », de nouveaux horizons s’offrent aux développeurs d’applications mobiles. Que vous ayez déjà pris le virage Windows Phone 7, ou que vous soyez encore à l’étude du marché, ce nouveau SDK va vous permettre d’établir de nouveaux scénarios : réalité augmentée avec l’intégration du flux vidéo, de Silverlight et XNA et du Spatial Framework, synchronisation online/offline avec le multitasking et la base de donnée locale, meilleure intégration dans l’expérience native du téléphone, etc. Vos applications métiers ne seront pas en reste puisqu’il est maintenant possible d’opter pour une distribution privée des applications. Une session technique et inspirante à destination des développeurs de tous niveaux, mobiles, ou pas !
Les dates à retenir:
Pour vous inscrire il faut aller sur le site des Microsoft Days et s’enregistrer aux rencontre techniques !
Avec le nouveau SDK pour Mango, le WebClient, le contrôle WebBrowser et la ListBox ont subi des changements qui peuvent impacter le bon fonctionnement de votre application.
Avant le WebClient revenait systématiquement dans le thread UI, peu importe le thread appelant. Cela change, et maintenant, il va revenir dans son thread appelant. Cela a un impact direct sur toutes les applications qui manipulent la couche UI depuis le callback du WebClient sans utiliser le dispatcher (c’est-à-dire, plein de gens !). Cela va maintenant provoquer une exception d’accès (Invalid cross-thread access).
Pour y remédier, la solution de facilité consiste à enfermer toutes vos manipulations de l’UI dans des appels au Dispatcher :
Deployment.Current.Dispatcher.BeginInvoke(() => { // Votre code qui manipule l’UI ici });
Attention, cette méthode permet de refaire marcher rapidement votre application, mais il faut bien avoir conscience que manipuler l’UI de cette manière n’est de toutes façons pas une bonne pratique ! Votre WebClient devrait travailler dans votre couche d’accès aux données qui devrait certainement être séparée de votre couche UI (par le pattern que vous voulez !).
Autre contrôle impacté par le passage à Mango, le contrôle WebBrowser. Mango va effectivement utiliser IE9 pour se mettre le plus à jour possible quant au support du HTML5 et le contrôle WebBrowser va aussi bénéficier de cette amélioration : toutefois comme tous les développeurs Web le savent, nouveau browser signifie souvent qu’il faut retester le code javascript/html/css pour s’assurer du rendu. Même si dès le départ, les expériences à base de contrôle WebBrowser ont été déconseillées (sauf pour afficher une page web évidement), certaines applications ont fait le choix de masquer leur site web mobile sous une expérience native… et dans ce cas, l’impact n’est que difficilement mesurable, car il dépend des standards utilisés pour ce site web ! Le user agent va également changer, et même si c’est maintenant considéré comme une mauvaise pratique de tailler l’expérience en fonction du user agent, certains choisissent parfois de le faire… il faudra faire attention ! Sachez que si vous souhaitez tester dès maintenant l’émulateur des outils de développement est en IE9 ! Si vous voulez tout savoir sur les capacités de IE9 et du contrôle WebBrowser dans Windows Phone 7 "Mango", rendez-vous sur MSDN : Web Development for Windows Phone 7.
Le dernier changement dont je voulais parler qui pourrait impacter certaines applications (beaucoup plus rares) vient du fait que maintenant le traitement des inputs (contacts) sur l’écran tactile qui se fait maintenant dans un thread à part. Encore une fois l’équipe Silverlight le décrit dans un post sur son blog. Cela peut impacter le rafraichissement de certaines propriétés du ScrollViewer. Ce dernier, à partir de Mango va aussi maintenant « manger » tous les évènements « ManipulationDelta » ce qui fait qu’ils ne seront plus disponibles pour les enfants du ScrollViewer. Si cela impacte votre application il suffit de rajouter une propriété à votre ScrollViewer :
ScrollViewer.ManipulationMode="Control"
Il n’y a que très peu de chance que votre application soit impactée par ces changements du ScrollViewer, en revanche, pour le WebClient et le contrôle WebBrowser, faites attention !! Enfin il y a d’autres changements qui ne sont pas forcément impactants mais que vous noterez au fur et à mesure, l’InputScope “Number” qui devient un vrai pavé numérique plutôt qu’un clavier complet avec chiffres par exemple… mais ces changements ne menacent pas directement votre application.
Depuis la beta 2 des outils (fin Juillet) il est possible de passer son téléphone à une ROM beta de Mango. Si vous avez déjà un compte sur l’App-Hub vous avez surement déjà reçu un email d’invitation à cette beta, hébergée sur Connect. (Si vous ne retrouvez pas cet email, vérifiez votre dossier spam… l’invitation vient de msftconn@microsoft.com.
Le processus de mise à jour est relativement sans risque, mais il faut quand même être conscient qu’il fait perdre la garantie constructeur. Point extrêmement important tout de même, n’oubliez pas l’étape de backup du téléphone, car il sera nécessaire d’utiliser ce point de restauration pour revenir à Nodo avant la mise à jour officielle et de production de Mango.
Si vous n’avez pas encore de compte développeur, c’est le moment d’en créer un! C’est de toutes façons obligatoire pour publier une application (Si vous ne cherchez pas à faire d’applications juste à profiter de Mango, cette béta n’est pas pour vous). Rendez-vous sur l’App-Hub avec votre LiveID, et suivez le guide.
Une fois le compte créé, vous pouvez demander une invitation à la beta en passant par ce formulaire en ligne. N’oubliez pas de bien lire les instructions, de bien respecter le backup du téléphone (et le backup du backup) et prévoyez entre 1 et 2 heures de votre temps…
Je profite de ce post pour vous rappeler qu’avoir la beta de Mango sur le téléphone ne suffit pas: il faut aussi télécharger les outils de dev, et mettre à jour vos toolkits. Pour l’instant on est à la Release Candidate des outils. Pas d’inquiétude pour autant quant à la stabilité de votre machine de dev, la béta de Mango étant parfaitement stable pour continuer à développer pour la version actuelle de Windows Phone 7 (et oui, vous allez voir, vous allez peut-être continuer un peu…)
Pour que l’installation des outils se passent bien assurez-vous de désinstaller d’abord l’ancienne version des outils, et du client Zune. Attention choisissez bien dans votre panneau de configuration le meta-installer (Windows Phone 7.0 SDK – ENU). Vérifiez avec la fonction recherche qu’il n’y a plus rien qui concerne Windows Phone 7 avant de vous lancer dans la nouvelle installation.
Enfin, avant de passer votre application à Mango, relisez bien ce post qui décrit ce que fait Marketplace avec les updates Mango des applications. Une fois que vous aurez publié une mise à jour de votre application pour Mango, vous ne pourrez plus poster de mises à jour pour la version pré-Mango de votre application… qui continuera à être téléchargée par tous les gens qui n’ont pas encore migré !! Réfléchissez donc bien au timing de votre mise à jour et aux besoins de vos utilisateurs!
Avec l’arrivée prochaine de Mango sur les téléphones des utilisateurs, cette rentrée est le bon moment pour se poser les questions des évolutions de vos applications. Quels sont les changements nécessaires, quels sont les changements suggérés, quelles sont les nouvelles expériences que vous pourriez proposer aux utilisateurs avec les nouvelles API? Premier post d’une petite série... et on commence avec la base: comment vont se passer les updates de votre application sur Marketplace pour les utilisateurs qui ont Mango, et ceux qui n’ont pas encore mis leur téléphone à jour?
Pour faire court, Marketplace gère les choses intelligemment: Chaque utilisateur verra la version de votre application qui convient à son téléphone, autrement dit votre dernière version “7.0” continuera d’exister aux cotés de la version “7.1”, et un utilisateur qui n’a pas encore migré verra la première, alors qu’un utilisateur ayant installé Mango verra la seconde.
Si un utilisateur a déjà migré à Mango a déjà installé la version 7.0 de votre application, il verra une notification pour passer à la version 7.1. Evidemment un utilisateur qui n’aura pas encore installé Mango ne verra pas cette notification de mise à jour.
Tous les rankings et les reviews que vous avez reçu avec votre application en 7.0 seront gardés pour la version 7.1.
En revanche, Attention ! Toutes les infos et les images (screenshots) que vous posterez avec l’update pour 7.1 seront celles qu’on verra avec la version 7.0.. il faut donc veiller à bien identifier dans la description de votre application et sur les screenshots les fonctionnalités Mango (avec un overlay “WP 7.5 Only”). On recommande aussi dans la description d’inclure un lien vers notre site d’information sur la mise à jour: http://wpupgrade.ms/mangome.
[Note au passage] Les terminaux Mango seront des Windows Phone 7.5, mais les nouveaux outils de développement, correspondent à la version de l’OS, qui est 7.1… Don’t ask!
Enfin, une fois que vous aurez poster une mise à jour pour Mango, vous ne pourrez plus poster de mise à jour pour la version 7.0. Autrement dit, il ne sera pas possible de faire évoluer les 2 branches en même temps… Ceci étant dit, les applications conçues pour Windows Phone 7.0 devrait continuer à fonctionner sur Windows Phone 7.1… A quelques breaking changes, associés à quelques erreurs courantes de programmation, dont on discutera dans un prochain article.
[Update – 20/09/2011] Finalement il sera possible de faire évoluer les 2 versions en même temps!
Dernier mot pour la conclusion, juste pour rappeler que tous les terminaux Windows Phone 7 auront droit à la mise à jour Mango, à l’exception des premiers modèles pour développeurs qui ne sont jamais sortis dans le commerce. A terme, on espère que 100% de votre base d’utilisateurs auront Mango!
Dans le prochain article, nous détaillerons les changements impactants les applications existantes dans Mango!