Développer une application Windows 8 (10/10) : Windows Store et déploiement

12 août 2012 Loic Rebours Windows 8, 13

Cet article est le dixième et dernier d’une série sur le développement d’applications Windows 8 en XAML et C#. Cette série s’adresse avant tout aux développeurs .NET, débutants comme professionnels, souhaitant découvrir la nouvelle plateforme de développement Windows 8. Chaque article présente une des notions indispensables à connaître pour développer une application Metro complète. Cette série est réalisée avec Windows 8 Pro et Visual Studio 2012.

1. Introduction
2. Cycle de vie d’une application Metro
3. Contrôles et navigation
4. AppBar, styles et animations
5. L’asynchronisme
6. Snapping et orientations
7. Application data et settings
8. Contrats de recherche et partage
9. Vignettes et notifications toast
10. Windows Store et déploiement

Introduction

Vous connaissez désormais toutes les notions indispensables pour développer une application Windows 8. Enfin, presque. Une application a vocation à être utilisée et Windows 8, plus que n’importe quelle autre plateforme existante, va vous offrir cette opportunité. Avec son nouveau système d’exploitation, Microsoft introduit le Windows Store. Dans l’absolu, il s’agit d’un simple marché d’applications comme il en existe tant d’autres. vous allez le découvrir dans cet article, le Windows Store est en réalité bien plus que cela.

Le Windows Store est avant tout un endroit auquel n’importe quel utilisateur de Windows 8 a accès. Il s’agit du seul et unique marché permettant aux utilisateurs de trouver et télécharger des applications Metro. Cela permet à Microsoft de contrôler et valider chaque application avant que celle-ci ne soit disponible sur le Store, offrant ainsi aux utilisateurs un gage de qualité certain. Les applications présentent sur le Store sont réparties dans plusieurs catégories (jeux, social, sports, news …) et une section Spotlight met en avant les meilleures applications du moment.

 

 

Les applications présentent sur le Windows Store sont soit gratuites, soit payantes. Pour chaque application payante, le développeur peut activer un mode trial. La période d’évaluation peut-être limitée dans le temps ou illimité, cas dans lequel le développeur peut brider les fonctionnalités de son application afin d’encourager l’utilisateur à acheter la version complète.

Sur de nombreux stores, l’achat d’une application représente l’unique source de revenu pour le développeur. Avec le Windows Store, il n’en sera rien. En effet, celui-ci offre aux développeurs une fonctionnalité « in app purchases ». Concrètement, le développeur peut définir un ensemble de fonctionnalités que l’utilisateur peut activer uniquement après avoir effectué un achat au sein même de l’application. Il est ainsi possible d’ajouter un ensemble de fonctionnalités afin de faire évoluer l’application et en dégager des sources de revenus continuellement.

 

 

Bien que le Windows Store contienne majoritairement des applications Metro, il ne s’y limite pas. En effet, certaines applications desktop peuvent également figurer sur ce dernier, à condition qu’un ensemble de guidelines soient respectées. Cependant, contrairement aux applications Metro, les applications desktop ne sont pas directement téléchargeables sur le Windows Store. Ce dernier les met en avant, mais l’utilisateur est redirigé vers le site de l’éditeur pour acquérir l’application en question.

Last but not least, le Windows Store est tout simplement le marché qui est potentiellement le plus large de tous. A ce jour, plus de 550 millions de PC possèdent Windows 7. Microsoft annonce que chacun d’entre eux, sans exception, peut faire tourner Windows 8 en s’assurant une expérience utilisateur de qualité. Votre application Metro ne sera donc pas téléchargeable par quelques milliers d’utilisateurs, mais par plusieurs centaines de millions.

Préparation

Pour les besoins de cet article, nous allons reprendre l’application développée dans les deux articles précédents. Pour rappel, il s’agit d’une application de chat affichant une liste de personnes (nom, image et statut de connexion). Celle-ci contient notamment :

• Une page principale listant toutes les personnes
• Une page Profile permettant d’accéder au détail d’une personne et de créer une vignette secondaire pour chaque personne
• Une page de recherche (Search)

Dans cet article, nous allons la faire évoluer en :

• affichant sur la page principale le nombre de jours restants avant l’expiration du mode trial ainsi qu’un bouton pour acheter l’application
• proposant à l’utilisateur de chater avec des personnes « VIP » grâce à un achat in-app.

Vous pouvez récupérer les sources de l’application qui nous servira de base pour cet article.

Mode trial

Avant d’acheter, tout utilisateur souhaite savoir si l’argent qu’il va dépenser ne sera pas perdu. Le Windows Store fournit une description et des images de chaque application, mais c’est bien souvent loin d’être suffisant. Pour répondre à ce besoin, il est également possible, lors de la soumission d’une application, de définir un mode trial. Ce mode trial est soit limité dans le temps (expiration au bout d’un jour, une semaine, deux semaines, un mois) ou illimité.

