Czy ktoś ma jakieś pomysły, jak zresetować i / lub wyczyścić piaskownicę zakupów w aplikacji na iOS?
Mam aplikację, którą testuję przy użyciu piaskownicy i chciałbym przetestować nowe zakupy bez konieczności tworzenia nowego użytkownika testowego za każdym razem, gdy coś kupię.
Jeśli tego nie zrobię, (oczywiście) zawsze otrzymuję komunikat, że element do zakupu w aplikacji został już zakupiony, gdy kliknę przycisk kup w mojej aplikacji.
Odpowiedzi:
IMO są 3 rzeczy, które możesz zrobić, aby testowanie materiałów nieużywalnych było znośne:
Możesz mieć wiele kont testowych powiązanych z jednym adresem e-mail. Na przykład Gmail pozwala na dodanie ciągu znaków „plus” do wiadomości e-mail, aby utworzyć aliasy dla adresu : więc tester+01@gmail.comi tester+02@gmail.comoba tak naprawdę po prostu przejdź do tester@gmail.com. Prawdopodobnie inne hosty poczty e-mail robią to samo. Podczas tworzenia konta testowego musisz podać: imię, nazwisko, adres e-mail, hasło, tajne pytanie, tajną odpowiedź, datę urodzenia i kraj sklepu iTunes. Możesz podać dokładnie te same dane (w tym hasło) dla tester+01@gmail.comi, tester+02@gmail.coma będziesz mieć dwa konta testowe. Wreszcie w swojej tester@gmail.comskrzynce odbiorczej otrzymasz dwa e-maile weryfikacyjne od Apple, aby potwierdzić oba konta testowe.
Powiedz, że masz materiał niezużywalny o identyfikatorze produktu @ „Extra_Levels”. Zamiast wpisywać @ "Extra_Levels" we wszystkich metodach (requestProduct, buyProduct, ...), po prostu napisz PRODUCT_ID1i umieść jakiś plik nagłówkowy #define PRODUCT_ID1 @"Extra_Levels"(bez średnika!), Wtedy preprocesor przeszuka PRODUCT_ID1 i podstawi go za @ "Extra_Levels". Utworzenie nowego nieużywalnego materiału o nazwie @ "Extra_Levels_01" i zmiana #define będzie równie dobre, jak zresetowanie zakupów dla wszystkich użytkowników testowych.
Jak wskazał appsmatics, możesz przetestować poprawne zachowanie swojego kodu, kupując niezużywalny IAP, najpierw używając zużywalnego IAP (aby użytkownik testowy mógł dokonać tylu zakupów, ile potrzeba), aby pozbyć się niektórych błędów. Oczywiście po tym należy również przetestować kod za pomocą rzeczywistego, nie zużywalnego IAP.
+adresów e-mail nie można już używać do rejestracji w celu uzyskania Apple ID.
O ile wiem, nie możesz tego zrobić. Backend piaskownicy działa jak prawdziwe konto - po zakupie jest kupowany (dzięki czemu możesz przetestować przywracanie). Powinieneś robić większość swojego rozwoju z wyrzuconymi elementami sklepu, a kiedy zaczniesz testować go w rzeczywistości, po prostu spodziewaj się utworzenia kilku kont testowych.
SKPaymentTransactionStateRestoredtym, że zamiast tego wracasz ze sklepu z aplikacjami SKPaymentTransactionStatePurchased. Ponieważ nie używasz tutaj prawdziwych pieniędzy, do wszystkich celów i celów, SKPaymentTransactionStateRestoredjest to w 100% równoważne z SKPaymentTransactionStatePurchasedtestowaniem. Zresetowanie stanu aplikacji na „niekupiony” zależy tak naprawdę od Ciebie (po prostu usuń odpowiedni wpis pęku kluczy lub cokolwiek, czego używasz do buforowania tego „kupionego przez użytkownika X”)
Mam 2 elementy do zakupu w aplikacji. 1 do produkcji. a drugi do testów. kiedy muszę „wyczyścić”, usuwam element w aplikacji i tworzę nowy (15 sekund w itunes connect i 1 sekunda na zmianę identyfikatora produktu w kodzie)
jeśli nie muszę testować „nowego użytkownika”, używam produkcji w elemencie aplikacji.
Cóż, technicznie nie potrzebujesz tego.
Jeśli dostaniesz SKPaymentTransactionStateRestored, jest to w 100% równoważne z weryfikacją przez sklep z aplikacjami użytkownika i przyznaniem mu zakupu. Mam włącznik typu:
- (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
}
}
}Kwestia logiki aplikacji / odebrania zakupu jest prosta: jeśli buforujesz zakupy w pęku kluczy, usuń pęku kluczy. Jeśli robisz to w inny sposób, po prostu zmień stan lokalnej aplikacji, aby udawać, że użytkownik nigdy wcześniej jej nie kupił. Okno dialogowe z prośbą o zakup jest nadal dokładnie takie samo, jedyną różnicą jest to, że gdy klikniesz TAK, SKPaymentTransactionStateRestoredzamiast tego otrzymaszSKPaymentTransactionStatePurchased .
Usunięcie aplikacji i ponowna instalacja działa również w przypadku testowania w piaskownicy. Zależy to oczywiście od aplikacji, ale testuję aplikację opartą na subskrypcji, którą w tej chwili kupuje tylko podczas rejestracji, więc było to najłatwiejsze rozwiązanie.
Sprawdź SimStoreKit . To „symulowana wersja StoreKit dla iPhone'a, do testowania interfejsów użytkownika sklepu w symulatorze iPhone'a, a nawet na urządzeniu bez konieczności konfigurowania IAP w Connect”.
SimStoreKit przechowuje zakupy w ustawieniach domyślnych użytkownika pod kluczem ILSimSKTransactions. Aby wyczyścić wszystkie zakupy, które możesz zrobić:
[[NSUserDefaults standardUserDefaults] removeObjectForKey:@"ILSimSKTransactions"]W symulatorze możesz po prostu usunąć aplikację i zainstalować ją ponownie.
Z powodzeniem użyłem SimStoreKit do debugowania strony sklepu mojej aplikacji przed testowaniem w piaskownicy. Piękno tej biblioteki polega na tym, że można ją skonfigurować tak, aby używała tych samych nazw klas, co prawdziwy framework StoreKit (robiąc to #define ILSimReplaceRealStoreKit 1przed wykonaniem #include <ILSimStoreKit.h>).
W plikach źródłowych, do których potrzebuję dostępu do StoreKit, dołączam ten plik nagłówkowy:
#import <TargetConditionals.h>
#if TARGET_IPHONE_SIMULATOR
#define kILSimAllowSimulatedStoreKit 1
#define ILSimReplaceRealStoreKit 1
#import <ILSimStoreKit.h>
#else
#import <StoreKit/StoreKit.h>
#endifMa to wpływ na używanie SimStoreKit, gdy uruchamiam na symulatorze i prawdziwego StoreKit, gdy uruchamiam na urządzeniu.
alternatywnie, aby utworzyć rozwiązanie dla wielu użytkowników testowych, możesz utworzyć wiele testów w zakupach aplikacji w iTunes Connect, a następnie nie musisz zmieniać konta użytkownika.
Po prostu korzystaj z tego samego konta testowego, przywracając zakupy, a nie kończąc nowe. W końcu, niezależnie od tego, czy zaczniesz nowy zakup, czy przywrócisz stary, TWOJA APLIKACJA zrobi to samo (przynajmniej początkowo może interfejs użytkownika zaktualizuje się inaczej po zakończeniu). Apple to ludzie inaczej radzący sobie w różnych sytuacjach - nie martw się o to.
Umieść logikę dostawy w przypadku SKPaymentTransactionStateRestored w ramach implementacji tej metody do testowania:
- (void)paymentQueue:(SKPaymentQueue *)queue
updatedTransactions:(NSArray *)transactions;Następnie pamiętaj, aby umieścić tę logikę dostawy w sprawie SKPaymentTransactionStatePurchased.
Na koniec, ponieważ większość z nas jest w różnym stopniu obsesyjno-kompulsywna, zrób ostatni test z nowym kontem (nie jest to wielka sprawa, aby zrobić drugie dla absolutnej pewności).
Ostatnia rzecz, na którą należy zwrócić uwagę: rozważ stanowisko Apple. Gdyby wystąpił problem z programistami, którzy musieli tracić czas na tworzenie dziesiątek lub setek kont, aby dokładnie przetestować IAP, rozwiązaliby problem. Nie ma problemu.