magnify
formats

Nouveau BLOG

Publié le 01/09/2014 par dans Information

Bonjour à toutes et à tous.

Je viens de monter ma propre société, elle s’appelle GUYZMO et son cœur de métier est le développement d’applications mobiles pour iOS, Android et Windows Phone.

Comme vous pouvez le constater, je reste dans ce que je sais faire le mieux 🙂

Le site de GUYZMO possède son propre blog et c’est donc tout naturellement que je vais maintenant publier dessus.

Je vous invite à m’y retrouver !

A bientôt, depuis le blog de GUYZMO 🙂

 
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments 
formats

Bonne année !!!!

Publié le 01/01/2014 par dans Non classé

Je vous souhaite une très bonne année 2014, qu’elle vous apporte tout ce que vous espérez, et aussi une très bonne santé.

Stéphane.

 
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments 
formats

Invité mystère du podcast LiveTile #36… C’est plus un mystère maintenant !

Vous connaissez le site www.livetile.fr ?

Et bien si vous êtes interessé par les actualités liées à Windows Phone 8 et Windows 8 en situation de mobilité, ce site propose un podcast qui est fait pour vous !

Depuis quelques temps, Christophe Peugnet, alias TossNet, a rejoint l’équipe de LiveTile en tant que chroniqueur et propose une chronique sur le développement Windows Phone 8. Vous voyez déjà où je veux en venir…

Pour info, TossNet est le papa de quelques applications bien connues sur le store Windows Phone, telles que Monster Photos, GhostCam, SumSnake, Music Test, Celebry Test, ou encore Almanach, pour ne citer que les plus connues.

TossNet est aussi très actif sur le groupe Facebook des développeurs Windows Phone francophones et sa bonne humeur quotidienne est un vrai bol d’air frais.

A chaque nouvel épisode de LiveTile, TossNet invite une personne fortement liée au développement Windows Phone. Cet invité reste anonyme le plus longtemps possible car vous l’avez compris, c’est l’invité mystère de LiveTile.

Dans le dernier épisode, le 36, j’étais l’invité mystère !

Je vous invite donc à écouter cet épisode 36, ainsi que tous les autres de LiveTile. Vous allez y appendre plein de choses intéressantes sur le monde Windows Phone, et pas que du coté développement, du coté usage aussi.

Merci encore à TossNet, Guillaume, et toute l’équipe de LiveTile, qui m’ont invité et surtout qui m’ont fait découvrir une très belle expérience sur la préparation d’un podcast de qualité sur un sujet qui me passionne.

Vous vous demandez pourquoi le titre de l’épisode 36 est « Le 3 c’est mieux ! », et bien je vous laisse le découvrir en l’écoutant car si vous le ne faites pas, ça restera un mystère…

 
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments 
formats

The Voice

The Voice est un dictaphone que j’ai développé pour Windows Phone 7 et 8

The Voice

Contrairement à beaucoup d’autres enregistreurs présents sur le store Windows Phone, The Voice est capable d’enregistrer pendant des heures sans souffrir de problèmes de mémoire.

Il fonctionne même sous l’écran de verrouillage et vous pouvez sauvegarder vos mémos sur Skydrive.

Sa fiche sur le Windows Phone Store.

 

 
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
5 Comments  comments 
formats

Donner un titre à vos pages comme dans Bing News

Si votre téléphone est un Windows Phone, vous avez très certainement installé l’application « Bing News » ou en français « Bing Actualités ».

Si vous ne l’avez pas encore fait, je vous la conseille vivement, c’est une application permettant une lecture très agréable de news provenant de différentes sources.

L’application « Bing News » affiche un bandeau rouge avec son nom dans la barre de statut. On y voit donc en permanence le nom de l’application et l’heure.

La barre de statut de Bing News

Si vous touchez la barre de statut, les autres informations (niveau du réseau téléphonique, connexion Wifi, Bluetooth, etc…) apparaissent normalement pour laisser au bout d’un instant de nouveau la place au bandeau précédent.

Je me suis demandé alors comment faire la même dans mes propres applications, car je trouve cette manière de présenter les choses bien à mon goût.