Vous vous dites probablement que laisser votre application gratuite ne vous servira à rien. Vous avez tort. Des études, réalisées à partir des données générées par le Marketplace Windows Phone prouve que proposer un mode trial aux utilisateur permet :

• d’augmenter de 70 fois le nombre de téléchargements
• d’augmenter de 10 fois les revenus générés par une application
• de convertir 10 % des testeurs en acheteurs

Le mode trial est réellement utile. Pour vos futurs utilisateurs et pour vous-même, vous ne pouvez négliger cela. D’autant que vous n’avez rien à faire pour gérer cela. Définissez simplement une période en soumettant vos applications et Windows se charge du reste. Lorsqu’un utilisateur utilise une application en mode trial, celle-ci se bloque automatiquement au bout du nombre de jours spécifiés par le développeur.

Récupérer les informations de licence d’une application

Toutes les API relatives au Windows Store se situent dans le namespace Windows.ApplicationModel.Store. C’est le cas de la classe statique CurrentApp permettant de représenter l’application courante. Celle-ci possède les propriétés suivantes :

• AppId : Identifiant de l’application sur le Windows Store
• LinkUri : URI pointant vers l’application sur le Windows Store
• LicenseInformation : Informations sur la licence de l’application

La dernière propriété, LicenseInformation est un objet de type LicenseInformation. Il possède notamment les propriétés suivantes :

• IsActive : détermine si la licence est active ou expirée
• IsTrial : détermine si l’application est ou non en mode trial
• ExpirationDate : date d’expiration de la licence

Pour récupérer des informations sur le marché visé, vous pouvez utiliser la méthode LoadListingInformationAsync(). Celle-ci renvoie un objet de type ListingInformation possédant les propriétés suivantes :

• AgeRating
• CurrentMarket
• Description
• FormattedPrice
• CurrentMarket
• Name

Toutes ses informations peuvent être récupérées une fois que l’application est déployée et disponible sur le Windows Store. Pour nos tests cependant, cela ne fonctionnera pas.

Simuler une licence

Pour simuler une licence et effectuer des tests lors du développement d’une application, nous n’allons pas utiliser la classe CurrentApp, mais CurrentAppSimulator. Cette classe possède exactement les mêmes méthodes, propriétés et évènements que CurrentApp. Son fonctionnement est exactement le même. L’unique différence, c’est que ce dernier ne se base pas sur les informations réelles de l’application, mais sur un fichier XML qui sert de proxy. Le xsd définissant la structure du fichier XML à utiliser avec la classe CurrentAppSimulator se trouve sur cette page MSDN

Notez bien que cette classe ne doit être utilisée qu’à des fins de tests. Si vous tentez de soumettre une application utilisant la classe CurrentAppSimulator, votre application sera immédiatement refusée.

Lorsque vous allez utiliser la classe CurrentAppSimulator pour la première fois, un fichier nommé WindowsStoreProxy.xml sera créé dans le dossier LocalState\Microsoft\Windows Store\ApiData, lui-même situé dans le dossier correspondant au package de votre application (C:\Users\[Username]\AppData\Local\Packages\[Package_ID]).

Voici le fichier en question (légèrement modifié) :

 

<?xml version="1.0" encoding="utf-16" ?>
<CurrentApp>
    <ListingInformation>
        <App>
            <AppId>00000000-0000-0000-0000-000000000000</AppId>
            <LinkUri>http://store.windows.microsoft.com/app/00000000-0000-0000-0000-000000000000</LinkUri>
            <CurrentMarket>fr-FR</CurrentMarket>
            <AgeRating>3</AgeRating>
            <MarketData xml:lang="fr-FR">
                <Name>Meet People</Name>
                <Description>Meet People is an awesome app</Description>
                <Price>1.49</Price>
                <CurrencySymbol>€</CurrencySymbol>
            </MarketData>
        </App>
        <Product ProductId="1" LicenseDuration="0">
            <MarketData xml:lang="fr-FR">
                <Name>Product1Name</Name>
                <Price>1.00</Price>
                <CurrencySymbol>€</CurrencySymbol>
            </MarketData>
        </Product>
    </ListingInformation>
    <LicenseInformation>
        <App>
            <IsActive>true</IsActive>
            <IsTrial>true</IsTrial>
	    <ExpirationDate>2012-12-31T00:00:00.00Z</ExpirationDate>
        </App>
        <Product ProductId="1">
            <IsActive>true</IsActive>
        </Product>
    </LicenseInformation>
</CurrentApp>

 

Notez que ce fichier ne sera pas modifié par l’application lors de vos tests. Les actions qui seront effectuées (passage du mode trial au mode complet par exemple) seront enregistrés en mémoire et seront annulés lorsque l’application redémarrera. Une fois encore, cela est fait pour faciliter vos tests.

