Pierre's Embedded and Mobile Blog : mobile

[Windows Phone 7.5] Protéger les données sensibles dans l’Isolated Storage

PierreCauchois — Thu, 05 Apr 2012 16:58:20 GMT

Il arrive que l'’on doive échanger des données sensibles, par exemple à travers du réseau, ou entre des couches applicatives. Pour cela on a accès à toute une couche de sécurité qui est très simple à utiliser et qui inclue les algos les plus classiques, qu’il s’agisse de crypto (AES, RSA etc) ou du hashage (HMAC, SHA1, SHA256…). Cette couche permet de crypter un contenu à partir d’une clef secrète ou d’un couple clef publique / clef privée.

Mais parfois on veut stocker ces données, et autant on peut utiliser ces algos pour stocker les crypter, on ne peut pas les utiliser pour stocker la clef de cryptage elle-même! Dans ce cas, on a la Data Protection API (DPAPI) qui utilise une clef secrète contenue dans le téléphone, impossible à récupérer et qui permettra de crypter n’importe quel type de contenu. Cette DPAPI est accessible depuis la classe statique System.Security.Cryptography.ProtectedData. Celle ci contient 2 méthodes, Protect et UnProtect, qui agissent tout simplement sur des tableaux de bytes:

Un exemple de cryptage:

byte[] dataBytes = System.Text.Encoding.UTF8.GetBytes(data);
byte[] encryptedData = ProtectedData.Protect(dataBytes, null);

Et un décryptage, aussi simple!

byte[] decryptedData = ProtectedData.Unprotect(encryptedData, null);
result = new string(System.Text.Encoding.UTF8.GetChars(decryptedData));

En tout état de cause, si vous n’avez qu’à stocker des données cryptées et pas forcément à les partager, vous pouvez ne vous servir que de cette classe. Ca simplifie grandement l’écriture de certaines applications comme par exemple les coffres de mots de passe… mais n’oubliez pas de gérer, lors de vos cryptages/décryptages, les tombstoning correctement… et n’écrivez jamais nulle-part un secret en clair!

Livemeeting “monétisation des applications mobiles” : le contenu est disponible!

PierreCauchois — Mon, 12 Mar 2012 18:06:31 GMT

Vendredi 9 Mars se tenait le deuxième livemeeting de l’accélérateur, dont le sujet était la monétisation des applications.

La première partie couvre les différents business models avec leurs avantages et inconvénients, et les clefs pour réussir le lancement d’une application. Cette partie a été présentée par Julien Amouroux de Nokia.

Voici le lien vers sa présentation

La deuxième partie couvre l’utilisation du SDK Microsoft Advertising, et une petite démonstration d’intégration de celui-ci dans une application, tout ceci par Aurélien Lemoine, de ClevLab (twitter).

Aurélien a posté sa présentation sur le skydrive de ClevLab.

Enfin, sachez que vous pouvez également revoir le webcast !

A vous de nous dire maintenant ce que vous aimeriez vois dans le prochain livemeeting!

[Windows Phone 7.5] Ce que signifie la mise à jour 7.1.1 (Tango) du SDK pour votre application

PierreCauchois — Wed, 29 Feb 2012 18:24:22 GMT

Une CTP de la version 7.1.1 du SDK Windows Phone “Tango” a été annoncée au Mobile World Congress, et sur le blog de l’équipe Windows Phone. Au menu, plutôt des bonnes nouvelles: la mise à jour “Tango” ouvre la porte à des terminaux plus low-cost, particulièrement utiles dans les pays émergents, ajoute le support d’un certain nombre de langues et de pays pour le marketplace, et cela se traduit par un nombre d’utilisateurs potentiels de vos apps qui grossit d’environ 60% d’un seul coup…

Parmi les concessions faites sur le châssis hardware pour diminuer les coûts des téléphones, il y a la possibilité de faire des terminaux avec seulement 256Mo de RAM. Ce choix a pour conséquence qu’une application qui consommerait plus de 90Mo de mémoire serait coupée automatiquement… Cela concerne moins de 5% des applications du Marketplace et nous travaillons avec ces développeurs pour les aider à revenir sous cette barre fatidique.