Tout le secret se trouve dans l’utilisation un peu détournée d’un « ProgressIndicator » qui permet habituellement d’afficher dans la barre de statut la progression d’un traitement.

Généralement il affiche un message et une barre de progression et on l’affiche uniquement pendant certains traitements un peu long comme dans l’image suivante tirée de la super application RadioMeuh (si si elle est super bien cette application) :

Un ProgressIndicator en action

Le truc pour utiliser un « ProgressIndicator » comme titre d’application est simplement de ne pas afficher la barre de progression.

Le seul moyen de ne pas afficher la barre de progression, c’est de ne pas la mettre en mode « Indeterminate ». Elle se comportera alors comme une barre de progression classique et affiche quelque chose uniquement si vous placez une valeur supérieure à zéro dans sa propriété « Value ».

Il ne faut pas oublier aussi de donner à la barre de statut (le SystemTray pour les intimes) la bonne couleur de fond et la bonne couleur de police.

Personnellement, je place l’initialisation du titre dans le constructeur de la page :

public MainPage()
{
    InitializeComponent();

    var wTitle = new ProgressIndicator();
    wTitle.Text = "Mon Titre";
    wTitle.IsIndeterminate = false;
    wTitle.IsVisible = true;

    SystemTray.SetIsVisible(this, true);
    SystemTray.SetBackgroundColor(this, Colors.Red);
    SystemTray.SetForegroundColor(this, Colors.White);
    SystemTray.SetProgressIndicator(this, wTitle);
}

 
Et voilà, un titre de page qui ne tient pas de place et qui est en plus sympa.

J’espère que cette petite astuce vous aidera dans vos propres développements.

 
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments 
formats

Communiquer avec un GPS Bluetooth, quelques améliorations

Dans un précédent article j’ai abordé la communication avec un périphérique Bluetooth en utilisant comme exemple la communication avec un GPS.

Comme j’étais en train de découvrir la nouvelle manière de lire des données en provenance d’un socket (StreamSocket) je n’avais pas utilisé la manière la plus simple ni la plus efficace.

Dans ce nouvel article, je vais apporter quelques améliorations à la méthode utilisée.

En creusant encore un peu le sujet, je me suis rendu compte que ma méthode était loin d’être la meilleure. Et tant mieux car perso je n’en étais pas super satisfait.

En 1er lieu, il faut passer par un DataReader pour lire les données en provenance du StreamSocket. On donne au DataReader l’InputStream utilisé par le StreamSocket pour collecter les données entrantes et on paramètre de DataReader pour qu’il effectue une lecture partielle des données.

 

DataReader wReader = new DataReader(_StreamSocket.InputStream);
wReader.InputStreamOptions = InputStreamOptions.Partial;

En d’autres termes, si on demande de lire 100 octets et qu’il n’y en a que 50 dans le buffer d’entrée, le DataReader va lire les 50 octets et rendre la main au lieu d’attendre la vie des rats que les 100 octets soient effectivement disponibles. Ca arrange bien nos affaires cette histoire.

La lecture en elle-même est très simplifiée. Il suffit de dire combien on veut lire d’octets maximum et on reprend la main quand on a lu au maximum ce nombre d’octets. Simple et rapide.

La fonction de lecture est asynchrone, donc pour l’attendre on n’oublie pas de placer le petit await qui va bien devant. La fonction retourne le nombre d’octets effectivement lus.

Si elle retourne zéro c’est que rien n’était disponible dans le buffer d’entrée. Suivant les matériels connectés ça peut vouloir dire qu’il ne cause plus pour le moment (il boude par exemple) ou alors qu’il n’est plus connecté. Dans le cas d’un GPS, qui est je vous le rappelle un appareil très bavard, le fait de ne plus recevoir de données signifie souvent qu’il n’est plus là pour le faire.

 

// Lecture de 300 octets
uint r = await wReader.LoadAsync(300);