Dans le fichier XML ci-dessus, nous simulons le cas d’une application nommée Meet People, disponible à 1.49€ sur le marché français, actuellement utilisée en mode trial avec une date d’expiration fixée au 31 décembre 2012.

Proposer à l’utilisateur de passer à la version complète

Maintenant que nous avons des données, nous allons pouvoir coder !

Pour commencer, nous allons tester si l’application est en mode trial. Si elle l’est, nous afficherons le temps restant avant l’expiration du mode trial et un bouton pour acheter l’application. Dans le cas contraire, nous afficherons un lien vers l’application sur le Windows Store.

Dans la page MainPage.xaml, remplacez le TextBlock pageTitle par le code suivant.

 

<Grid Grid.Column="1">
	<Grid.ColumnDefinitions>
		<ColumnDefinition Width="*" />
		<ColumnDefinition Width="*" />
	</Grid.ColumnDefinitions>

	<TextBlock x:Name="pageTitle" Text="{StaticResource AppName}" Style="{StaticResource PageHeaderTextStyle}"/>
	<StackPanel Orientation="Horizontal" Grid.Column="1" HorizontalAlignment="Right" VerticalAlignment="Center" Margin="0,0,20,0">
		<TextBlock x:Name="trialText" FontSize="15" />
		<Button x:Name="PurchaseButton" Content="Buy" Click="Button_Click"></Button>
	</StackPanel>
</Grid>

 

Dans le code-behind, définissez une méthode nommée HandleTrialMode et appelez-la dans le constructeur.

 

private async void HandleTrialMode()
{
	LicenseInformation licenseInformation = CurrentAppSimulator.LicenseInformation;
	if (licenseInformation.IsActive)
	{
		if (licenseInformation.IsTrial)
		{
			int daysRemaining = (licenseInformation.ExpirationDate - DateTime.Now).Days;
			trialText.Text = String.Format("Trial : {0} days remaining", daysRemaining.ToString());

			ListingInformation listingInformation = await CurrentAppSimulator.LoadListingInformationAsync();
			PurchaseButton.Content = String.Format("Buy ({0})", listingInformation.FormattedPrice);
		}
		else
		{
			trialText.Text = String.Format("App : {0}", CurrentAppSimulator.LinkUri);
			PurchaseButton.Visibility = Visibility.Collapsed;
		}
	}
}

 

Dans cet exemple, nous utilisons les informations présentées dans la section précédente :

• LicenseInformation permet de savoir si l’application est active, si elle est en mode trial et permet de récupérer la date d’expiration du mode trial
• LicenseInformation permet de récupérer le prix de l’application pour le marché courant

En exécutant l’application, vous devriez désormais voir apparaître ceci dans le coin supérieur droit.

 

 

Nous allons maintenant permettre à l’utilisateur d’acheter l’application. Lorsque ce sera le cas, la licence de l’application sera modifiée. Pour prendre ce changement en compte depuis l’application, il est nécessaire de s’abonner à l’évènement LicenseChanged de la classe LicenseInformation. Cela permet à l’utilisateur de ne pas avoir besoin de redémarrer l’application pour que les changements soient pris en compte. Notez également que cette licence utilise le roaming de Windows 8. Ainsi, si vous utilisez une application sur deux ordinateurs différents (avec le même compte Microsoft) et que vous achetez la licence sur l’un d’entre eux, la modification sera automatiquement prise en compte sur le second.

L’achat de l’application se fait grâce à la méthode RequestAppPurchaseAsync de la classe CurrentApp. Pour des raisons évidentes, l’achat ne se fait pas de façon automatique mais requiert la validation de l’utilisateur.

Abonnez-vous à l’évènement LicenseChanged dans le constructeur de la page MainPage.xaml.

 

public MainPage()
{
	this.InitializeComponent();

	CurrentAppSimulator.LicenseInformation.LicenseChanged += LicenseInformation_LicenseChanged;
	HandleTrialMode();
}

void LicenseInformation_LicenseChanged()
{
	HandleTrialMode();
}

 

Désormais, lorsque la licence sera modifiée, la méthode HandleTrialMode sera appelée.

 

private async void Button_Click(object sender, RoutedEventArgs e)
{
	try
	{
		await CurrentAppSimulator.RequestAppPurchaseAsync(true);
	}
	catch (Exception)
	{
		MessageDialog md = new MessageDialog("Error while trying to purchase the app. Please, try again.");
		md.ShowAsync();
	}
}

 

La méthode suivante est déclenchée lorsque l’utilisateur appuie sur le bouton « Buy ». Notez que si l’achat ne réussit pas, une exception est levée.

En utilisant la classe CurrentAppSimulator, une fenêtre apparaît à l’écran lors de l’achat. Celle-ci nous permet de déterminer manuellement le résultat à renvoyer (achat effectué, annulé, échoué, …).

 

 

Choisissez l’option S_OK pour confirmer l’achat. En faisant cela, la licence de l’application est modifié; l’évènement LicenseChanged est levé et la méthode HandleTrialMode appelée. Le bouton « Buy » disparait alors pour laisser place au lien de l’application dans le Store.

 

 

