Règle « Association d’URI » pour le concours « Docteur Souris »

Nokia organise via DVLUP un concours qui me tient particulièrement à cœur puisqu’il s’agit de faire une bonne action en amusant les enfants et adolescents des hôpitaux par le biais d’application sur téléphone et tablette (Windows Phone et Windows).

Comme Nokia a également un grand cœur il permettra de gagner des téléphones dernière génération ou des points DVLUP (Chouette !).
Faisant partie du jury je ne pourrai malheureusement pas participer au concours mais je me frotte les mains en pensant aux futures applications présentées.

Trêve de bavardage, pour participer et connaitre les règles du concours rendez-vous directement à cette url :
https://www.dvlup.com/Challenge/599

Une dernière règle importante

Parmi les quelques règles énoncées sur DVULP il en manque une sur le site DVLUP (pour le moment) particulièrement importante :

Les applications doivent impérativement associer une URI du type :
masuperapp:docteursouris
ou masuperapp sera le nom de votre application.

Dans le cas où le nom de votre app correspondrait à un schéma réservé (http: par exemple) vous pouvez le remplacer par le schèma de votre choix.

Mais pourquoi cette règle ?

Le but ultime de ce concours est d’obtenir une application « Docteur Souris » capable de lancer d’autre apps les applications de ce concours.
Or pour lancer des apps à partir d’une autre app, il faut qu’elles soient pourvues d’une association d’URI.

En suivant ce lien vous trouverez, en détail, comment implémenter cette association d’URI :
http://msdn.microsoft.com/fr-FR/library/windows/apps/xaml/hh779670

et un exemple complet ici :
http://code.msdn.microsoft.com/windowsapps/Association-Launching-535d2cec/

Conclusion

Ne passer pas à côté de cette règle importante du concours car elle seul permettra aux enfants de s’amuser sur nos smartphones et tablettes en toute simplicité.
Bon courage et à vos clavier !

PS: Un grand merci à Kévin Trélohan pour l’idée et la mise en place de ce concours avec l’aide toujours efficace et conviviale d’Olivier Lovisa de chez Nokia. Une spécial dédicace pour Franck Nguessan qui s’occupe de la réalisation de l’application lanceur « Docteur Souris ».

0  

Connectivity version 12 pour WP8.1



« Microsoft.Smartdevice.Connectivity » est une librairie fournit par Microsoft qui permet de se connecter à Windows Phone (device ou emulateur) afin gérer les applications développeurs (installation, désinstallation, lancement) et de lire leurs IsolatedStorages.

Si vous êtes intéressé par le fonctionnement de base de cette DLL, vous pouvez relire cet article sur le sujet

La nouvelle version de Connectivity vient d’arriver avec le SDK WP8.1, c’est le moment de faire le point sur les nouveautés.
Malheureusement, cette librairie n’a pas, à ma connaissance, de page officielle mise à jour sur MSDN.
Je vais donc vous livrer les informations que j’ai pu recueillir en la décompilant et qui m’ont servies à mettre à jour mon application IsoStoreSpy.

De nouvelles racines

Globalement, la librairie fonctionne de la même manière que ses prédécesseurs mais une différence de taille est venu se glisser dans cette release.
En effet, Il est possible d’accéder, sous certaines conditions, à d’autre répertoire que celui de l’isolatedStorage.
Dans les cadres des applications WP8.1, trois racines sont désormais accessibles (contre une auparavant) :

- « Local » qui représente l’IsolatedStorage classique (valeur par défaut)
- « Roaming » qui permet d’accéder au données du Roaming
- « Temp » qui est un dossier temporaire

On accède donc à l’IsoStore en ajoutant simplement la chaine d’une des racines à la méthode GetIsolatedStore :

// WP8 old Style:
// var storage = SelectedApplication.GetIsolatedStore();

// WP8.1 new Style :
var storage = SelectedApplication.GetIsolatedStore("Roaming");

Et les apps WP8 ?

Malheureusement, les racines « Roaming » ou « Temp » ne sont pas accessibles des applications WP8 même sur un device WP8.1 (ce qui est facilement compréhensible vu qu’il n’y a pas d’accès niveau code).

Il faut donc une manière simple de détecter qu’une app est compiler pour WP8 ou pour WP8.1.