Une fois qu’on a des données disponibles dans le buffer d’entrée, il suffit d’aller les récupérer de la manière qui convient le mieux en utilisant le DataReader et ses fonctions de récupération (ReadByte, ReadBytes, ReadDouble, etc…). C’est lui qui s’occupe d’aller puiser le bon nombre d’octets dans le buffer d’entrée pour récupérer les informations dans le format que vous souhaitez (sympa le mec).

Dans le cas du GPS nous devons récupérer les données sous la format de caractères ASCII. Malheureusement la méthode ReadString ne convient pas car elle lit la chaîne en UTF8 ou en Unicode, mais ne sais pas le faire en ASCII. En fait le format ASCII a été retiré des formats proposés dans System.Text.Encoding. Quelle idée ???

Donc nous allons récupérer les octets comme si c’était de simples caractères ASCII et construire une chaîne ASCII, à la mano, comme le faisait mon grand père.

 

// On prépare le buffer de réception
// La variable r contient le nombre d'octets lus du StreamSocket

byte[] wBuffer = new byte[r];

// On récupère les données 

wReader.ReadBytes(wBuffer);

// On transforme ces données en string ASCII

string wString = "";

for (int i = 0; i < r; i++)
{ 
    wString += (char)wBuffer[i];
}

// Dans wString on a maintenant les données lues sous forme d'une chaîne de caractères

Ensuite il suffit de traiter ces informations comme dans l’article précédent pour afficher les trames NMEA envoyées par le GPS.

Il suffit alors de reboucler pour lire le flot suivant de caractères et le tour est joué. Plus besoin de timer pour effectuer la lecture à intervalles réguliers. On est toujours en mode pooling car nous ne sommes pas notifié de la disponibilité de nouveaux octets dans le buffer d’entrée, mais ce pooling-ci est plus « souple » que celui que je vous avais précédemment proposé.

Idéalement, il faudrait gérer un timeout. En effet, comme expliqué un peu plus haut, quand le périphérique est déconnecté, il cesse d’envoyer des données, mais aucune erreur n’est levée au moment où l’on essaye de notre coté de lire de nouvelles données, on n’a seulement comme indice le fait que la fonction de lecture du DataReader retourne zéro.

Au bout d’un certain temps, il sera donc nécessaire d’en conclure que la liaison est rompue. La durée de ce timeout dépendra du comportement « normal » du périphérique auquel vous êtes connectés. Par exemple, pour le GPS Hollux que j’ai utilisé, une absence de données pendant plus d’une seconde n’est pas normale, le timeout sera donc compris en 1000 et 1500 millisecondes.

Si j’en ai le courage, j’ajouterai ce timeout dans un prochain article. En tous cas, si cela vous intéresse, n’hésitez pas à me le demander, ce sera pour moi la meilleure des motivations.

Sources de cet article.

 

 

 
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments 
formats

Communiquer avec un GPS Bluetooth sous Windows Phone

A l’époque de Windows Mobile, communiquer avec un périphérique en utilisant une liaison série était quelques chose de très simple à mettre en œuvre. Le système d’exploitation intégrait tout ce qu’il fallait pour ouvrir un port série et permettre l’envoi et la réception de données par ce canal. Simple, ouvert, pratique.

Dans les 1ères versions de l’OS mobile de Microsoft, du temps de Pocket PC 2000 sous Windows CE 3 par exemple, la liaison série était physiquement réelle. On branchait un câble qui reliait le PDA avec le périphérique, comme on peut le voir dans cet exemple de borne interactive animée par un Pocket PC que j’ai mis en ligne en 2001. Le programme était réalisé en eVB (ça ne me rajeunit pas cette histoire).

Ensuite, avec la démocratisation du Bluetooth, les machines ont été en mesure de créer des liaisons séries virtuelles, le câble ayant été remplacé par les ondes radio. Classiquement, à cette époque, on se connectait avec des GPS Bluetooth car les machines sous Windows Mobile n’intégraient pas encore de puce GPS, il fallait donc passer par des appareils externes pour être en mesure de proposer une géolocalisation et de la carto.

A l’époque j’avais d’ailleurs écrit un article sur la manière de se connecter à un GPS et être en mesure de décoder les trames NMEA qu’il crachait périodiquement et pour le TechDays 2008 j’avais présenté une application permettant de prendre des photos géolocalisées avec la possibilité de les afficher sur une carte. Et oui à l’époque ça en a impressionné plus d’un, maintenant c’est d’une grande banalité je vous l’accorde.