En choisissant une autre option, une exception est levé et un message s’affiche à l’écran.

 

 

Le mécanisme est désormais en place. Si vous souhaitez restreindre les fonctionnalités de votre application en mode trial (illimité), reproduisez cet exemple en testant si le mode trial est actif, puis en proposant à l’utilisateur, le cas échéant, d’acheter l’application.

In-app purchases

Une fois publiée, une application doit continuer à vivre, à évoluer. Cela se fait généralement par des mises à jour, gratuites, qui demandent à l’utilisateur de télécharger à nouveau l’application. Avec le Windows Store, cela peut également se faire avec des achats effectués directement dans l’application, les in-app purchases.

Ces dernières vous permettent de continuer à monétiser vos applications après leur achat initial. Notez également qu’il est tout à  fait possible de mettre en place un système d’in-app purchases si l’application est gratuite. Cela peut même être une excellente stratégie de monétisation. Selon une étude réalisée à partir des données d’un ensemble de Marketplace, 72 % des revenues du top 200 des applications téléchargées proviennent d’in app purchases.

Concrètement, le développeur va créer des fonctionnalités qui ne seront pas activées par défaut. En soumettant son application, il créera ces fonctionnalités en définissant un nom et un prix. En codant son application, le développeur pourra utiliser certaines API permettant d’identifier si telle ou telle feature a été ou non achetée. Les in app purchases ne sont donc pas des mises à jours, mais de simples fonctionnalités à activer ou non en fonction d’un mécanisme d’achat entièrement géré par le Windows Store.

Préparation

Pour notre application, nous allons proposer aux utilisateurs de chatter avec des VIPs. Cette fonctionnalité ne sera pas gratuite, mais proposée via un achat in-app. Pour cela, nous allons devoir mettre à jour plusieurs fichiers.

 

Modifiez le fichier Person.cs pour ajouter un booléen IsVIP.

public class Person
{
	public int ID { get; set; }
	public string Name { get; set; }
	public string Photo { get; set; }
	public Status Status { get; set; }
	public bool IsVIP { get; set; }
}

 

Ajoutez la liste de personnes suivantes dans le repository.

new Person { ID = 26, Name = "William K.", Status = Status.Online, Photo = "Images/img2.jpg", IsVIP = true },
new Person { ID = 27, Name = "Ethan M.", Status = Status.Away, Photo = "Images/img4.jpg", IsVIP = true },
new Person { ID = 28, Name = "James S.", Status = Status.Offline, Photo = "Images/img3.jpg", IsVIP = true },
new Person { ID = 29, Name = "David A.", Status = Status.Online, Photo = "Images/img1.jpg", IsVIP = true }

 

Ajoutez les méthodes suivantes dans le repository (remplacez GetPersons)

public static List<Person> GetPersons()
{
	return _persons.Where(p => !p.IsVIP).ToList();
}

public static List<Person> GetPersonsIncludingVIPs()
{
	return _persons;
}

 

Dans le dossier Converters, ajoutez le converter suivant :

class VipToVisibilityConverter : IValueConverter
{
	public object Convert(object value, Type targetType, object parameter, string language)
	{
		bool isVIP = bool.Parse(value.ToString());
		return isVIP ? Visibility.Visible : Visibility.Collapsed;
	}

	public object ConvertBack(object value, Type targetType, object parameter, string language)
	{
		throw new NotImplementedException();
	}
}

 

Dans le fichier App.xaml, modifiez le DataTemplate PersonItemTemplate et ajoutez le converter précédemment créé.

<DataTemplate x:Key="PersonItemTemplate">
	<StackPanel Orientation="Vertical">
		<Image Source="{Binding Photo}" Width="200" Stretch="UniformToFill" Height="220"></Image>
		<Grid Height="40" Margin="0,-40,0,0">
			<Grid.ColumnDefinitions>
				<ColumnDefinition Width="Auto" />
				<ColumnDefinition Width="*" />
			</Grid.ColumnDefinitions>
			<Rectangle Fill="{Binding Status, Converter={StaticResource StatusConverter}}" Width="6"></Rectangle>
			<Border Grid.Column="1">
				<Border.Background>
					<SolidColorBrush Color="Black" Opacity="0.7"></SolidColorBrush>
				</Border.Background>
				<Grid>
					<TextBlock Text="{Binding Name}" FontWeight="Light" VerticalAlignment="Center" FontSize="28" Margin="10,0,10,0"></TextBlock>
					<Image Source="Images/vip.png" Visibility="{Binding IsVIP, Converter={StaticResource VipToVisibilityConverter}}" HorizontalAlignment="Right" />
				</Grid>
			</Border>
		</Grid>
	</StackPanel>
</DataTemplate>

