Si vous souhaitez soumettre une application utilisant un audio playback agent ou un audio stream agent (qui permettent notamment à votre application de jouer de la musique même si l’application est fermée), il se peut que votre application plante sur le marketplace alors qu’elle fonctionne correctement sur votre téléphone de développement.

Ce problème provient de la détection automatique des capabilities de votre application.

Qu’est ce qu’une Capability ?

Dans le répertoire Properties de votre application, vous trouverez une fichier WMAppManifest.xml. Ce dernier représente les informations de déploiement de votre application, on y trouve notamment le nom de l’application, la description des Tasks, ou encore la description de votre tuile principale. Ce qui nous intéresse dans notre cas est l’élément Capabilities, voici à quoi il peut ressembler :

<Capabilities>
<Capability Name="ID_CAP_GAMERSERVICES"/>
<Capability Name="ID_CAP_IDENTITY_DEVICE"/>
<Capability Name="ID_CAP_MEDIALIB"/>
<Capability Name="ID_CAP_MICROPHONE"/>
<Capability Name="ID_CAP_PHONEDIALER"/>
<Capability Name="ID_CAP_PUSH_NOTIFICATION"/>
<Capability Name="ID_CAP_SENSORS"/>
<Capability Name="ID_CAP_CONTACTS"/>
<Capability Name="ID_CAP_APPOINTMENTS"/>
<Capability Name="ID_CAP_IDENTITY_USER" />
<Capability Name="ID_CAP_LOCATION" />
<Capability Name="ID_CAP_ISV_CAMERA" />
<Capability Name="ID_CAP_NETWORKING" />
<Capability Name="ID_CAP_WEBBROWSERCOMPONENT"/>
</Capabilities>

Cet élément permet de spécifier quelles sont les fonctionnalités utilisé par votre application, par exemple ID_CAP_LOCATION permet d’indiquer que votre application utilise la géolocalisation GPS ou encore ID_CAP_CONTACTS qui indique que votre application pourra accéder aux contacts du téléphone. Ces capabilities sont notamment utilisé sur le marketplace pour alerter l’utilisateur que l’application aura accès à la géolocalisation.

Dans 99% des cas, vous n’aurez pas à vous soucier de ces capabilities, en effet, lorsque vous créez un projet sous visual ou blend, ceux-ci active la totalité des capabilities. Lorsque vous allez soumettre votre application sur le marketplace, un programme va analyser automatiquement votre code et va définir selon les appels aux fonctions du SDK, les capabilities à activer. Suite à cela, votre fichier WMAppManifest.xml sera écrasé avec le nouveau fichier généré.

Pourquoi l’application plante alors ?

Le problème vient de la détection automatique du marketplace, celle-ci n’arrive pas toujours à détecter que vous utilisez un audio background agent et donc ne vas pas activer la capabilities ID_CAP_MEDIALIB correspondant à la lecture de média. Lorsque votre application va tenter de lire un flux audio, votre application va planter car le runtime va détecter que vous n’avez pas accès à cette fonctionnalité.

Comment le vérifier ?

Le SDK 7.1 de windows phone, dispose d’un outil appelé le marketplace test kit, il suffit de faire un clic droit sur votre projet, de cliquer sur « Open Marketplace Test Kit », allez dans « Automated Tests » et cliquez sur « run tests » (il faudra préalablemenet avoir compilé son application en mode release)

Assurez vous alors que ID_CAP_MEDIALIB est bien listé dans la colonne « Result Details ».

Comment contourner ce problème ?

Il est assez facile de forcer cette capabilities au niveau de la détection, il suffit juste de créer une page jamais appelée, et d’y insérer dedans un élément MediaElement. Le détecteur ne va jamais analyser si votre page est accessible ou pas, il va donc la considérer au même titre que vos autres pages.

<phone:PhoneApplicationPage xmlns:my="clr-namespace:Microsoft.Phone.Controls.Maps;assembly=Microsoft.Phone.Controls.Maps"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
x:Class="MonApp.DummyPage"
mc:Ignorable="d">
<MediaElement Source="http://contoso.com/contoso.mp3"/>
</phone:PhoneApplicationPage>

Le programme va alors analyser vos assemblies, va bien détecter qu’un mediaelement est utilisé et que donc votre application à besoin de la capability ID_CAP_MEDIALIB.

Une autre méthode est forcer dans votre code, l’appel à certaines assemblies, par exemple :

Si vous référencez Microsoft.Phone.dll, ajoutez quelque part dans votre code :
Microsoft.Devices.MediaHistory history = null;

Si vous référencez Microsoft.Xna.Framework.dll, ajoutez :
Microsoft.Xna.Framework.Media.MediaLibrary lib = null;