Pour moi la sortie de Windows Phone fût un grand choc. Belle plateforme, belles et puissantes machines, fluidité, design moderne, en gros que du bonheur par rapport à la plateforme Windows Mobile. Mais en creusant un peu, quel retour en arrière sur certains points ! Certes les machines intégraient nativement une puce GPS et le SDK permettait d’en tirer partie, mais impossible par exemple d’ouvrir une liaison série (réelle ou virtuelle), impossible de créer un socket serveur, impossible de faire plein de choses qui étaient devenues si naturelles avec l’ancienne plateforme… Allez expliquer ça à vos clients qui vous demandent de porter leurs anciennes applications Windows Mobile vers Windows Phone. Dans certains cas impossible de le faire, et on passe donc à Android où là il n’y a rien qui s’y oppose.

Avec le recul je comprends très bien pourquoi les choses ont été faites comme ça, mais je dois bien avouer qu’à l’époque MS a pourri une partie importante de mon business avec ces conneries !

Dans certains cas il est indispensable d’avoir plusieurs GPS en même temps. Par exemple, si vous faites du GPS différentiel, vous ne pouvez vous contenter d’utiliser celui inclus dans le device, vous devez collecter les données de plusieurs GPS et effectuer des traitements en temps réel pour arriver à une précision de positionnement de l’ordre du cm par exemple. De plus vous ne pouvez vous contenter de récupérer simplement la position (latitude, longitude), vous devez aussi récupérer des données très importantes sur le niveau de précision, le nombre de satellites en vue et j’en passe. Je ne vais pas entrer dans le détail du GPS différentiel ce n’est pas le but de cet article.

Donc avec Windows Phone, si vous voulez faire du GPS différentiel vous êtes cuit. Sauf depuis la sortie de Windows Phone 8 qui a ouvert encore un peu plus le périmètre des libertés anciennes (Windows Mobile) retrouvées.

Avec Windows Phone 8 vous avez la possibilité de créer un socket entre votre application et un périphérique Bluetooth. Donc pour faire simple, on peut communiquer très facilement en Bluetooth avec par exemple… un GPS, et même plusieurs GPS en même temps ! Ca y est, 3 ans après la sortie de la plateforme Windows Phone, je peux dire à mes clients qu’il peuvent abandonner Android et revenir dans le droit chemin sous Windows Phone ! Sauf que pour eux maintenant c’est trop tard, ils sont passés à Android et ne reviendront pas en arrière. En effet il n’ont pas la capacité financière de faire redévelopper toutes les 5 minutes leurs applications mobiles.

Je vais donc dans cet article vous montrer comment dialoguer avec un GPS en Bluetooth et vous allez voir que c’est assez simple à faire.

Le petit programme GpsBT que j’ai réalisé pour l’occasion permet de faire 3 choses :

  1. Lister les appareils liés en Bluetooth
  2. Sélectionner un appareil et s’y connecter
  3. Afficher les trames NMEA envoyées par le GPS

Les sources de GpsBT sont disponibles ici.

1/ Les droits

La 1ère chose à faire, c’est de donner à votre application les droits pour utiliser les fonctions Bluetooth :

ID_CAP_PROXIMITY

ID_CAP_NETWORKING

2/ Lister les appareils liés

Il faut partir à la découverte des appareils liées. Ces appareils sont ceux qui sont listés dans l’écran des settings du Bluetooth et qui ont été liés à votre téléphone par une opération d’appairage. On ne peut se connecter qu’avec un appareil qui a été au préalable lié et impossible dans l’état actuel du SDK de provoquer par programme ce lien.

        private async void BouPeerDiscovery_Click(object sender, RoutedEventArgs e)
        {
            BouPeerDiscovery.IsEnabled = false;

            PeerFinder.AlternateIdentities["Bluetooth:Paired"] = "";

            try
            {
                var wPairedDevices = await PeerFinder.FindAllPeersAsync();
                this.ViewModel = new MainPageViewModel(wPairedDevices.ToList());
                BouPeerDiscovery.Visibility = System.Windows.Visibility.Collapsed;
            }
            catch (Exception ex)
            {
                MessageBox.Show(ex.Message, "Peer Discovery", MessageBoxButton.OK);
                BouPeerDiscovery.IsEnabled = true;
            }
        }

