Gérer un vaste catalogue de produits in-app
Si votre application offre un grand catalogue de produits dans l’application, vous pouvez éventuellement suivre le processus décrit dans cette rubrique pour vous aider à gérer votre catalogue. Dans les versions antérieures à Windows 10, le Windows Store a une limite de 200 listes de produits par compte de développeur, et le processus décrit dans cette rubrique peut être utilisé pour contourner cette limitation. À compter de Windows 10, le Windows Store n’a aucune limite au nombre de listes de produits par compte de développeur, et le processus décrit dans cet article n’est plus nécessaire.
Important
Cet article montre comment utiliser les membres de l’espace de noms Windows.ApplicationModel.Store . Cet espace de noms n’est plus mis à jour avec de nouvelles fonctionnalités et nous vous recommandons d’utiliser l’espace de noms Windows.Services.Store à la place. L’espace de noms Windows.Services.Store prend en charge les derniers types d’extensions, tels que les modules complémentaires consommables gérés par le Store et les abonnements, et est conçu pour être compatible avec les futurs types de produits et de fonctionnalités pris en charge par l’Espace partenaires et le Store. L’espace de noms Windows.Services.Store a été introduit dans la version 1607 de Windows 10 et ne peut être utilisé que dans les projets ciblant Windows 10 édition anniversaire (10.0 Build 14393) ou une version ultérieure dans Visual Studio. Pour plus d’informations, consultez Achats in-app et versions d’évaluation.
Pour activer cette fonctionnalité, vous allez créer une poignée d’entrées de produits pour des niveaux de prix spécifiques, chacun pouvant représenter des centaines de produits au sein d’un catalogue. Utilisez la surcharge de méthode RequestProductPurchaseAsync qui spécifie une offre définie par l’application associée à un produit dans l’application répertorié dans le Windows Store. Outre la spécification d’une offre et d’une association de produits pendant l’appel, votre application doit également passer un objet ProductPurchaseDisplayProperties qui contient les détails de l’offre de catalogue volumineux. Si ces détails ne sont pas fournis, les détails du produit répertorié seront utilisés à la place.
Le Windows Store utilise uniquement l’offerId à partir de la demande d’achat dans les AchatsResults résultants. Ce processus ne modifie pas directement les informations fournies à l’origine lors de la description du produit in-app dans le Windows Store.
Prérequis
- Cette rubrique traite de la prise en charge du Windows Store pour la représentation de plusieurs offres dans l’application à l’aide d’un seul produit dans l’application répertorié dans le Windows Store. Si vous n’êtes pas familiarisé avec les achats dans l’application, consultez Activer les achats de produits dans l’application pour en savoir plus sur les informations de licence et comment répertorier correctement votre achat dans l’application dans le Windows Store.
- Lorsque vous codez et testez de nouvelles offres dans l’application pour la première fois, vous devez utiliser l’objet CurrentAppSimulator au lieu de l’objet CurrentApp . De cette façon, vous pouvez vérifier votre logique de licence à l’aide d’appels simulés au serveur de licences au lieu d’appeler le serveur en direct. Pour ce faire, vous devez personnaliser le fichier nommé WindowsStoreProxy.xml dans %userprofile%\AppData\local\packages\package name>\<LocalState\Microsoft\Windows Store\ApiData. Le simulateur Microsoft Visual Studio crée ce fichier lorsque vous exécutez votre application pour la première fois, ou vous pouvez également charger un fichier personnalisé lors de l’exécution. Pour plus d’informations, consultez Utilisation du fichier WindowsStoreProxy.xml avec CurrentAppSimulator.
- Cette rubrique fait également référence à des exemples de code fournis dans l’exemple Store. Cet exemple est un excellent moyen d’obtenir une expérience pratique avec les différentes options de monétisation fournies pour les applications plateforme Windows universelle (UWP).
Effectuez la demande d’achat pour le produit dans l’application
La demande d’achat d’un produit spécifique au sein d’un grand catalogue est gérée de la même façon que toute autre demande d’achat au sein d’une application. Lorsque votre application appelle la nouvelle surcharge de méthode RequestProductPurchaseAsync , votre application fournit à la fois un OfferId et un objet ProductPurchaseDisplayProperties rempli avec le nom du produit in-app.
string offerId = "1234";
string displayPropertiesName = "MusicOffer1";
var displayProperties = new ProductPurchaseDisplayProperties(displayPropertiesName);
try
{
PurchaseResults purchaseResults = await CurrentAppSimulator.RequestProductPurchaseAsync(
"product1", offerId, displayProperties);
switch (purchaseResults.Status)
{
case ProductPurchaseStatus.Succeeded:
// Grant the user their purchase here, and then pass the product ID and transaction ID
// to currentAppSimulator.reportConsumableFulfillment to indicate local fulfillment to
// the Windows Store.
break;
case ProductPurchaseStatus.NotFulfilled:
// First check for unfulfilled purchases and grant any unfulfilled purchases from an
// earlier transaction. Once products are fulfilled pass the product ID and transaction
// ID to currentAppSimulator.reportConsumableFulfillment to indicate local fulfillment
// to the Windows Store.
break;
case ProductPurchaseStatus.NotPurchased:
// Notify user that the purchase was not completed due to cancellation or error.
break;
}
}
catch (Exception)
{
// Notify the user of the purchase error.
}
Signaler l’exécution de l’offre dans l’application
Votre application devra signaler l’exécution du produit au Windows Store dès que l’offre a été remplie localement. Dans un scénario de catalogue volumineux, si votre application ne signale pas l’exécution de l’offre, l’utilisateur ne pourra pas acheter d’offres dans l’application à l’aide de cette même liste de produits du Store.
Comme mentionné précédemment, le Windows Store utilise uniquement les informations d’offre fournies pour remplir les AchatsResults et ne crée pas d’association persistante entre une offre de catalogue volumineux et la description des produits store. Par conséquent, vous devez suivre les droits de l’utilisateur pour les produits et fournir un contexte spécifique au produit (par exemple, le nom de l’élément acheté ou des détails sur celui-ci) à l’utilisateur en dehors de l’opération RequestProductPurchaseAsync .
Le code suivant illustre l’appel de traitement et un modèle de messagerie d’interface utilisateur dans lequel les informations d’offre spécifiques sont insérées. En l’absence de ces informations spécifiques sur le produit, l’exemple utilise des informations du product ListingInformation.
string offerId = "1234";
product1ListingName = product1.Name;
string displayPropertiesName = "MusicOffer1";
if (String.IsNullOrEmpty(displayPropertiesName))
{
displayPropertiesName = product1ListingName;
}
var offerIdMsg = " with offer id " + offerId;
if (String.IsNullOrEmpty(offerId))
{
offerIdMsg = " with no offer id";
}
FulfillmentResult result = await CurrentAppSimulator.ReportConsumableFulfillmentAsync(productId, transactionId);
switch (result)
{
case FulfillmentResult.Succeeded:
Log("You bought and fulfilled " + displayPropertiesName + offerIdMsg);
break;
case FulfillmentResult.NothingToFulfill:
Log("There is no purchased product 1 to fulfill.");
break;
case FulfillmentResult.PurchasePending:
Log("You bought product 1. The purchase is pending so we cannot fulfill the product.");
break;
case FulfillmentResult.PurchaseReverted:
Log("You bought product 1. But your purchase has been reverted.");
// Since the user' s purchase was revoked, they got their money back.
// You may want to revoke the user' s access to the consumable content that was granted.
break;
case FulfillmentResult.ServerError:
Log("You bought product 1. There was an error when fulfilling.");
break;
}