Очищення покупок у тестовому користувачі через пісочницю покупки через додаток iOS

Хтось має ідеї, як скинути та / або очистити пісочницю покупки в додатку iOS?

У мене є додаток, який я тестую з пісочницею, і я хотів би протестувати нові покупки, не створюючи нового тестового користувача кожного разу, коли я щось купую.

Якщо я цього не роблю, то, звичайно, завжди отримую повідомлення про те, що товар про придбання через додаток уже придбано, коли натискаю кнопку покупки додатка.

IMO Є три речі, які можна зробити, щоб зробити тестування не витратні матеріали:

1. Ви можете мати багато тестових облікових записів, пов’язаних з однією електронною поштою. Наприклад, Gmail дозволяє додавати рядок "плюс" до електронної пошти, щоб створити псевдоніми для адреси : тож tester+01@gmail.comі те й tester+02@gmail.comінше просто перейти tester@gmail.com. Можливо, інші хости електронної пошти роблять те ж саме. Під час створення тестового облікового запису потрібно ввести: ім’я, прізвище, електронну адресу, пароль, таємне запитання, таємну відповідь, дату народження та країну магазину iTunes. Ви можете ввести абсолютно однакові дані (включаючи пароль) для tester+01@gmail.comі, tester+02@gmail.comі ви матимете два тестових акаунта. Нарешті, у вашу tester@gmail.comпоштову скриньку ви отримаєте два повідомлення для підтвердження від Apple для підтвердження обох тестових акаунтів.

2. Скажіть, що у вас немає споживчого товару з ідентифікатором продукту @ "Extra_Levels". Замість того, щоб писати @ "Extra_Levels" у всіх методах (requestProduct, purchaseProduct, ...), просто напишіть PRODUCT_ID1і в якийсь файл заголовка поставте #define PRODUCT_ID1 @"Extra_Levels"(без крапки з комою!), Тоді препроцесор здійснить пошук PRODUCT_ID1 і замінить його на @ "Extra_Levels". Тоді створити новий неспоживний під назвою @ "Extra_Levels_01" та змінити #define буде так само добре, як і скинути покупки для всіх ваших користувачів тесту.

3. Як зазначав appsmatics, ви можете перевірити правильність поведінки свого коду, купуючи неспоживаючий IAP, спочатку скориставшись споживчим IAP (щоб користувач-тест міг зробити стільки покупок, скільки потрібно), щоб позбутися деяких помилок. Звичайно, ви також повинні перевірити код за допомогою справжнього неспоживного IAP після цього.

Ви не можете цього зробити, наскільки я знаю. Бенкенд пісочниці працює як справжній рахунок - після його придбання він купується (і таким чином ви можете перевірити відновлення). Ви повинні робити більшу частину свого розвитку, коли речі в магазині вимкнулися, і тоді, коли ви перейдете до тестування справжнього, просто розраховуйте створити кілька тестових облікових записів.

У мене є 2 елементи для придбання додатків. 1 для виробництва. а інший для тестування. коли мені потрібно "очистити", я видаляю елемент додатка і створюю новий (15 секунд під час підключення в itunes і 1 секунда для зміни ідентифікатора продукту в коді)

якщо мені не потрібно тестувати "нового користувача", я використовую продукцію в додатку.

Ну, технічно це вам не потрібно.

Якщо ви отримаєте SKPaymentTransactionStateRestored, це 100% еквівалент магазину додатків, який підтверджує користувача та надає йому покупку. У мене є перемикач, як:

- (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
     }
  }
}

Питання щодо логіки вашої програми / повернення покупки простий: якщо ви кешуєте покупки в брелок, видаліть брелок. Якщо ви робите це іншим способом, просто змініть стан місцевого додатка, щоб зробити вигляд, як користувач ніколи його не купував. Діалог запиту на придбання все одно точно такий же, різниця полягає лише в тому, що ви пробиваєте ТАК, він дає вам SKPaymentTransactionStateRestoredзамість SKPaymentTransactionStatePurchased.

Видалення програми та перевстановлення працює також для тестування пісочниці. Залежно від програми, очевидно, але я тестую додаток на основі підписки, який купує лише під час реєстрації, тому це було найпростішим рішенням.

Перевірте SimStoreKit . Це "імітація версії iPhone StoreKit для тестування інтерфейсів магазину на iPhone Simulator або навіть на пристрої без встановлення IAP в Connect".

SimStoreKit зберігає покупки за замовчуванням користувача під клавішею ILSimSKTransactions. Отже, щоб очистити всі покупки, які ви можете зробити:

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

На тренажері ви можете просто видалити додаток і встановити його знову.

Я успішно використовував SimStoreKit для налагодження передньої частини магазину перед тестуванням з пісочницею. Краса цієї бібліотеки полягає в тому, що вона може бути налаштована на використання тих самих імен класів, що і реальна рамка StoreKit (виконуючи її #define ILSimReplaceRealStoreKit 1перед тим, як робити #include <ILSimStoreKit.h>).

У вихідні файли, де мені потрібно отримати доступ до StoreKit, я включаю цей файл заголовка:

#import <TargetConditionals.h>

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

Це спричиняє використання SimStoreKit під час запуску на тренажері та реального StoreKit під час роботи на пристрої.

альтернативно, щоб створити кілька тестових користувальницьких рішень, ви можете створити кілька тестів у покупках додатків у iTunes connect, тоді вам не потрібно змінювати обліковий запис користувача.

Просто продовжуйте використовувати один і той же тестовий рахунок, відновлюючи покупки на відміну від заповнення нових. Зрештою, незалежно від того, розпочавши нову покупку чи відновите стару, ВАШЕ ДОДАТКУ зробить те саме (принаймні спочатку, можливо, після завершення користувальницький інтерфейс оновиться інакше). Яблуко - це люди, які по-різному поводяться з речами в різних ситуаціях - не турбуйтеся про це.

Розмістіть логіку доставки у випадку SKPaymentTransactionStateRestored в рамках здійснення цього методу для тестування:

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

Тоді обов'язково введіть цю логіку доставки у корпус SKPaymentTransactionStatePurchased.

Зрештою, через те, що більшість із нас в різній мірі нав'язливо-нав'язливі, робіть остаточний тест із новим рахунком (не велика справа робити другий для абсолютної впевненості).

Остаточне, що слід зазначити: врахуйте позицію яблука. Якби розробникам довелося витрачати час на створення десятків чи сотень облікових записів, щоб ретельно перевірити IAP, вони вирішили б цю проблему. Немає жодних проблем.