La liste des appareils liés est retournée par la fonction PeerFinder.FindAllPeerAsync. Dans mon exemple, la liste est fournie au ViewModel de la page pour un affichage dans une liste comme dans l’écran suivant :

Le GPS que j’utilise est le Holux GR-230, c’est donc à lui que je vais essayer de me connecter. Il ne faut pas oublier au préalable de le mettre en route, bien sûr.

3/ Connexion à un appareil

La fonction permettant de lister les appareils disponibles retourne pour chacun d’entre eux un objet de type PeerInformation. Parmi les informations disponibles, on a le DisplayName qui est le nom en clair (celui que j’utilise dans la liste), et le HostName qui sera utilisé pour effectuer la connexion.

La connexion est réalisée via un objet de type « StreamSocket » en utilisant sa méthode asynchrone « ConnectAsync » avec en premier paramètres le HostName provenant du PeerInformation de l’appareil auquel on veut se connecter et la chaîne 1 en second paramètre (je ne sais pas vraiment à quoi correspond ce second paramètre, dans tous les exemples de la documentation la valeur utilisée est la chaine 1 alors va pour ça).

        public async Task ConnectAsync(PeerInformation wPeer)
        {
            // Si un précédent device était déjà connecté, on débranche

            if (_StreamSocket != null)
            {
                _ScanGpsTimer.Stop();

                _StreamSocket.Dispose();
                _StreamSocket = null;
            }

            // On essaye de se connecter au device

            _StreamSocket = new StreamSocket();

            try
            {
                await _StreamSocket.ConnectAsync(wPeer.HostName, "1");

                // Pas d'erreur ?
                // Alors c'est qu'on est connecté
                // On peut mettre en place le scan des données qui arrivent du device

                _CurrentGpsInput = "";
                this.DeviceName = wPeer.DisplayName;
                _ScanGpsTimer.Start();
            }
            catch (Exception ex)
            {
                // Erreur pendant la connexion

                _StreamSocket = null;
                return ex;
            }

            return null;
        }

Ma petite fonction de connexion, placée dans le ViewModel de la page, retourne l’erreur rencontrée en cas de problème ou null si tout c’est bien passé.
Si la connexion se passe bien, on passe en mode pooling dans lequel on va lire à intervalle régulier le contenu du buffer d’entrée du StreamSocket. Si des données sont disponibles, elles sont lues et partant du principe que ce sont des trames NMEA, elles sont « découpées » pour être affichées dans une liste.

C’est un DispatcherTimer qui s’occupe d’effectuer les lectures à intervalles régulier :

        private async void OnScanGpsTimerTick(object sender, EventArgs e)
        {
            if (_StreamSocket != null)
            {
                _ScanGpsTimer.Stop();

                // Lecture des données

                var wBuffer = new Windows.Storage.Streams.Buffer(100);
                await _StreamSocket.InputStream.ReadAsync(wBuffer, 100, Windows.Storage.Streams.InputStreamOptions.None);

                if (wBuffer.Length > 0)
                {
                    // On a bien des données

                    using (var wReader = DataReader.FromBuffer(wBuffer))
                    {
                        // On prépare le buffer de réception 

                        byte[] wBuffer2 = new byte[wBuffer.Length];

                        // On récupère les données 
                        wReader.ReadBytes(wBuffer2);

                        // On transforme ces données en string

                        string wString = System.Text.Encoding.UTF8.GetString(wBuffer2, 0, wBuffer2.Length);

                        // On ajoute ces données aux trames générales reçues du GPS

                        _CurrentGpsInput += wString;

                        // On essaye de découper la trame générale en lignes NMEA

                        int p;

                        do
                        {
                            // On recherche les caractères CRLF

                            p = _CurrentGpsInput.IndexOf("\r\n");

                            if (p > -1)
                            {
                                // On récupère le début (avant les caratères CRLF)

                                string wDebut = _CurrentGpsInput.Substring(0, p);

                                // On enlève cette partie de la trame générale

                                _CurrentGpsInput = _CurrentGpsInput.Substring(p + 2);

                                // Généralement une trame NMEA valide commence par $GP

                                if (wDebut.StartsWith("$GP"))
                                {
                                    // On ajoute la partie à la liste des trames NMEA

                                    this.GpsNmea.Add(wDebut);

                                    // On ne garde que les 25 dernières trames NMEA dans la liste

                                    while (GpsNmea.Count > 25) { GpsNmea.RemoveAt(0); }
                                }
                            }

                        } while (p > -1);
                    }
                }
                else
                {
                    // Aucune donnée n'a été lue, si ça dure trop longtemps cela voudra dire
                    // Que le device ne communique plus ou qu'il n'est plus connecté
                    // Dans la vraie vie, c'est un cas qu'il faut traiter
                }

                _ScanGpsTimer.Start();
            }
        }