<converters:VipToVisibilityConverter x:Key="VipToVisibilityConverter"></converters:VipToVisibilityConverter>

 

Enfin, ajoutez cette image dans le dossier Images.

Récupérer des informations de licence sur une feature

Pour chaque feature activable via le système d’in-app purchases, il est possible de récupérer des informations. Vous allez le constatez, la méthode est la même que pour récupérer les informations de licence de l’application.

La classe LicenseInformation possède une propriété nommée ProductLicenses. Il s’agit d’un dictionnaire string/ProductLicense où la string correspond à l’identifiant d’une feature et l’objet ProductLicense aux informations de cette feature. La classe ProductLicense possède les propriétés suivantes :

• ProductID : Identifiant de la feature
• ExpirationDate : Date d’expiration
• IsActive : booléen indiquant si la feature est active ou non

Pour récupérer les informations sur le marché, il faut passer la propriété ProductListings de la classe ListingInformation. Il s’agit là encore d’un dictionnaire string/ProductListing où la string correspond à l’identifiant d’une feature et l’objet ProductListing aux informations de cette feature. La classe ProductListing possède les mêmes propriétés que la classe ListingInformation.

Simuler des licences pour l’in app purchase

Pour simuler des licences, le principe est le même que celui décrit précédemment. Il va nous falloir un fichier xml servant de proxy. Pour cet exemple, nous utiliserons le suivant :

 

<?xml version="1.0" encoding="utf-16" ?>
<CurrentApp>
    <ListingInformation>
        <App>
            <AppId>00000000-0000-0000-0000-000000000000</AppId>
            <LinkUri>http://store.windows.microsoft.com/app/00000000-0000-0000-0000-000000000000</LinkUri>
            <CurrentMarket>fr-FR</CurrentMarket>
            <AgeRating>3</AgeRating>
            <MarketData xml:lang="fr-FR">
                <Name>Meet People</Name>
                <Description>Meet People is an awesome app</Description>
                <Price>1.49</Price>
                <CurrencySymbol>€</CurrencySymbol>
            </MarketData>
        </App>
        <Product ProductId="VIPFeature" LicenseDuration="0">
            <MarketData xml:lang="fr-FR">
                <Name>VIP</Name>
                <Price>4.99</Price>
                <CurrencySymbol>€</CurrencySymbol>
            </MarketData>
        </Product>
    </ListingInformation>
    <LicenseInformation>
        <App>
            <IsActive>true</IsActive>
            <IsTrial>true</IsTrial>
	    <ExpirationDate>2012-12-31T00:00:00.00Z</ExpirationDate>
        </App>
        <Product ProductId="VIPFeature">
            <IsActive>false</IsActive>
        </Product>
    </LicenseInformation>
</CurrentApp>

 

Dans la section ListingInformation, remarquez qu’une feature nommée VIPFeature a été définie. Celle-ci est illimité dans le temps et disponible pour 4.99 €. Dans la section LicenseInformation, cette feature est définie comme inactive.

Proposer à l’utilisateur d’acheter une feature via le système d’in-app purchases

Le proxy étant en place, il faut maintenant écrire le code permettant d’activer/d’acheter cette feature. Pour cela, nous allons ajouter une AppBar qui proposera plusieurs features. Lorsque l’utilisateur cliquera sur l’une d’entre elles, un flyout apparaîtra afin de proposer à l’utilisateur de l’acheter s’il ne le possède pas déjà. S’il l’achète, alors les données seront immédiatement mise à jour.

Pour le Flyout, nous utiliserons ce helper de David Catuhe. Créez une classe nommée FlyoutHelper et ajoutez-y le code de David.

Ce Flyout affiche un UserControl. Créez-en un nommé VIPFeaturePurchase et ajoutez-y le code suivant :

 

<Grid>
	<Grid.Background>
		<SolidColorBrush Color="#8cc600" Opacity="0.9"></SolidColorBrush>
	</Grid.Background>

	<Grid.RowDefinitions>
		<RowDefinition Height="*" />
		<RowDefinition Height="50" />
	</Grid.RowDefinitions>

	<TextBlock x:Name="FeatureDescription" TextAlignment="Justify" FontSize="18" TextWrapping="Wrap" Margin="5,5,5,5" />
	<Button Content="Buy" Click="Button_Click" HorizontalAlignment="Center" Grid.Row="1"></Button>
</Grid>

 

Le TextBlock FeatureDescription affichera un message à l’utilisateur ainsi que le prix de la feature précédemment définie. Cela est initialisé dans le constructeur du user control.

 

public VIPFeaturePurchase()
{
	this.InitializeComponent();

	LoadVIPFeatureInformations();
}

private async void LoadVIPFeatureInformations()
{
	ListingInformation listingInformation = await CurrentAppSimulator.LoadListingInformationAsync();
	ProductListing VIPFeatureListing = listingInformation.ProductListings["VIPFeature"];

	FeatureDescription.Text = String.Format("To chat with VIPs, you have to purchase a new feature ({0})", VIPFeatureListing.FormattedPrice);
}

 