Pour tester si c’est votre cas, la CTP de la version 7.1.1 du SDK Windows Phone amène une version “bridée” à 256Mo de l’émulateur. il n’y a en gros que ça d’intéressant dans cette version, qui n’est de toutes façons pas encore mure pour publier des applications sur Marketplace (pas de licence dite “go live”). Pas besoin de se jeter dessus, donc, surtout pour votre machine de production, mais si vous êtes dans les 5% à consommer plus de 90Mo, il peut être bon de le tester rapidement.

Si vous savez que vous avez systématiquement besoin de plus de 90Mo, vous pouvez l’indiquer dans votre manifest, et alors l’application n’apparaitra plus aux utilisateurs des téléphones low-cost, évitant l’expérience “j’installe mais ça plante”.

Il suffit de rajouter, dans le fichier WMAppManifest.xml, sous les capabilities les 3 lignes suivantes:

<Requirements>
  <Requirement Name="ID_REQ_MEMORY_90" />
</Requirements>

Si on résume, soit vous utilisez moins de 90Mo, et tout va bien, soit vous utilisez plus de 90Mo de RAM, et là 2 options:

Vous optimisez
Vous décrétez que vous ne voulez pas que votre application soit installable sur les téléphones ne disposant que de 256Mo de mémoire, avec les 3 lignes ci-dessus

Attention aux background agents…

Votre application n’est pas sensée dépendre d’un background agent pour fonctionner correctement: dès le début, vous deviez prendre en compte le fait que vos utilisateurs peuvent les désactiver manuellement dans le panneau de configuration. Sur les terminaux à 256Mo de RAM, ils ne tourneront pas, de toutes façons. Une raison de plus d’y penser, donc, en créant l’expérience de votre application…

Cela ne concerne que les background agents génériques (PeriodicTask/ResourceIntensiveTask).
Si vous n’avez pas encadré le lancement de votre background agent dans un block try/catch, une InvalidOperationException sera levée et fera éventuellement crasher votre application… (qui aurait crashé de la même manière si le nombre maximum de background agents sur un terminal “normal” est atteint)… Si vous n’avez pas envisagé ce cas, je vous conseille de le faire
Si vous avez besoin de background agents pour activer des options spécifiques (live-tile, par exemple) essayez de ne proposer cette option que si le terminal dispose de plus de 256Mo… ce qui m’amène à la question suivante:

Comment savoir si un terminal dispose de plus de 256 Mo?

Réponse: En utilisant les DeviceExtendedProperties:

try
{
    long result = 
    (long)DeviceExtendedProperties.GetValue("ApplicationWorkingSetLimit");
}
catch (ArgumentOutOfRangeException) 
{
    // The device has not received the OS update, which means the device is a 512-MB device.
}

Comment optimiser l’usage de la mémoire?

La racine de tout ce qui concerne les performances des applications Windows Phone est sur cette page:

Performance Considerations in Applications for Windows Phone

Si vous êtes dans le cas d’un jeu en XNA (particulièrement sensible à l’usage de la mémoire) vous pouvez vous tourner vers:

Improving Memory Use for XNA Games

Une session qui a été jouée au Techdays 2012 sur le sujet sera par ailleurs bientôt en ligne…

Pour conclure, je dirais bien que pragmatiquement à partir du moment où on code propre, et où on avait regardé dès le début les contraintes de certification de Marketplace (qui incluent, depuis la première version, la limite de 90Mo), il n’y aura pas de problème. Et pour ceux qui auraient une situation particulière, lié à un usage spécifique ou à une erreur bénigne dans le code au lancement des background agents, la résolution est facile! A vous de jouer!

Source: Developping for 256-MB devices sur MSDN

[Windows Phone 7.5] Supprimer le “pinch to zoom” sur un contrôle WebBrowser

PierreCauchois — Mon, 20 Feb 2012 12:24:42 GMT

Le ViewPort

Le ViewPort se défini dans le code HTML. Il indique la largeur “virtuelle” de la page web. Sur un terminal mobile, on a envie d’ajuster le ViewPort en fonction de la largeur de l’écran, et d’une plateforme à une autre, ça peut varier (ça sera la même pour tous les Windows Phone). Le ViewPort permet de définir plusieurs propriétés:

width: par défaut, 320 (pixels). Comme ça c’est compatible iPhone, et après c’est le navigateur qui se charge de faire la conversion “pixels web –> pixels réels”.
height : par défaut, 480
user-scalable: permet de définir si l’utilisateur peut zoomer dans la page

Certaines plateformes définissent des paramètres comme minimum-scale, maximum-scale, ou initial-scale… Ils ne sont pas supportées par IE9 dans Windows Phone.

Le truc classique en manipulant le viewport pour supprimer l’effet de zoom, c’est de passer le paramètre user-scalable à “no” et le paramètre “width” à “device-width”:

<meta name="viewport" content="width=device-width, user-scalable=no"/>

Supprimer les manipulations

Mais cela ne suffit pas! En effet, si l’utilisateur essaie de zoomer, la page zoomera quand même… puis reviendra en place automatiquement, empêchant d’afficher un autre niveau de zoom que celui prescrit initialement, mais indiquant à l’utilisateur que son geste a bien été pris en compte (bonne pratique d’ergonomie en général, mais pas top quand on veut cacher qu’on utilise une webview… parce qu’on sait tous que c’est pourri!).

Pour supprimer cet effet, il faut supprimer carrément les évènements de manipulation au niveau du contrôle WebBrowser. cela nécessite un peu de code qui m’a gentiment été soufflé par nos amis d’Ucaya, et plus particulièrement Romuald, dont l’origine est ce post de Colin Eberhardt:

private void WebBrowser_Loaded(object sender, System.Windows.RoutedEventArgs e)
{
    var border = ((Microsoft.Phone.Controls.WebBrowser)sender).Descendants<Border>().Last() as Border;

    border.ManipulationDelta += Border_ManipulationDelta;
    border.ManipulationCompleted += Border_ManipulationCompleted;
}

private void Border_ManipulationCompleted(object sender,
                                    ManipulationCompletedEventArgs e)
{
    // suppress zoom
    if (e.FinalVelocities.ExpansionVelocity.X != 0.0 ||
        e.FinalVelocities.ExpansionVelocity.Y != 0.0)
        e.Handled = true;
}

private void Border_ManipulationDelta(object sender,
                                        ManipulationDeltaEventArgs e)
{
    // suppress zoom
    if (e.DeltaManipulation.Scale.X != 0.0 ||
        e.DeltaManipulation.Scale.Y != 0.0)
        e.Handled = true;

    //// optionally suppress scrolling
    //if (ScrollDisabled)
    //{
    //    if (e.DeltaManipulation.Translation.X != 0.0 ||
    //      e.DeltaManipulation.Translation.Y != 0.0)
    //        e.Handled = true;
    //}
}

Evidemment, il faut associer la méthode WebBrowser_Loaded à l’évènement Loaded du contrôle WebBrowser…

Petite précision à propos de ce bout de code: il utilise la très excellente extension LinqToVisualTree qu’il faudra donc ajouter également au projet…

Et voila, plus d’effet de zoom. Ceci étant dit, ça ne doit pas vous encourager à utiliser les WebBrowser pour autre chose qu’afficher des pages HTML… et surtout, quelqu’en soit votre utilisation, ne les utilisez jamais, AU GRAND JAMAIS, dans un Panorama ou un Pivot, ça casse l’expérience de navigation horizontale. Il y a une place spéciale en enfer pour les gens qui font ça. Vous voilà prévenu!

Du bon usage du contrôle WebBrowser

Les contrôles de type “WebBrowser”, (ou WebView) sont rarement bien utilisés…

Un WebBrowser, c’est fait pour afficher du contenu web (du HTML) parce qu’on ne veut/peut pas le parser (par exemple, une page d’authentification OAuth).

Ce n’est pas fait pour éviter d’avoir à créer une expérience native.
Ce n’est pas fait pour réutiliser des vues entre différentes plateformes.
Ce n’est pas fait pour s’acheter une place sur un store, qu’on n’aurait pas eu avec un site web mobile.