Voilà, la boucle est bouclée, nous avons réalisé toutes les opérations pour se connecter à un GPS Bluetooth depuis un device Windows Phone 8.

Comme vous pouvez le constater, c’est très simple à mettre en œuvre. Mon seul regret étant de devoir effectuer du pooling pour récupérer les données.

Il y a peut-être le moyen de se « brancher » sur un événement du StreamSocket ou du InputStream sous-jacent, mais je dois vous avouer que je n’ai pas encore pris le temps de creuser cette piste pour le moment.

 
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
3 Comments  comments 
formats

Editeur d’applications Windows Phone, qu’en dire après 10 mois ?

Publié le 19/10/2013 par dans Windows Phone

Depuis la sortie de la plateforme Windows Phone, j’ai eu plusieurs fois l’occasion de réaliser des applications pour mes clients.

Ce n’était donc pas mes applications mais leurs applications… Pas pareil !

Alors depuis janvier 2013 j’ai décidé de publier mes propres applications pour Windows Phone.

Pour le fun uniquement, et je dois bien avouer que je me suis pris au jeu !

Le mot « éditeur » semble pompeux, mais quand on y regarde de plus près c’est exactement ce que l’on est quand on publie une application sur le store Windows Phone !

Actuellement j’ai 6 applications publiées :

Quand vous développez votre première application pour Windows Phone, une idée revient tout le temps :

Ce que je suis en train de réaliser, le monde entier pourra y avoir accès !

Et oui ! Grâce au store vous développez des applications qui seront présentes dans 192 marchés ! Cela correspond à des millions de téléchargements potentiels, ça fait tourner la tête au début et ça donne envie d’en profiter !

Une fois que votre application est développée, que vous l’avez testé sous toutes les coutures, qu’elle vous semble prête à s’envoler, vous devez la publier.

Là les choses se corsent un peu, car avant elle va passer par une phase de validation. Cette validation est réalisée par de vraies personnes, employées par Microsoft, pour vérifier que l’application fonctionne correctement, qu’elle suit les guidelines de l’éditeur, et qu’elle ne fait rien qui pourrait nuire à ses futurs utilisateurs.

La première fois qu’on publie une application et qu’on attend qu’elle soit validée (ou refusée), ça fait flipper, un peu comme quand on attend les résultats d’un examen.

En ce qui me concerne, la première publication fut la bonne. Au bout de quelques jours (max 5) j’ai reçu un mail qui m’indiquait que mon application avait passé les tests avec succès et qu’elle était publiée pour de bon !

Vient ensuite le rituel du compteur. Vous ne pouvez pas vous empêcher d’aller voir (souvent) le compteur de téléchargement et les évaluations faites par les utilisateurs. C’est maladif, une vraie drogue ! Le pire c’est que les données statistiques ne sont pas mises à jour en temps réel mais avec un décalage qui varie souvent. Parfois on a les infos qui s’arrêtent la veille, ou alors 3 jours avant ! Du coup on est un peu frustré au début, et puis on s’y fait (comme pour tout bien sûr).