Le bouton du user control permet d’acheter la feature. Cela se fait avec la méthode RequestProductPurchaseAsync. Celle-ci prend en paramètre l’identifiant de la feature et un booléen indiquant si l’on souhaite récupérer un reçu ou non. Comme pour l’achat de l’application, il est nécessaire de catcher les éventuelles exceptions levées si l’achat n’est pas validé.

 

private async void Button_Click(object sender, RoutedEventArgs e)
{
	try
	{
		await CurrentAppSimulator.RequestProductPurchaseAsync("VIPFeature", true);
	}
	catch (Exception)
	{
		MessageDialog md = new MessageDialog("Error while trying to purchase the VIP Feature. Please, try again.");
		md.ShowAsync();
	}
}

 

Dans la page MainPage.xaml, ajoutez le code suivant afin de définir une AppBar.

 

<Page.BottomAppBar>
	<AppBar>
		<StackPanel Orientation="Horizontal" >
			<Button Style="{StaticResource FavoriteAppBarButtonStyle}" AutomationProperties.Name="Feature 1"></Button>
			<Button Style="{StaticResource FavoriteAppBarButtonStyle}" AutomationProperties.Name="Feature 2"></Button>
			<Button x:Name="VIPAppBarButton" Click="VIPAppBarButton_Click"
					Style="{StaticResource FavoriteAppBarButtonStyle}" AutomationProperties.Name="Display VIP"></Button>
		</StackPanel>
	</AppBar>
</Page.BottomAppBar>

 

Ajoutez maintenant cette méthode dans le code-behind. Celle-ci permet d’afficher le flyout si la feature n’est pas active.

 

private async void VIPAppBarButton_Click(object sender, RoutedEventArgs e)
{
	ProductLicense VIPFeature = CurrentAppSimulator.LicenseInformation.ProductLicenses["VIPFeature"];
	if (!VIPFeature.IsActive)
	{
		FlyoutHelper.ShowPopup(VIPAppBarButton, new VIPFeaturePurchase());
	}
}

 

Désormais, tout le mécanisme permettant d’ajouter la feature est en place. Il ne reste qu’à afficher la liste des VIP si la feature correspondante est activée. Comme pour le passage du mode trial au mode payant d’une application, la licence sera mise à jour lors de l’achat d’une feature. Il suffit donc une fois de plus de réagir à l’évènement LicenseChanged pour afficher, ou non, la liste des VIP.

 

void LicenseInformation_LicenseChanged()
{
	HandleTrialMode();
	HandleInAppPurchases();
}

private void HandleInAppPurchases()
{
	ProductLicense productLicense = CurrentAppSimulator.LicenseInformation.ProductLicenses["VIPFeature"];
	if(productLicense.IsActive)
	{
		DefaultViewModel["Persons"] = PersonRepository.GetPersonsIncludingVIPs();
		VIPAppBarButton.Visibility = Visibility.Collapsed;
	}
}

 

Dans cette méthode, nous récupérons à nouveau les informations de licence concernant la feature. Si celle-ci est active, nous chargeons la liste des personnes en incluant les VIP et nous cachons le bouton de l’AppBar permettant d’acheter cette feature.

En exécutant l’application, vous voyez désormais plusieurs boutons dans l’AppBar. En cliquant sur VIP Feature, le Flyout apparait.

 

 

En cliquant sur Buy (et en utilisant le simulateur), une fenêtre apparaît afin de vous permettre de choisir la réponse à renvoyer à l’application.

 

 

En retournant le code « S_OK », la licence est mise à jour et la liste des VIP s’affichent désormais.

 

 

Appliquez la même méthode pour chaque feature que vous souhaitez proposer via le système d’in-app purchases. Notez que les transactions d’argent sont gérées automatiquement par le Windows Store. Vous n’avez aucune ligne de code à écrire pour prendre cela en compte.

Vous pouvez récupérer les sources finales de cette application.

Déployer une application en local

Vous avez fini votre application et vous vous apprêtez à déployer votre application sur le Windows Store. Pensez auparavant à tester cette dernière sur différents devices. Le simulateur intégré à Visual Studio permet certes de tester votre application sous plusieurs résolutions, mais rien ne vaut un test réel.

Pour déployer votre application sur un autre device que celui sur lequel il est développé, effectuez un clic droit sur votre projet Windows 8, puis sélectionnez Store > Create App Package.

 

 

Une fenêtre s’ouvre et vous permet de créer un package pour le Windows Store ou pour un déploiement local. Choisissez la deuxième option.

 

 

Sur l’écran suivant, définissez les settings du package, puis cliquez sur Create.

 

 

Plusieurs fichiers sont alors créés.

 

 

Le fichier ps1 est un script powershell qu’il faut exécuter pour installer l’application. Effectuez un clic droit sur le fichier, puis sélectionnez Run With PowerShell.

 

 