Malheureusement 90% du temps c’est ça qu’on voit. Il ne faut pas faire. Une expérience native c’est justement pour avoir quelque chose de spécifique à chaque plateforme, en terme d’ergonomie, de look’n’feel. C’est ce que les utilisateurs attendent! Malheureusement le développement d’application n’est pas toujours piloté par le développeur soucieux de la beauté du code, ou le créa soucieux de la beauté des visuels et des animations. Des fois, le responsable du projet qui n’a pas assez de sous, ou de temps, et qui doit faire avec ce qu’il a… et on se retrouve avec des webviews mal utilisées.

Alors quand on utilise un contrôle WebBrowser, pour de bonnes ou de mauvaises raisons, il faut en contrôler le comportement. Sinon on se retrouve sur wtfmobileweb.com.

Encore merci à @RomuxX pour l’info, et pour d’autres lectures intéressantes sur le sujet, je vous encourage à aller voir la page sur le développement web pour Windows Phone 7.5, sur MSDN.

[E-Camp] Animations et Transitions de pages dans Windows Phone 7.5, webcast et slides

PierreCauchois — Thu, 16 Feb 2012 15:44:23 GMT

Comme pour tous les e-camps, vous pouvez retrouver le webcast directement sur la page de l’évènement (en cliquant sur “Afficher en ligne”). Quant aux slides, je les ai publiées sur ce skydrive, les voici :

D’une manière générale sachez que chaque e-camp peut être retrouvé directement sur sa page d’inscription, une fois qu’il a été enregistré (le jour J) il peut être revu.

LiveMeeting : Comment faire des animations et des transitions pour rendre vos applications plus fluides?

PierreCauchois — Wed, 01 Feb 2012 11:18:54 GMT

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!

[Techdays 2012] Préparation du parcours “Windows Phone 7”

PierreCauchois — Wed, 23 Nov 2011 19:29:36 GMT

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!

[Windows Phone 7.5] Passer en mode 32 bits dans les applications

PierreCauchois — Mon, 14 Nov 2011 10:25:34 GMT

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!)”

[Windows Phone 7.5] Utiliser les réseaux sociaux pour faire connaitre votre application!

PierreCauchois — Wed, 09 Nov 2011 13:33:55 GMT

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!)

Premier cas d’utilisation: partager un statut

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.

Second cas d’utilisation: partager un hotlink vers son 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)!

La méthode que j’avais trouvé à l’origine consiste à 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.

Mais depuis, Vivien Chevallier nous a trouvé une idée beaucoup plus propre… la solution sur son blog (un indice: il utilise le fichier WMAppManifest.xml)

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!

Si vous voulez aller plus loin dans la découverte des réseaux sociaux et de leur usage dans une application mobile, je vous invite également à regarder le webcast de cette session sur les APIs des réseaux sociaux, par Nicolas Humman aux Techdays 2012.

[Windows Phone 7.5] Nokia fait son roadshow près de chez vous!

PierreCauchois — Mon, 07 Nov 2011 20:49:16 GMT

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!

Jeudi 10 novembre à Marseille
Jeudi 17 novembre à Toulouse
Jeudi 24 novembre à Rennes
Mercredi 30 novembre à Bordeaux
Jeudi 1^er décembre à Strasbourg
Vendredi 12 décembre à Lyon

>> Inscrivez-vous! <<

[Windows Phone 7.5] Tutoriel sur la réalité augmentée, partie 3: afficher les données augmentées à l’écran

PierreCauchois — Mon, 31 Oct 2011 15:36:04 GMT

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;
    }
}

Projeter les points d’intérêt sur l’écran

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 !

[Windows Phone 7.5] Tutoriel simple sur la réalité augmentée, partie 2: Les APIs

PierreCauchois — Mon, 31 Oct 2011 15:23:00 GMT

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.

Accéder au flux de la camera

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.

Déterminer la position du téléphone dans l’espace

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.

Déterminer la position GPS et la direction des points d’intérêt

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….

[Windows Phone 7.5] Tutoriel simple sur la réalité augmentée, partie 1: les concepts, et les maths

PierreCauchois — Mon, 31 Oct 2011 15:13:42 GMT

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 :