La lecture des évaluations laissées par les utilisateurs est une activité que je trouve très récréative et très importante car elle permet de récolter beaucoup d’informations pour comprendre ce qu’il faut améliorer dans l’application pour qu’elle ait encore plus de succès. Les commentaires sont laissés dans toutes les langues, mais Microsoft a eu la bonne idée de les traduire à la volée pour une meilleure compréhension. C’est assez drôle de voir défiler des commentaires en russe, en allemand, en anglais et parfois en français…

Le choix de la langue par défaut est un paramètre très important. Au début on n’y pense pas. On crée l’application avec le français comme langue par défaut et on publie. Et puis on se rend compte que si l’application avait été plutôt en anglais elle aurait eu plus de succès (logique mais par forcément évident au début). Alors on localise l’application en anglais (langue par défaut) et on laisse le français qui est déjà en place comme langue secondaire. Il vaut mieux faire ça dès le début, c’est bien plus simple et rapide.

Une fois que la localisation est terminée, et suite à une nouvelle publication réussie, les résultats ne se font pas attendre, les téléchargements doublent ou triplent en très peu de temps. L’effet magique de la langue anglaise face au français !

J’ai créé Tempo, FreeBubbles, Cérébro et RadioMeuh seulement en français, alors que BigContacts et The Voice ont été dès le début localisées en anglais et en français avec l’anglais comme langue par défaut. Pour bien faire, il faudrait que je les localise toutes. Autant pour FreeBubbles, Cérébro et RadioMeuh ça ne devrait pas être trop problématique (pas beaucoup de texte à traduire), autant pour Tempo la tâche ne sera pas simple. Il y a beaucoup de texte et pas mal de phrases techniques qu’il me sera difficile de traduire correctement.

D’ailleurs pour BigContacts, Nokia m’a donné un coup de main. Ils m’ont offert la traduction en anglais, espagnol, italien et russe. Sympa non ? C’est arrivé car je suis inscrit au programme développeur Nokia et parce qu’ils ont remarqué que BigContacts était pas mal téléchargé. Du coup j’ai eu droit (comme beaucoup d’autres développeurs inscrits) à ce sympathique coup de pouce.

La traduction reste tout de même un soucis. Je suis en train de préparer une nouvelle version de BigContacts, du coup je dois maintenant traduire tous les nouveaux termes en anglais, espagnol, italien et russe… Je ne suis pas sorti d’affaire et Nokia de son coté ne va pas non plus effectuer une traduction gratuite à chaque nouvelle version. Du coup ce qui était à la base un super cadeau, devient un gros problème à gérer. Comme quoi on ne peut pas tout avoir non plus.

La communauté développeurs Windows Phone francophone , incarnée par un groupe Facebook très actif, est un maillon important. Elle a été initiée par Rudy Huyn, le développeur Windows Phone français le plus connu dans le monde (papa des applications phares 6Tag, 6Sec, Wikipédia, etc…) et grand vainqueur d’un nombre incalculable de concours tournant tous autours de Windows Phone. Il s’est lancé dans l’aventure il y a 2 ans 1/2 et il incarne la réussite absolue dans ce domaine.

Cette communauté (dont je fais bien entendue partie) est composée de membres ayant globalement tous le même profil, celui d’un développeur Windows Phone, créant des applications pour lui-même ou l’entreprise qui l’emploie. Il y a actuellement un peu moins de 1700 membres et elle grandit un peu plus chaque jours. Ce genre de regroupement est très important et très utile. Il permet à un maximum de personnes de trouver des réponses rapides et fiables à des problèmes qu’ils rencontrent tous les jours. Je sais de quoi je parle, en son temps j’ai créé et animé pendant 10 ans la communauté équivalente pour Windows Mobile (6500 membres dans les forums de CodePPC).

Microsoft propose aussi des solutions pour aider les développeurs à produire des applications de qualité en nombre. Il propose par exemple le programme Accélérateur Windows Phone qui a pour mission d’aider les développeurs en leur donnant des ressources, du coaching et de la visibilité. Grâce à ce programme, certaines de mes applications on été mise en avant plusieurs fois, et à chaque fois les compteurs de téléchargement s’affolent ! La mise en avant (généralement pendant une journée) sur le store est un manière très efficace de promouvoir une application.