On va utiliser ici l’exception ArgumentException générer par l’accès aux méthodes de Connectivity dans un contexte de Roaming.

        public bool IsSelectedApplicationIsWP8
        {
            get
            {
                if( _IsSelectedApplicationIsWP8 == null )
                {
                    try
                    {
                        this.SelectedApplication.GetIsolatedStore("Roaming").GetDirectoryListing(string.Empty);
                        _IsSelectedApplicationIsWP8 = false;
                    }
                    catch (ArgumentException)
                    {
                        _IsSelectedApplicationIsWP8 = true;
                    }
                }

                return _IsSelectedApplicationIsWP8.Value;
            }
        }

        private bool? _IsSelectedApplicationIsWP8 = null;

On n’a plus qu’a tester IsSelectedApplicationIsWP8 pour voir si l’on peut afficher ou non les racines complémentaires.

Des chemins d’accès modifiés

Les chemins d’accès au répertoires et fichiers ont également été modifiés par l’utilisation de ces nouvelles racines :

ainsi pour les devices WP8 la racine de base de l’application était la suivante :

string root = @"%FOLDERID_APPID_ISOROOT%\" + APP_PRODUCT_ID + "\"

elle devient celle ci pour WP8.1 :

string root = @"%FOLDERID_APPID_ISOROOT%\" + APP_PRODUCT_ID + "\" + RACINE + "\" 

la chaine APP_PRODUCT_ID represente le GUID de l’app et RACINE une des chaines suivantes :

- « %LOCL% » pour la racine Local
- « %ROAM% » pour la racine roaming
- « %TEMP% » pour la racine temp

Détruire des fichiers

Une coquille c’était glisser dans la dernière version de Connectivity pour WP8. Il était impossible de détruire des fichiers.
C’est ennuyeux mais heureusement cette fonctionnalité est de nouveau opérationnelle !

conclusion

Je me doute que cet article ne servira qu’a très peu de personnes vu la nature des services de cette librairie mais sachez que plusieurs Bothans sont morts pour nous fournir ces informations.
Ca calme.

0  

Retour d’expérience : Passage d’une app Windows Phone Silverlight 8.0 à 8.1

La nouvelle mouture de Windows Phone 8.1 présentée hier à la Build est aussi riche en features pour les utilisateurs que pour les développeurs.

Afin de profiter des nouveautés offertes par WP8.1 j’ai donc voulu mettre une de mes applications les plus complexes à niveau.

Cette application est un bon test puisqu’elle contient des librairies C++/CX ainsi que du code C# plus classique.

Une fois Visual Studio 2013 Update 2 RC installé et exécuté, je me lance dans l’aventure!

Transformation !

Pour plus de sécurité, il est de bon ton de faire une copie du dossier de son app. On ne sait jamais.

Puis, on commence la migration de notre application vers Silverlight 8.1 (oui on a plus peur de dire Silverlight).

Pour ce faire, il suffit de cliquer droit sur la solution puis dans le menu lancer « retarget solution ».

Il est également possible d’effectuer cette migration projet par projet.

Une fenêtre apparaît ensuite nous signalant que la conversion est à sens unique.

Retarget

Il ne nous reste plus qu’à cliquer sur OK et, quelques secondes plus tard, notre projet est mise à jour :

RetargetProject

Pour l’instant tout va bien !

On se lance !

Trêve de plaisanterie, il est temps de lancer notre application fraîchement convertie.

La compilation se passe sans problème mais au lancement de l’app c’est le drame !

Elle plante lamentablement.

En regardant d’un peu plus près cela ne semble pas trop grave puisque c’est une exception sur chemin de fichier qui ne lui plait pas.

Plus précisément le chemin d’un fichier contenu dans le XAP et chargé par la commande GetFileFromPathAsync

Coté Windows Phone 8, j’obtenais le fichier de la manière suivante :

return await StorageFile.GetFileFromPathAsync("Assets/Icons/gba.png");

Windows Phone 8.1 est plus tatillon et n’accepte que les chemins absolus comme sur un système de fichier Windows classique.
En ce sens, on se rapproche de Windows 8.
Plus de ‘/’ donc mais des ‘\’ sans oublier le signe ‘@’ devant la chaine si l’on est fainéant (evite que le ‘\’ soit vu comme un caractère d’échappement et d’écrire « \\ »).