l’utilisation du téléphone en mode « viewfinder », par exemple pour repérer les directions de points d’intérêt autour de l’utilisateur qui pointe le téléphone dans une certaine direction.
L’utilisation du téléphone pour capter un « tag » ou un point visuel reconnaissable, sur lequel on affiche des informations en rapport avec ce point : c’est le cas de nombreux jeux par exemple qui se servent de ce principe pour intégrer le gameplay dans un environnement réel.

Dans cet série d’articles, nous allons nous intéresser au premier cas d’utilisation, à savoir le téléphone en mode « viewfinder ».

Les concepts de 3D et de mathématiques à comprendre

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 :

L’œil de l’utilisateur correspond à une caméra : c’est un point, qui dispose de coordonnées dans un monde en 3D.
Le viewport, c’est l’écran du téléphone : la surface sur laquelle on va dessiner les éléments, s’ils sont dans une certaine zone.
Cette certaine zone s’appelle le frustum, et il a la forme d’une pyramide tronquée au sommet (le sommet étant l’œil). C’est la zone qui est comprise entre l’écran, et une limite au loin qu’on appelle le far plane (l’écran devenant le near plane).

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:

Windows Phone 7 Design Day: tout pour comprendre et vous former au design Metro, le 8 novembre au campus Microsoft

PierreCauchois — Fri, 28 Oct 2011 16:24:34 GMT

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:

10h: Bienvenue!
10h15: metro: the foundation

Comprendre Metro, l’agencement, la typographie, les animations, les spécificités d’une expérience utilisateur sur téléphone
11h: Pause!

11h15: think: sketch, wireframe, prototype

Brainstorming créatif, techniques… la réflexion avant la conception

12h: design: visual, interaction, motion

Le langage visuel, les graphismes, les animations et les patterns d’interactions
12h45: déjeuner!

14h: refine: best practices

bonnes pratiques, amélioration des performances perçues, utiliser les fonctionnalités du téléphone…

14h45: make it XAML

importer du contenu dans Expression Blend, agencer et créer des contrôles…
15h30: pause!

15h45: workshop

démarrer une nouvelle application ou faites vous conseiller sur votre design!

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 et les friday labs : du nouveau pour les développeurs mobiles

PierreCauchois — Fri, 28 Oct 2011 15:37:13 GMT

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:

Des ressources techniques: accès à l’app-hub offert, téléphones à disposition, support…
Du coaching: que ce soit de l’aide sur un point spécifique du développement, ou de la formation plus avancée (et gratuite) on devrait pouvoir vous aider à ne jamais vous sentir bloqué dans votre développement!
De la visibilité: que ce soit à l’évènement Le Web 11, sur Marketplace, ou à travers la réalisation d’une vidéo de promotion de votre application. Faisons en sorte que votre application soit un succès dès sa publication!

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!

[App-Hub // Mango] Finalement, il sera possible de mettre à jour à la fois la version 7.0 et la version 7.1 de votre application sur l’App-Hub

PierreCauchois — Wed, 21 Sep 2011 09:37:39 GMT

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.

[Windows Phone 7] Du contenu pour faciliter la vie des développeurs Nokia

PierreCauchois — Wed, 21 Sep 2011 09:26:59 GMT

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!

Rencontrons-nous aux Microsoft Days pour parler Mango, à Paris ou en régions!

PierreCauchois — Tue, 06 Sep 2011 17:10:37 GMT

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:

Nantes : 28 Septembre
Paris : 4 Octobre
Strasbourg : 13 Octobre
Lille : 19 Octobre
Marseille : 3 Novembre
Lyon : 9 Novembre
Bordeaux : 15 Novembre

Pour vous inscrire il faut aller sur le site des Microsoft Days et s’enregistrer aux rencontre techniques !

[Windows Phone 7–Mango] S’assurer que votre application marchera avec Mango : les “breaking changes”.

PierreCauchois — Mon, 05 Sep 2011 11:35:04 GMT

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.

Le WebClient

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 !).

Le contrôle WebBrowser

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 ScrollViewer (et donc la ListBox)

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.

[Windows Phone 7] Développeurs, avez-vous passé votre téléphone à Mango?

