Altova MobileTogether Designer

Les pages précédentes de cette section décrivaient les principaux composants du mécanisme d'achats In-App de MobileTogether Designer. Dans cette page, nous recensons et décrivons brièvement les autres composants clés du mécanisme.

Vérifier disponibilité du service d'achat In-app

Vous pouvez utiliser une fonction dénommée mt-in-app-purchase-service-started() pour vérifier si le service d'achat in-app a démarré sur l'appareil client. Pour plus de détails, voir les pages Fonctions d'extension de MobileTogether et Exemple de projet : disponibilité de service In-App.

Vérifier la réponse de l'app store du dernier achat in-app

Les fonctions d'extension de MobileTogether suivantes peuvent être utilisées pour vérifier le succès de la dernière requête à l'app store qui a été associée à un achat in-app :

•mt-last-in-app-purchase-response-code()

•mt-last-in-app-purchase-response-text()

•mt-last-in-app-purchase-response-was-user-canceled()

Ceci vous permet de rendre la prochaine étape dans le flux de travail dépendante du succès de l'étape actuelle. Pour prendre un exemple, veuillez voir les actions de l'événement OnPurchaseUpdated dans l'Exemple de projet. Veuillez noter que ces fonctions peuvent être utilisées pour obtenir la réponse de l'app store en ce qui concerne la dernière requête envoyée qui a été associée à un achat in-app.

Un app store peut répondre avec un nombre illimité de réponses, dépendant de quel app store il s'agit. Un code 0 indique une opération réussie. Les autres codes indiquent différents types d'échec. La fonction qui renvoie le texte de réponse fournirait plus d'information sur l'échec. Toutefois, un des types d'échec devrait être géré différemment puisqu'il ne s'agit pas d'une erreur. Ceci serait le cas quand l'utilisateur final annule un achat. Pour faire la différence entre ce type d'échec de l'achat et des erreurs, MobileTogether fournit la fonction mt-last-in-app-purchase-response-was-user-canceled.

OnPurchaseUpdated : quand l'app store accepte une requête d'achat

Lorsqu'un app store accepte une demande d'achat, l'achat est automatiquement ajouté à la Source de page d'achat In-App. L'achat est donc mis à jour (dans la source de page) et l'événement OnPurchaseUpdated est déclenché. Une séquence d'actions peut être défini pour l'événement, ce qui vous permet d'exécuter des actions en continu sans avoir besoin d'input de l'utilisateur, une fois que la demande d'achat a été acceptée. Par exemple, vous allez vouloir accuser réception d'un achat directement une fois qu'il a été accepté (voir la prochaine section ci-dessous). Pour avoir accès au dialogue Actions de l'événement, allez à la propriété du projet Actions d'achat In-App.

Veuillez noter les points suivants sur les actions de l'événement OnPurchaseUpdated :

•Pendant que les actions de l'événement OnPurchaseUpdated sont traitées, la variable \$MT_UpdatedInAppPurchases a une portée. La variable contient une séquence de strings, qui sont les ID_SKU de produits achetés mis à jour dans la Source de page d'achat In-App. Donc, si un élément a été acheté, l'ID_SKU peut être obtenue avec une expression XPath \$MT_UpdatedInAppPurchases[1]. La variable se met en mode hors de portée une fois que les actions de l'événement ont été traitées. Ceci signifie que la variable ne peut être utilisée que dans des actions de l'événement OnPurchaseUpdated.

•Dans la Source de page d'achat In-App, chaque élément Purchase a un attribut PurchaseState qui prend une valeur soit de PENDING ou PURCHASED. Vous allez vouloir modifier correctement votre flux de travail afin de tenir compte de ce statut.

Pour un exemple (i) du genre d'actions qui peuvent être définies pour l'événement OnPurchaseUpdated et (ii) comment utiliser la variable

\$MT_UpdatedInAppPurchases, voir la description de cet événement dans un exemple de projet :                  

l'Événement OnPurchaseUpdated.

Activer le produit

Activez le produit acheté dans l'appli. Après avoir vérifié l'état de l'achat, la validité de l'abonnement, une annulation éventuelle etc., de l'achat, vous allez devoir activer le produit en conséquence. Il s'agit ici d'une étape que vous allez devoir faire vous-même en tant que designer de l'appli ; MobileTogether ne peut pas le faire automatiquement pour vous.

