La compensation des achats à partir d'IOS in-app achat bac à sable pour un utilisateur de test

Question

Quelqu'un aurait-il des idées sur la façon de restaurer et/ou de l'effacer IOS in-app achat sandbox? J'ai une application que je suis en essais avec la sandbox, et je voudrais tester de nouveaux achats sans avoir à créer un nouvel utilisateur de test à chaque fois que je acheter quelque chose. Si je ne fais pas ça, alors j'ai (bien sûr) toujours obtenir un message que l'achat dans l'application de l'élément a déjà été acheté quand je clique sur mon application sur le bouton acheter.

Answer 1

IMO il y a 3 choses que vous pouvez faire pour faire le test de non-consommables supportable:

1. Vous pouvez avoir plusieurs comptes de test associé à un e-mail. Gmail, par exemple, permet d'ajouter un "plus" de la chaîne de l'e-mail de créer des alias pour une adresse: si tester+01@gmail.com et tester+02@gmail.com à la fois très juste aller à l' tester@gmail.com. Probablement d'autres e-mail hôtes en faire de même. Lorsque vous créez un compte de test, vous devez présenter: nom, prénom, adresse email, mot de passe, question secrète, la réponse secrète, date de naissance, et de l'iTunes store pays. Vous pouvez mettre exactement les mêmes données (y compris le mot de passe) tester+01@gmail.com et tester+02@gmail.com et vous avez deux comptes de test. Enfin, dans votre tester@gmail.com boîte de réception, vous recevrez deux emails de vérification de la Pomme à confirmer à la fois des comptes de test.

2. Dire que vous avez un non-consommable avec ID de produit @"Extra_Levels". Au lieu d'écrire @"Extra_Levels" dans toutes les méthodes (requestProduct, purchaseProduct, ...), écrivez - PRODUCT_ID1 et à un fichier d'en-tête mis #define PRODUCT_ID1 @"Extra_Levels" (avec pas de point-virgule!), puis le préprocesseur va rechercher PRODUCT_ID1 et de la remplacer par @"Extra_Levels". Ensuite, la création d'un nouveau non-consommable appelé @"Extra_Levels_01" et la modification de la #define sera aussi bonne que la réinitialisation des achats pour tous vos utilisateurs de test.

3. Comme appsmatics souligné, vous pouvez tester le bon comportement de votre code lorsque vous achetez un non-consommation de l'IAP, en utilisant d'abord un consommable PEI (de sorte que l'utilisateur de test peut se faire de nombreux achats selon les besoins) pour se débarrasser de quelques bugs. Bien sûr, vous devez également tester le code avec le réel non consommable PEI après.

Answer 2

Vous ne pouvez pas faire cela, autant que je sache. Le bac à sable backend fonctionne comme un compte réel-- une fois qu'il est acheté, il est acheté (et donc vous pouvez tester la restauration). Vous devriez faire la plupart de votre développement avec le magasin des trucs calée, et puis quand vous arrivez à le tester pour de vrai, il suffit de s'attendre à la création de plusieurs comptes de test.

Answer 3

J'ai 2 en application de l'achat des articles. 1 pour la production. et l'autre pour le test. quand j'ai besoin de "clair" - je supprimer l'app élément et en créer de nouveaux (15 secondes dans itunes connect et 1 seconde pour changer l'id de produit dans le code)

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

Answer 4

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

Si vous obtenez SKPaymentTransactionStateRestored, il est de 100%, l'équivalent de l'app store de la vérification de l'utilisateur et de lui accorder 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 d'avoir votre application logique / reprendre l'achat est simple: si vous êtes à la mise en cache des achats dans le trousseau d'accès, de supprimer votre trousseau de clés. Si vous êtes en train de faire d'une autre façon, il suffit de changer votre local de l'application de l'état à faire semblant comme si l'utilisateur n'a jamais acheté auparavant. La demande d'achat de boîte de dialogue est toujours exactement la même, la seule différence, c'est quand vous frappez OUI, il vous donne SKPaymentTransactionStateRestored au lieu de SKPaymentTransactionStatePurchased.

Answer 5

Découvrez SimStoreKit. C'est une "version simulée de l'iPhone StoreKit, pour essayer de le stocker de l'Isu sur le Simulateur d'iPhone, ou même sur l'appareil sans avoir à mettre en place du PEI dans le Connecter."

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

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

Sur le simulateur, vous pouvez simplement supprimer votre application et de l'installer à nouveau.

J'ai utilisé avec succès SimStoreKit pour déboguer mon app store front avant de tester avec le bac à sable. La beauté de cette bibliothèque est qu'il peut être configuré pour utiliser les mêmes noms de classes comme le véritable StoreKit cadre (en faisant #define ILSimReplaceRealStoreKit 1 avant #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 de l'utilisation de SimStoreKit quand je le lance sur le simulateur et le réel StoreKit lorsque je l'exécute sur le périphérique.