PierreCauchois — Wed, 31 Aug 2011 11:02:59 GMT

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!

[Windows Phone 7] Passage à Mango : Quelle version, pour qui, sur Marketplace?

PierreCauchois — Mon, 29 Aug 2011 15:51:34 GMT

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!

[Windows Phone 7] Les toolkits Silverlight et Coding4Fun passent à Mango!

PierreCauchois — Fri, 26 Aug 2011 13:06:06 GMT

Avec les outils en Release Candidate, les développeurs de toolkits qui fournissent des contrôles supplémentaires au SDK se mettent à jour. A l’occasion du passage de votre application à Mango, pensez à regarder les nouveautés, il y a de bons moyens d’intégrer facilement des nouveaux contrôles et améliorer l’expérience de votre applications!

Le Silverlight Toolkit for Windows Phone

Mis à jour en Août, il propose un tas d’améliorations de performance (notamment le LongListSelector et les transitions, ouf!) mais aussi des nouveautés comme le contrôle HubTile qui permet de recréer l’expérience du start screen dans votre application. Indispensable! En plus il est fournit en source donc vous pouvez vous en inspirer pour dériver vos propres contrôles.

Le Coding4Fun Toolkit for Windows Phone

Livré en source aussi, avec dedans des trucs simples et sympas comme le RoundButton, le TimeSpanPicker (par notre collègue Stéphanie!) ou des popup et des overlays bien sympas. Bref, de quoi pimper votre application!

WP7Contrib

Qui ne contient pas que des contrôles, mais aussi des bouts de code utile implémentant des patterns de caching, de messaging… bref, de quoi améliorer votre application. L’inconvénient de ce toolkit est qu’il est dépendant d’autres (JSON.NET, MVVM Light, etc) et donc c’est un peu compliqué d’évaluer s’il est vraiment Mango Ready… mais ça vaut le coup de le connaitre quoiqu’il arrive!

N’hésitez pas à partager si vous connaissez d’autres toolkits qui méritent d’être cités!!

[Windows Phone 7] le SDK Mango passe en Release Candidate

PierreCauchois — Wed, 24 Aug 2011 09:20:05 GMT

La RC du kit de développement Windows Phone 7 est maintenant disponible sur le download center Microsoft:

Windows Phone SDK 7.1 Release Candidate

La documentation a été mise à jour sur MSDN pour refléter les derniers changements:

Quoi de neuf dans la RC du SDK Mango

On retrouve en vrac l’utilitaire de screenshot, l’utilitaire de tests de Marketplace (qui permet de faire passer votre application aux tests automatisés avant de l’envoyer à la certification), et une belle amélioration du profiler qui permet de tester l’usage de la mémoire dans votre application… mais surtout, ce SDK est compatible avec la build de Mango disponible sur Connect pour les développeurs enregistrés (7712), la build de l’émulateur est finale (7720) et les API sont en version finale, ce qui nous permet, par la même occasion, d’ouvrir le Marketplace à la soumission d’applications pour Mango! Serez-vous prêts pour le lancement?

Update de l’AppHub Windows Phone 7: béta et distribution privée, nouveau SDK pub, nouveau dashboard….

PierreCauchois — Thu, 21 Jul 2011 07:56:32 GMT

Aujourd’hui se lance la version améliorée de l’AppHub, le dashboard développeur qui permet de publier une application sur le Marketplace Windows Phone 7… et c’est une sacrée update! De très nombreux feedbacks de notre communauté ont été intégrés, et la liste des nouveautés est impressionnante:

Nouveaux modèles de distribution d’application: béta privée, et distribution cachée

“Je veux pouvoir faire tester mon application avant de la publier!”

Il est maintenant possible de proposer une beta à des utilisateurs en indiquant leur live ID dans le dashboard, sans passer de certification, et sans débloquer leur téléphone: ils recevront un email, et pourront télécharger l’application et l’utiliser pendant 90 jours. Limitée à 100 utilisateurs, forcément gratuite, et sans mécanisme d’update (i.e.. nouvelle version == nouvelle beta).

“Je veux pouvoir distribuer mon application sans qu’elle soit visible!” ou bien “je veux un marketplace privé!”

