Effacement des achats à partir du bac à sable d'achat intégré iOS pour un utilisateur test

Quelqu'un a-t-il des idées sur la façon de réinitialiser et / ou d'effacer le bac à sable d'achat dans l'application iOS?

J'ai une application que je teste avec le bac à sable et j'aimerais tester de nouveaux achats sans avoir à créer un nouvel utilisateur de test à chaque fois que j'achète quelque chose.

Si je ne le fais pas, je reçois (bien sûr) toujours un message indiquant que l'article d'achat dans l'application a déjà été acheté lorsque je clique sur le bouton d'achat de mon application.

IMO, il y a 3 choses que vous pouvez faire pour rendre les tests de non-consommables supportables:

1. Vous pouvez avoir plusieurs comptes de test associés à un e-mail. Gmail, par exemple, vous permet d'ajouter une chaîne «plus» à l'e-mail pour créer des alias pour une adresse : donc tester+01@gmail.comet les tester+02@gmail.comdeux vont vraiment à tester@gmail.com. Probablement d'autres hôtes de messagerie font de même. Lorsque vous créez un compte de test, vous devez indiquer: prénom, nom, adresse e-mail, mot de passe, question secrète, réponse secrète, date de naissance et pays de l'iTunes Store. Vous pouvez mettre exactement les mêmes données (y compris le mot de passe) pour tester+01@gmail.comet tester+02@gmail.comet vous aurez deux comptes de test. Enfin, dans votre tester@gmail.comboîte de réception, vous recevrez deux e-mails de vérification d'Apple pour confirmer les deux comptes de test.

2. Supposons que vous ayez un non-consommable avec l'ID de produit @ "Extra_Levels". Au lieu d'écrire @ "Extra_Levels" dans toutes les méthodes (requestProduct, purchaseProduct, ...), écrivez simplement PRODUCT_ID1et placez un fichier d'en-tête #define PRODUCT_ID1 @"Extra_Levels"(sans point-virgule!), Puis le préprocesseur recherchera PRODUCT_ID1 et le remplacera par @ "Extra_Levels". Ensuite, créer un nouveau non-consommable appelé @ "Extra_Levels_01" et changer la #define sera aussi bon que de réinitialiser les achats pour tous vos utilisateurs de test.

3. Comme l'a souligné appsmatics, vous pouvez tester le comportement correct de votre code lorsque vous achetez un IAP non consommable en utilisant d'abord un IAP consommable (afin que l'utilisateur test puisse effectuer autant d'achats que nécessaire) pour éliminer certains bogues. Bien sûr, vous devriez également tester le code avec le vrai IAP non consommable après cela.

Vous ne pouvez pas faire ça, pour autant que je sache. Le backend sandbox fonctionne comme un vrai compte - une fois acheté, il est acheté (et vous pouvez donc tester la restauration). Vous devriez faire la majeure partie de votre développement avec les éléments du magasin, puis lorsque vous le testez pour de vrai, attendez-vous simplement à créer plusieurs comptes de test.

J'ai 2 articles d'achat dans l'application. 1 pour la production. et l'autre pour les tests. lorsque j'ai besoin de "effacer", je supprime l'élément dans l'application et en crée un nouveau (15 secondes dans iTunes se connectent et 1 seconde pour modifier l'identifiant du produit dans le code)

si je n'ai pas besoin de tester "nouvel utilisateur", j'utilise l'élément de production dans l'application.

Eh bien, techniquement, vous n'en avez pas besoin.

Si vous obtenez SKPaymentTransactionStateRestored, cela équivaut à 100% à ce que l'App Store vérifie l'utilisateur et lui accorde l'achat. J'ai un interrupteur comme:

- (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions
{
  for( SKPaymentTransaction *purch in transactions )
  {
    switch( purch.transactionState )
    {
      case SKPaymentTransactionStateRestored:
        info( "PURCHASE RESTORE" ) ;
        // fall thru
      case SKPaymentTransactionStatePurchased:
        [[SKPaymentQueue defaultQueue] finishTransaction:purch];
        // Do regular changes to app state for this purchase,
        // register in keychain, etc.
        break ;

       //.. other cases
     }
  }
}

La question de la logique de votre application / de la reprise de l'achat est simple: si vous mettez en cache des achats dans le trousseau, supprimez votre trousseau. Si vous le faites d'une autre manière, changez simplement l'état de votre application locale pour faire comme si l'utilisateur ne l'avait jamais achetée auparavant. La boîte de dialogue de demande d'achat est toujours exactement la même, la seule différence est que lorsque vous pointez OUI, cela vous donne à la SKPaymentTransactionStateRestoredplace de SKPaymentTransactionStatePurchased.

La suppression de votre application et la réinstallation fonctionnent également pour les tests de sandbox. Cela dépend évidemment de l'application, mais je teste une application basée sur un abonnement qui n'achète que lors de l'inscription pour le moment, c'est donc la solution la plus simple.

Découvrez SimStoreKit . Il s'agit d'une "version simulée du StoreKit de l'iPhone, pour tester les interfaces utilisateur des magasins sur iPhone Simulator, ou même sur l'appareil sans avoir à configurer IAP dans Connect."

SimStoreKit stocke les achats dans les valeurs par défaut de l'utilisateur sous la clé ILSimSKTransactions. Donc, pour effacer tous les achats, vous pouvez faire:

[[NSUserDefaults standardUserDefaults] removeObjectForKey:@"ILSimSKTransactions"]

Sur le simulateur, vous pouvez simplement supprimer votre application et la réinstaller.

J'ai utilisé avec succès SimStoreKit pour déboguer la vitrine de mon application avant de tester avec le bac à sable. La beauté de cette bibliothèque est qu'elle peut être configurée pour utiliser les mêmes noms de classe que le véritable framework StoreKit (en faisant #define ILSimReplaceRealStoreKit 1avant de faire #include <ILSimStoreKit.h>).

Dans les fichiers source où j'ai besoin d'accéder à StoreKit, j'inclus ce fichier d'en-tête:

#import <TargetConditionals.h>

#if TARGET_IPHONE_SIMULATOR
    #define kILSimAllowSimulatedStoreKit 1
    #define ILSimReplaceRealStoreKit 1
    #import <ILSimStoreKit.h>
#else
    #import <StoreKit/StoreKit.h>
#endif

Cela a pour effet d'utiliser SimStoreKit lorsque je cours sur le simulateur et le vrai StoreKit lorsque je cours sur l'appareil.

Alternativement, pour créer plusieurs solutions utilisateur de test, vous pouvez créer plusieurs tests d'achats d'applications dans iTunes connect, vous n'avez pas besoin de changer de compte utilisateur.

Continuez simplement à utiliser le même compte de test, en restaurant les achats plutôt qu'en en complétant de nouveaux. Après tout, que vous démarriez un nouvel achat ou que vous restauriez un ancien, VOTRE APP fera la même chose (au moins au début, peut-être que l'interface utilisateur se mettra à jour différemment à la fin). Apple gère les choses différemment dans ces différentes situations - ne vous en faites pas.

Placez votre logique de livraison dans le cas SKPaymentTransactionStateRestored dans l'implémentation de cette méthode pour les tests:

- (void)paymentQueue:(SKPaymentQueue *)queue
 updatedTransactions:(NSArray *)transactions;

Assurez-vous ensuite de placer cette logique de livraison dans le cas SKPaymentTransactionStatePurchased.

À la fin, parce que la plupart d'entre nous sont obsessionnels-compulsifs à des degrés divers, faites un test final avec un nouveau compte (pas un gros problème pour en faire un deuxième pour une certitude absolue).

La dernière chose à noter: considérez la position d'Apple. S'il y avait un problème avec les développeurs qui devaient perdre du temps à créer des dizaines ou des centaines de comptes pour tester en profondeur IAP, ils auraient résolu le problème. Il n'y a pas de problème.