Suivez les instructions et attendez que l’application soit installée.

Déployer une application sur le Windows Store

Déployer son application sur le Windows Store est la toute dernière étape à réaliser. Lorsque vous le faites, vous devez vous assurer que votre application respecte bien toutes les guidelines définies par Microsoft, qu’elle est entièrement fonctionnelle, qu’elle ne crash pas et qu’elle apporte réellement de la valeur à l’utilisateur.

Pour être acceptée sur le Windows Store, votre application doit être performante, sécurisée et fiable. Elle fera l’objet, par les équipes de Microsoft en charge de la validation, de tests:

• Pour certifier l’application techniquement
• Pour vérifier qu’elle ne contient pas de virus/malware
• Pour s’assurer que le contenu est approprié.

N’oubliez jamais que votre application s’adresse à une audience globale composée potentiellement de plusieurs centaines de millions de personnes à travers le monde.

Valider une application techniquement

Pour aider les développeurs à valider leurs applications techniquement, un outil nommé Windows App Cert Kit (WACK) est mis à leur disposition. Celui-ci va effectuer un ensemble de tests qui seront exactement les mêmes que ceux que Microsoft passera. Cela signifie que si votre application obtient des résultats positifs aux tests passés avec le Windows App Cert Kit, elle obtiendra forcément un résultat positif aux tests passés par Microsoft.

Ce kit s’assure que :

• les API utilisées sont correctement supportées
• l’application est stable et sécurisée
• le contenu du manifest est correct
• la taille des images est respectée

Pour tester votre application avec le WACK, vous devez préalablement l’installer. Pour cela, référez-vous à la section précédente.

Lorsque vous lancez le WACK, vous devez choisir quel type d’applications vous souhaitez tester. Choisissez Validate Windows Store App.

 

 

Choisissez ensuite l’application à tester.

 

 

Le test démarre. Celui-ci dure plusieurs minutes. Durant cette période, vous allez voir votre application démarrer automatiquement. N’interagissez-pas avec celle-ci lors des tests.

 

 

Une fois le test fini, une fenêtre s’ouvre afin de vous faire sauvegarder un fichier XML. Ce fichier contient les résultats du test. Ouvrez-le avec Internet Explorer.

Deux résultats sont alors possible : Passed ou Failed.

 

 

Ici, le test échoue. Le fichier XML vous permet de prendre connaissance des erreurs qui ont fait échouer le test. Ici, j’ai utilisé une configuration Debug au lieu de Release. Inutile donc de soumettre mon package sur le Store, celui-ci serait immédiatement refusé.

 

 

Lorsque le WACK passe ses tests avec succès, tous les indicateurs sont verts. Vous pouvez désormais soumettre votre package sans souci.

Pensez également à utiliser le WACK avec votre application en mode offline.

Soumettre l’application depuis le Dev Center

Pour soumettre votre application, rendez-vous sur le Dev Center pour applications Metro. Si ce n’est pas déjà fait, créez-vous un compte en utilisant un compte Microsoft.

Ceci fait, cliquez sur le bouton Submit an app. Le workflow de soumission commence par la réservation d’un nom pour votre application. C’est ce nom qui identifiera votre application sur le Windows Store. Ce nom peut-être réservé à tout moment, même si vous n’avez pas encore commencé à coder.

 

 

Le workflow ci-dessous est celui que vous devrez respecter pour finaliser la soumission de l’application.

 

 

Ce workflow vous permet notamment de :

• décrire votre application
• désigner les marchés visés
• désigner l’audience visée
• déterminer le prix de votre application
• fixer vos features disponibles via l’in-app purchases
• uploader votre package
• ajouter des notes à destination des testeurs pour accélérer le processus de validation

 

Fixez vos prix

Fixer vos prix est probablement une des étapes les plus importantes. C’est sur ce prix que vont se baser tous vos utilisateurs pour acheter, ou non, votre application. C’est également ce qui permettra de récompenser les longues heures passées devant votre ordinateur à coder.

Le prix est déterminé en fonction de la devise du marché du développeur. Il est ensuite converti pour s’adapter aux autres marchés. Sur le marché français, une application peut être vendue entre 1.19€ et 834.99€.

 

 

C’est également ici que vous allez déterminer si votre application possèdera ou non un mode Trial. Notez que l’application ne peut posséder un mode trial que si elle est payante (cela parait logique).

 

 

Le mode trial peut durer un jour, une semaine, deux semaines, un mois, ou ne jamais expirer. Dans ce cas dernier cas, désactivez certaines features afin de donner l’envie à l’utilisateur d’acheter votre application.

La troisième étape du workflow vous permet de créer les features disponibles via le système d’in-app purchases. Ces features seront déterminées par :