return await StorageFile.GetFileFromPathAsync(
  Path.Combine(
    Windows.ApplicationModel.Package.Current.InstalledLocation.Path,
    @"Assets\Icons\gba.png"
));

Notez, que ce code marche également parfaitement sur Windows Phone 8.0.

Une fois corrigé, l’application se lance normalement.

Conclusion

Le passage d’une application WP Silverlight 8.0 à 8.1 s’est effectuée rapidement et sans problème majeur.
La petite mésaventure du « GetFileFromPathAsync » invite néamoins à la prudence et aux tests intensifs avant une première mise en production.

Vous trouverez d’autres différences entre SL8 et SL8.1 sur cette page :
http://msdn.microsoft.com/en-us/library/windowsphone/develop/dn642084(v=vs.105).aspx

Sans device 8.1, difficile à dire s’il on bénéficie de meilleur performance pour notre app.
En revanche, on a désormais accès aux toutes nouvelles API de Windows Phone Silverlight 8.1 ce qui ouvre de nouvelles possibilités que je vais m’empresser de mettre en oeuvre. Pas vous ?

1  

Utiliser des librairies C++/CX dans Windows Phone, c’est swag !



L’ajout de components C++/CX dans un projets Windows Phone en C# permet d’associer la puissance du C++/CX à la facilité d’utilisation du C#.

C’est bon, c’est frais, c’est swag.

L’intégration de ces librairies s’effectue comme un assembly .NET classique.
Il suffit d’ajouter une référence pointant vers le fichier d’extension « .winmd » de la librairie.
Ce fichier permet de faire le lien entre notre projet et la dll C++/CX et contient des métadatas (comme son extension le laisse deviner).

Exemple avec la librairie MOGA

L’API MOGA permet de connecter à votre application une manette de jeu bluetooth.
J’ai personnellement testé le modèle Moga HERO (gentiment prêté par Mr. Alex Danvy).

Pour intégrer l’API Moga, on doit ajouter la référence à sa librairie, le fichier « Moga.Windows.Phone.winmd ».

AddReferenceMoga

Une fois référencé on peut regarder le chemin de la librairie dans la fenêtre propriétés de la référence.

MogaProperties

Le chemin qui pointe vers cette librairie contient un dossier ARM.

Lorsque l’on lance notre application en mode « Device » tout se passe bien mais dès que nous changeons la cible vers un de nos émulateurs, le compilateur nous assène un message peut avenant :

« There was a mismatch between the processor architecture of the project being built « x86″ and the processor architecture, « ARM », of the implementation file « D:\Sam\WP8\PurpleCherryX\Librairies\Moga\ARM\Moga.Windows.Phone.dll » for « D:\Sam\WP8\PurpleCherryX\Librairies\Moga\ARM\Moga.Windows.Phone.winmd ». This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and implementation file, or choose a winmd file with an implementation file that has a processor architecture which matches the targeted processor architecture of your project. »

Vilain !

A contrario d’une application .NET, les libraries sont compilées pour une cible particulière:

  • - ARM pour un téléphone.
  • - X86 pour un émulateur.

Si on regarde au même niveau d’arborescence que le dossier ARM contenant la librairie Moga, vous trouverez également un dossier x86.
C’est toujours le cas pour les librairies C++/CX.

On va donc tout simplement enlever la référence actuelle de la librairie MOGA ARM pour la remplacer par celle contenue dans le dossier x86.

Voila ça compile maintenant !

Sauf que…

Lorsque je repasse la cible de compilation en « Device » l’erreur revient mais dans l’autre sens.

Si vous êtes de nature patiente et guillerette vous allez changer de nouveau la référence de la librairie pour la faire pointer vers le dossier ARM (ou x86 selon le cas) autant de fois que nécessaire.

Pour ma part, qui suis plutôt du type de nature illustré ci-dessous, j’ai préféré la solution expliquée en détail dans le prochain paragraphe.

Angoisse

Tout est bien qui finit bien

Oyez l’amis !
Voici donc la solution qui te permettra de continuer le développement tout en restant sain d’esprit.
Il existe sans doute d’autre façon de faire, alors n’hésitez pas à commenter l’article !