Accusé de réception d'un Achat

Une fois que l'utilisateur final a acheté un produit via un achat in-app, l'app store accepte la demande et envoie une information sur l'achat à l'appli. Après réception de cette information, l'appli doit accuser réception de l'achat, et ceci est une chose que vous, en tant que designer de l'appli, devez faire discrètement sans impliquer l'utilisateur final. L'étape de l'accusé de réception permet à l'appli de traiter l'information reçue par l'app store afin de déterminer si l'achat est légitime et si l'achat peut être conclu par le vendeur. Ceci vous permet, en tant que designer de l'appli, de vérifier différents aspects de l'achat. Les app stores fournissent des informations détaillées sur l'évaluation que vous devez réaliser avant d'accuser réception de l'achat. Veuillez lire attentivement l'information pertinente dans l'app store avant de décider quelles étapes à prendre avant d'accuser réception de l'achat. Ce n'est qu'une fois que vous avez accusé réception de l'achat que l'app store traitera le paiement et l'acheminera vers le compte du propriétaire du compte.

Les achats sont confirmés par le biais de l'action Accuser réception d'un achat de MobileTogether, et le plus judicieux est d'inclure cette action comme l'une de celles qui doivent être effectuées quand l'événement OnPurchaseUpdated est déclenché (voir la section précédente ci-dessus).

Pour tout détail concernant cette action, voir la description de l'action d'Accuser réception d'un achat et la description de sa mise en œuvre dans l'exemple de projet.

Interroger les stores pour des données d'achat

Vous pouvez interroger l'app store pour tous les achats traités par l'utilisateur actuel. L'action à cette fin est l'action Requête achats. Lorsque l'action est exécutée, l'app store renvoie les données sur les achats de l'utilisateur, et les points de données clés sont stockés dans l'élément Purchases de la Source de page d'achat In-App. Chaque achat est stocké dans un élément Purchase individuel. Vous pouvez ensuite utiliser ces données d'achat dans le flux de travail de l'appli. Pour des informations détaillées, voir la description de l'action Requête achats et la description du bouton Requête achats dans l'exemple de projet.

Restaurer les achats (iOS uniquement)

L'Apple Store garde un enregistrement de tous les achats de l'utilisateur final et permet à l'utilisateur final de restaurer tous les achats dans un appareil iOS à tout moment. L'action Restaurer les achats peut être utilisée pour interroger l'Apple Store sur tous les achats d'un utilisateur final. Les données renvoyées sont stockées dans l'élément Purchases de la Source de page d'achat In-App, avec chaque achat étant stocké dans l'élément Purchase individuel. Vous pouvez ensuite utiliser ces données d'achat dans le flux de travail de l'appli. Pour toute information détaillée, voir la description de l'action Restaurer les achats et la description du bouton Restaurer les achats dans l'exemple de projet.

Obtenir/Rapporter Consommables (uniquement Windows)

Après avoir acheté un consommable, il peut être consommé dans l'appli. Dans le cas des applis de Windows, l'app store de Windows propose l'option de garder un enregistrement dans le solde consommable d'un utilisateur. L'action Obtenir/Rapporter Consommable aborde cette option de Windows. Elle peut obtenir le solde actuel de l'app store de Windows et rapporter le niveau d'épuisement du consommable à l'app store de Windows. Pour plus de détails, voir la description de l'action.

Suivre le statut de l'activation du produit

Il vous incombe de déterminer si un produit est actif au sein de l'appli à tout moment. Cette décision s'appuierait sur les facteurs suivants :

•Le PurchaseState du produit rapporté par l'app store.

•Dans le cas des produits consommables, le niveau actuel du crédit consommable. Vous allez devoir le suivre dans votre appli.

•Dans le cas des abonnements, le niveau actuel de l'abonnement relatif à la date d'entrée en vigueur et à la période de l'abonnement.

•Tout autre facteur qui affecte le statut de l'activation du produit, tel qu'une période d'extension gratuite pour un abonnement.

Interfaces REST

Vous pouvez également utiliser des interfaces REST aussi longtemps qu'elles sont prises en charge sur les plate-formes respectives. L'utilisation des interfaces REST avec les applis de l'AppStore sur Android a été testée et la documentation de ces interfaces est disponible sous : https://developers.google.com/android-publisher/api-ref/rest.