Et si aucune des deux précédentes :
System.Windows.Controls.MediaElement me = null;

Samuel Blanchard avec qui je vais partager une session aux techdays 2012
« Concevoir une expérience SoLoMo », vient de poster un article sur le problème
des messagebox dans la fonction completed des Tasks, problématique qui ne m’était pas venu à l’esprit, donc merci Sam !

Pourquoi ?

En effet, la méthode Completed intervient pendant la reprise de l’application, c’est à dire avant même le NavigatedTo. Or une application n’a le droit qu’à 15 secondes pour reprendre. Comme la fonction MessageBox.Show est synchrone, tant que la boite de dialogue n’est pas fermé, l’application ne peut continuer la reprise, jusqu’à ce que l’on atteigne les fameuses 15 secondes et donc une fermeture de l’application par le système.

Solution

Samuel propose dans son article d’utiliser un booléen, initialisé dans la méthode Completed et vérifié dans OnNavigatedTo pour afficher la messagebox par exemple, on évite ainsi de bloquer la reprise de l’application.

Personnellement, je privilégie l’utilisation de Toast pour ce genre de scénario, mais parfois une messagebox peut-être indispensable.

Mon alternative

Une autre solution a ce problème serait de pouvoir lancer la MessageBox de façon asynchrone, mais cela n’est pas possible en Silverlight, enfin… presque

Dans mon article MessageBox avancée, j’avais mis en avant la gestion des messagebox dans le framework XNA avec notamment le fait que l’on puisse les appeler de façon assynchrone, ce qui est clairement ce que l’on souhaite. On pourra donc lancer une messagebox dans la méthode Completed sans bloquer la reprise de l’application

public MainPage()
{
InitializeComponent();
photoChooser = new PhotoChooserTask();
photoChooser.Completed += new
EventHandler(photoChooser_Completed);
}

PhotoChooserTask photoChooser;
private void button1_Click(object sender, RoutedEventArgs e)
{
photoChooser.Show();
}

void photoChooser_Completed(object sender, PhotoResult e)
{
Microsoft.Xna.Framework.GamerServices.Guide.BeginShowMessageBox(
"Aimez vous Fuse ?",
"Avez vous acheté la super application Fuse ?",
new string[] { "évidemment !", "c'est quoi ?" },
0,
Microsoft.Xna.Framework.GamerServices.MessageBoxIcon.Alert,
null,
null);
}

Suite à la mise en place de l’accélérateur windows phone, j’ai voulu faire le tour des templates d’applications windows phone existant et j’ai notamment découvert le template Windows Phone Starter Kit for Schools par Chris Koenig, un évangeliste microsoft américain.

Le design de celui est plutôt intéressant, mais ne correspondait pas forcément à mes attentes.

Le service météo par exemple est limité au états-unis, donc difficilement exploitable pour nous.

De plus, il y a quelques problèmes ergonomiques, par exemple, sur le panneau contacts, il faut cliquer avec précision sur le numéro de téléphone pour téléphone ou sur l’email pour écrire.

Comme vous pouvez le voir sur cette capture, les deux textes étant très proche et de petite taille, l’utilisation n’était pas aisé. De la même façon, on pouvait afficher le plan du campus, mais impossible de naviguer dedans, peu utile donc.

Un autre problème est l’utilisation de l’évènement MouseLeftButtonUp dans le panorama, ce qui faut éviter car lorsque l’utilisateur navigue dans le panorama, il risque de cliquer dessus dans le vouloir, il faut plutôt privilégier l’évènement Silverlight 4 « Tap » ou tout simplement des boutons.

Enfin au niveau du code, le MVVM étant assez mal exploité et ca manquait d’optimisations : des ObservableCollection et OnPropertyChanged inutiles.

Réécriture du template

Les templates étant souvent le premier point d’entrée d’un développeur débutant, autant lui montrer du beau code ! C’est donc pour cela, que j’ai souhaité réécrire ce template complètement tout en revoyant l’ergonomie mais en gardant le design de l’ancien template et en ajoutant de nouvelles fonctionnalités comme :

• l’apparition d’un toast pour choisir entre numéro de téléphone ou email d’un contact si les deux sont disponibles
• la navigation sur le plan du campus en utilisant le pinch
• la localisation de l’application
• les clubs et la météo via google pour une compatibilité mondiale.

Note : L’application est MVVM mais j’ai pris le partie de ne pas utiliser de commande, pour simplifier la prise en main de l’application par des développeurs débutants.

L’application est évidemment facilement personnalisable, un prochain article détaillera les étapes pour le personnaliser.

Pour télécharger le template :

CLIQUEZ ICI !