Tout d’abord on se rend dans le répertoire de notre application en effectuant dans Visual Studio un bouton droit de la souris sur le projet C# puis « Open folder in file explorer ».

Dans ce dossier, on cherche le fichier du projet en cours « MonProjet.csproj » que l’on ouvre avec un gros Notepad.

A l’intérieur, on recherche la référence à notre fichier « Moga.Windows.Phone.winmd » qui nous conduit vers une une balise « HintPath ».

    <Reference Include="Moga.Windows.Phone, Version=255.255.255.255, Culture=neutral, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\Librairies\Moga\ARM\Moga.Windows.Phone.winmd</HintPath>
    </Reference>

Dans la balise « HintPath », on remplace le dossier ARM (ou x86 selon votre référence) par la variable « $(Platform) » qui rendra le chemin dynamique selon le type de cible visé (ARM ou x86)

    <Reference Include="Moga.Windows.Phone, Version=255.255.255.255, Culture=neutral, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\Librairies\Moga\$(Platform)\Moga.Windows.Phone.winmd</HintPath>
    </Reference>



On enregistre, puis on recharge le projet et le tour est joué !

0  

Viewer d’image Windows Phone 8 pour grosse feignasse

Voilà un titre qui parlera à beaucoup d’entre vous (dont moi) et qui a le mérite d’être clair sur les intentions de cet article.
Le développeur, par essence, est paresseux et il est prêt à des trésors d’espièglerie pour faire coder des morceaux de son applications par d’autres.

Windows Phone est plutôt très aimable de ce coté là car il propose quantité de classes « Launchers » et « Choosers » qui permettent de simplifier la vie du développeur tout en sécurisant son application.

L’objectifs de ces classes est de lui proposer des services systèmes prêt à l’emploi, dont l’utilisation est très aisée. Cela permet, par exemple la sélection d’une image dans la Média Library, l’écriture d’un mail, etc…

http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff769542(v=vs.105).aspx

Mais savez-vous qu’il existe d’autres « Launchers » cachés dans l’API Windows Phone ?

En tant que grosse feignasse, vous êtes désormais à l’écoute.

Un Viewer d’image ?

Il arrive souvent dans une application d’avoir besoin d’afficher une image.

Dialogues typiques :

- Tu peux rajouter un viewer de l’image du produit ?

- Héhé fastoche. Je crée une page XAML avec un contrôle Image. Hop ! c’est fini.

- Tu peux aussi rajouter un menu pour sauver l’image et, disons, la mettre en Ecran de démarrage parce que bon c’est cool non ?

- PFFFFFFF! Bon je rajoute le menu puis petite sauvegarde dans la Media Librairy puis c’est quoi la doc sur le LockScreen déjà ?

- Oui mais on aimerait pouvoir la zoomer également. Avec une inertie dans les déplacements. Ca gère le GIF au fait ?.

- …

Décès du dévéloppeur.

Farniente-Man à la rescousse !

Afin d’éviter un certain nombre d’AVC à mes concitoyens et amis développeurs voici donc le moyen d’afficher en deux lignes de code un Viewer d’image PNG, JPEG, ICO, TIFF, BMP et GIF (mais pas animé).

L’astuce consiste à enregistrer votre image dans l’isolatedStorage puis de faire un appel à LaunchFileAsync qui s’occupera d’appeler le viewer d’image du système.

// Lecture de l'image
var file = await Windows.Storage.ApplicationData.Current.LocalFolder.GetFileAsync("ScreenShotPaddleGBA.png");
// Lancement du viewer
bool isLaunched = await Launcher.LaunchFileAsync(file);

et voila !

Viewer

Encore plus de paresse !

Ah mes amis ! Je vous vois satisfait de ce petit trick qui va vous permettre de faire plus de veille sur « Bonjour Madame » !
Sachez qu’il est aussi possible de lancer facilement d’autres viewers système en choisissant d’autres types de fichier : lecture de son, de vidéo, de fichier zip, texte et autres fichiers Office sont également possibles.

Vous trouverez la liste exhaustive des extensions réservées par le système dans ce lien.

http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj207065(v=vs.105).aspx

Pour conclure, aucun risque que votre viewer soit remplacer par une autre app car ces extensions de fichier ne sont utilisables que par le système.

A très bientôt pour de nouvelles avenZZZZZZZZZZZZ…

0