• Un identifiant : correspondant à celui utilisé dans votre application
• Un prix : compris entre 1.19 € et 834.99 € sur le marché français
• Une durée : 1 jour, 3 jours, 5 jours, une semaine, deux semaines, un mois, deux mois, trois mois, six mois, neuf mois, un an ou durée illimitée

 

 

L’exemple ci-dessus définit la feature utilisée dans les exemples précédents. Libre à vous d’en ajouter autant que vous le souhaitez.

Suivez vos applications

Une fois votre application soumise et validée par Microsoft, celle-ci devient disponible sur le Windows Store. Vous pouvez alors vous rendre à nouveau sur le Windows Store Dev Center pour découvrir un Dashboard pour chacune de vos applications soumises et validées. Ce Dashboard vous permet d’accéder à un ensemble d’informations vous permettant :

• d’améliorer votre application
• de la comparer aux autres applications du marché
• de déterminer une stratégie (d’un point de vue business) pour le futur de votre application

Le Dashboard fournit notamment les données suivantes :

• Le nombre de fois où l’application a été vue sur le Store
• Le nombre de téléchargements
• Le nombre d’achats de l’application
• Le nombre d’achats in app
• Les sources de visite de votre application sur le Windows Store
• Le détail des téléchargements et achats par jour
• Une comparaison des détails et achats de votre application avec l’application en ayant réalisés le plus dans la catégorie à laquelle votre application appartient
• La durée d’usage de votre application
• Le nombre d’utilisateurs par jour

Vous pouvez également utiliser le Dev Center pour consulter les feedbacks des utilisateurs, pour découvrir les exceptions levées par votre application, les crash et autres indicateurs de qualités.

Parlons argent !

Si votre application est fonctionnelle et intéressante, celle-ci va forcément vous rapporter de l’argent. Sur l’ensemble des ventes de votre application, 70% vous sera reversé. Lorsque le montant total des ventes de votre application attendra 25 000 $ (ou équivalent dans votre devise), 80 % des ventes vous seront alors reversés.

Chaque mois, Microsoft consulte le montant des ventes de votre application. Si celui-ci est égal à 200 $ (ou équivalent) pour lesquels vous n’avez pas encore été payé, un virement est effectué. Notez que ces 200 $ sont équivalents au montant des ventes, et non pas au montant de ce que vous allez percevoir. Vous devez donc enlever 20 ou 30% selon le montant total des ventes de l’application.

Lorsqu’un utilisateur achète et installe votre application, celle-ci n’est pas liée à son ordinateur, mais à son compte Microsoft. Ainsi, un utilisateur pourra installer une application achetée jusqu’à 5 fois. Cela pourra se faire sur cinq ordinateurs différents, mais également sur un même ordinateur partagé, sur cinq comptes Windows différents.

Lorsque vous déployez une mise à jour de votre application, celle-ci est forcément gratuite pour l’ensemble des utilisateurs ayant déjà acheté votre application. Ainsi, si vous possédez une application initialement achetée à 1.19€ et que le développeur la passe à 1.99€ en incluant une mise à jour, vous pourrez télécharger cette mise à jour gratuitement. La licence acquise lors de l’achat d’une application reste valide durant toute la vie de cette application. En revanche, les nouveaux acheteurs devront bel et bien payer le nouveau prix fixé par le développeur.

Pour publier une application sur le Windows Store, vous devez posséder un compte développeur. Ce compte développeur n’est pas gratuit. Il fait l’objet de frais d’enregistrement annuel. En France, ces frais s’élèvent à 37€ HT pour une personne physique et 75€ HT pour une personne morale.

Enfin, outre les solutions décrites dans cet article, vous pouvez également gagner de l’argent avec votre application en y ajoutant de la publicité (Microsoft Advertising) ou en implémentant votre propre système de transactions.

Aller plus loin

Cet article conclue cette série. De la création d’une application Metro jusqu’au paiement de cette application, en passant par son cycle de vie, le storage, les contrats et l’asynchronisme, toutes les notions indispensables pour créer votre propre application vous ont été présentées.

WinRT ne se limite toutefois pas à cela et de nombreuses autres possibilités s’offrent à vous avec le développement Windows 8. Voici quelques ressources vous permettant d’aller plus loin.

• Dev Center Windows : contient une documentation très fournie et des centaines de samples
• Win8Dev : le site de la communauté française des développeurs Windows 8
• Windows 8 App Developer Blog (MSDN)
• Windows Store for Developers (MSDN)
• Blogs MSDN des évangélistes MS France : David Catuhe, Eric Vernié, Stéphanie Hertrich, David Rousset, Michel Rousseau (design)
• Blogs techniques de membres de la communauté Windows 8 : Jonathan Antoine, Olivier Matis, Thomas Lebrun, John Thiriet, Richard Clark

Enfin, continuez à suivre ce blog, de nombreux articles indépendants sur Windows 8 seront publiés prochainement.

appx, C#, Déploiement, Dev center, In App Purchase, Licensing, money, Store, Trial, WinRT, XAML