Pour ceux qui veulent déployer leur application en privé, il est aussi possible, après certification, de ne pas publier l’application mais obtenir un lien privé, sans contrôle d’accès: à vous de voir ensuite comment vous distribuez votre lien, et faites votre sécurité dans l’application! pas de limite en nombre d’utilisateurs ou en durée d’utilisation, et la possibilité d’utiliser le système d’updates pour pousser les nouvelles versions. il est aussi possible de passer l’application en distribution publique plus tard, et même de choisir si elle sera gratuite ou payante!

Processus d’inscription simplifié pour les développeurs indépendants et les étudiants

“J’en peux plus de Geotrust, ça fait 3 semaines que j’essaye d’ouvrir un compte pour débloquer mon téléphone!”

Pour la catégorie Individual, une simple carte de crédit valide (qu’on rentre de toutes façons au moment de payer l’abonnement) suffit pour valider le compte, plus besoin de passer par le processus Geotrust. Pour les étudiants, le compte sera validé par dreamspark, et l’âge vérifié avec le Live ID, plus besoin de publier une première application, pour que le compte soit validé.

Inscription, soumission d’apps, reporting… un dashboard beaucoup plus clair, avec des informations plus pertinentes

“Je veux comprendre ce qui se passe avec mes applications!”

Toutes les parties du dashboard Marketplace ont été grandement améliorées: le processus d’inscription est plus simple, plus pertinent (par exemple, on ne demande plus de remplir les informations bancaires pour les gens qui publient des applications gratuites). Le processus de soumission aussi bénéficie d’améliorations (le statut de certification est plus explicite par exemple). Enfin le reporting aussi est amélioré: daily downloads, crash counts, graphes consolidés de downloads, et surtout possibilité de les exporter..

Le SDK de pub Microsoft Advertising bientôt disponible dans plus de pays, notamment la France!

“Je veux pouvoir intégrer de la pub dans mon application et toucher des sous-sous!”

Disponible auparavant uniquement aux états-unis, on pourra bientôt intégrer le SDK “officiel” de pub in-app de Microsoft dans les applications, notamment en Europe et en Asie… Vous retrouverez à l’occasion un article sur ce blog pour vous en parler!

Plus de pays pour soumettre des applications, et pour les distribuer!

“Je veux que mon application soit visible par le monde entier!”

Une amélioration sensible pour tous ceux qui publient une application à vocation internationale: vous allez maintenant pouvoir régionaliser votre application pour 19 pays de plus (incluant le Brésil, l’Argentine et la Colombie, l’Inde, l’Afrique du Sud, certains pays d’Europe de l’Est dont la Pologne, la Russie…) et publier votre application depuis 9 pays de plus (dont la Chine, l’Inde, l’Afrique du Sud…). Enfin le global publisher program continue d’être disponible pour tous les pays qui ne sont pas encore listés dans ces listes…

Soumission d’applications pour Mango dès le mois prochain!

“Mon application est prête je veux pouvoir la distribuer aux gens qui ont déjà installé Mango!”

Patience, ça arrive! une version RC des outils devrait arriver d’ici la fin Août et avec ça la possibilité de soumettre des applications sur Marketplace directement à destination des terminaux Mango!

Toutes ces nouveautés sont également détaillées sur le blog officiel des développeurs Windows Phone 7.

Une série de vidéos Supinfo pour vous expliquer comment concevoir une application Windows Phone 7 connectée au cloud

PierreCauchois — Mon, 04 Jul 2011 12:13:07 GMT

Belle initiative de supinfo a lancé sa webtv cette année, les rendez-vous des experts, et qui nous propose une petite série de webcasts sur le développement d’une application Windows Phone 7, avec un backend dans Azure, utilisant WCF, Entity Framework et SQL Azure, avec quelques soupçons de T4 dedans !

Partie 1: le DAL avec Entity Framework et la base Azure

Partie 2 – Avec Mathieu Mezil et Julien Dollon, pour la couche Entities et un peu de T4!

Partie 3 – Julien Dollon sur WCF, l’hébergement dans Azure et Thomas Laurent pour l’application WP7