Comme beaucoup de développeurs j’ai été tenté de mettre des bandeaux de publicité dans mes applications. Finalement, pourquoi ne pas le faire, l’application est gratuite, c’est donc un moyen  de récolter un peu de monnaie. Il est très simple d’ajouter de la publicité dans un écran. Microsoft propose même d’intégrer sa propre régie publicitaire (Microsoft Advertising PubCenter) qui semble sur le papier être très rentable par rapport à d’autres régies.

Le problème c’est que pour que ça gagne un peu il faut des dizaines et même des centaines de milliers d’affichages et surtout que la publicité reste affichée assez longtemps pour être comptabilisée comme une vraie vue. Du coup ça limite l’usage principalement aux jeux (dans lesquels on reste sur le même écran longtemps) avec un nombre d’affichages assez conséquent, sans quoi vous aurez l’extrême joie de ne gagner que quelques centimes d’euros par jour.

Vous pouvez aussi proposer une application payante avec une version d’essai gratuite. Si l’utilisateur achète l’application, on n’affiche plus la pub, et on active certaines fonctions bloquées en version d’essai. C’est pas mal comme méthode (Tempo, FreeBubbles et The Voice fonctionnent sur ce principe).

Mais l’idéal aujourd’hui semble de proposer des applications gratuites avec la possibilité d’ajouter des fonctionnalités payantes que l’on peut acheter après coup, au fur et à mesure des besoins, et ce sans quitter l’application (achats InApp). C’est le modèle qui semble le plus efficace aujourd’hui (et quelle que soit la plateforme).

Alors éditeur d’applications Windows Phone, qu’en dire après 10 mois ? Et bien que cette plateforme est promise à un bel avenir, et que développer pour elle aujourd’hui semble être un moyen de réaliser de très belles choses et pour certains (dont je ne fais pas partie) d’en vivre de manière assez confortable.

Alors perso je vais continuer à faire évoluer mes applications et à en créer de nouvelles aussi, car l’acte de création est la chose que j’aime le plus dans ce beau métier qu’est celui de concepteur d’application mobiles destinées au monde entier.

Alors fier d’être développeur et avec Windows Phone, fier d’être aussi mon propre éditeur !

 
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
2 Comments  comments 
formats

Comprendre les icônes de votre Windows Phone

Publié le 08/07/2013 par dans Windows Phone

Les icônes de la barre de statut de Windows Phone

Comme tout téléphone qui se respecte, Windows Phone possède une barre des statut sur laquelle sont affichés, entre autres, l’heure, le niveau de batterie, le niveau de réception du signal GSM, etc…

Pour en connaître toutes les facettes je vous invite à lire cet article.

 
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments 
formats

Tempo, mis en avant sur Microsoft Frogz

Publié le 03/07/2013 par dans Tempo, Windows Phone

Vous ne le savez peut-être pas encore, mais je suis le papa de l’application Windows Phone Tempo.

Tempo permet de comptabiliser le temps que vous passez sur vos différents projets pro et/ou perso.

Le mode « décompte » permet de comptabiliser le temps passé même lorsque Tempo est arrêté et/ou le téléphone en veille.

Vous pouvez à tout moment demander le temps passé sur un projet précis, avec ventilation par tâche, mais aussi avec le détail de chaque opération.

Vous pouvez aussi demander un relevé de votre activité pour différentes périodes prédéfinies (semaine en cours, semaine précédente, mois en cours…) ou en bornant les dates.

Tous les rapports affichés peuvent être envoyés par email depuis l’application.

Une sauvegarde/restauration Skydrive est aussi prise en charge.

 

Aujourd’hui, Tempo est mise en avant sur le site Microsoft Frogz.

D’autres site ont déjà parlé de Tempo dans le passé :

MonWindowsPhone

SmarphoneFrance (bonjour au passage à Christophe son webmaster).

 

 

 

 
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
1 Comment  comments