
Trend-Einblicke
September 7, 2022
Updated: März 20, 2023
Heute kommen wir auf die Fehlercodes zu sprechen, die wir von der Billing Library in der getResponseCode() Methode erhalten können.
Ein Beispiel dafür, wie wir Fehler zu unseren Callbacks geleitet haben, finden Sie in diesem Artikel. Wir haben bereits einen der Fehler in vorherigen Artikeln betrachtet, nämlich USER_CANCELED, der auftritt, wenn ein Nutzer den Kaufdialog schließt, ohne etwas zu kaufen. Lassen Sie uns weitere Fehler kennenlernen.
Lassen Sie uns mit den als ERROR (responseCode 6) und DEVELOPER_ERROR (responseCode 5) bezeichneten Fehlern beginnen. Im erst genannten Fall schreibt Google in der Dokumentation „Fatal error during the API action“. Im anderen genannten Fall erscheint „Invalid arguments provided to the API“. Ich habe beispielsweise einen DEVELOPER_ERROR erhalten, wenn ich einen leeren String zum Builder in setType() für die querySkuDetailsAsync() Anfrage geschickt habe.
Aber so einfach ist das nicht. Ich ging einen Schritt weiter und nutzte in der launchBillingFlow() Methode die modifizierten SkuDetails (die ich aus dem json der SkuDetails des echten Produkts erhalten, dann die productID darin geändert und sie zum SkuDetails Constructor geschickt habe). Das ist im Grunde ein Invalid Argument und ich erwartete einen DEVELOPER_ERROR, bekam aber…einen ERROR.
Das war natürlich ein künstlich herbeigeführtes Beispiel. Wenn Google die Zahlung ablehnt, ist dies deutlich realer. Wenn Sie im Kaufdialog beim Testen mit einer Testkarte „test card, always declined“ auswählen (worauf wir noch am Ende dieses Artikels zu sprechen kommen), kommt es ebenfalls zu einem ERROR, allerdings mit richtigem Text.
Im dritten Artikel, in dem es um die Abonnement-Änderung ging, haben wir den Preis eines Jahresabonnements für einen der Prorationsmodus fast verdreifacht, aber nicht erwähnt, welcher Fehler auftreten würde, hätten wir das nicht getan. Wir geloben Besserung.
Wir haben herausgefunden, dass der falsche Prorationsmodus angegeben ist und sollten logischerweise den gleichen DEVELOPER_ERROR erhalten. Stattdessen erhalten wir SERVICE_UNAVAILABLE (responseCode 2). Diesen erhalten wir auch, wenn wir unpassende Zahlen als Prorationsmodus eingeben (also int statt enum) und wenn wir den falschen purchaseToken bestimmen. Wir schauen in der Dokumentation SERVICE_UNAVAILABLE an und…was?! Wir sehen, dass die „Netzwerkverbindung abgebrochen sei.“.
Gleichzeitig erhalten wir dieses seltsame Dialogfenster:
Es gibt noch eine weitere interessante Sache im Falle des ERROR. Wenn wir nämlich den Dialog NICHT per „OK“ Button schließen (was als “zurückgehen” interpretiert wird), kommt der ERROR zu onPurchasesUpdated(). Im Falle von SERVICE_UNAVAILABLE in einer ähnlichen Situation kommt USER_CANCELED (wenn Sie aber im Dialog auf „OK“ klicken, erhalten wir SERVICE_UNAVAILABLE wie erwartet).
Im Falle einer verlorenen Internetverbindung kommt tatsächlich SERVICE_UNAVAILABLE.
Hier sind einige weitere Fehlercodes mit kurzen Kommentaren, um sie wenigstens einmal erwähnt zu haben.
Der letzte und vermutlich häufigste Fehler zu Beginn der Implementierung von In-App-Käufen ist ITEM_UNAVAILABLE (responseCode 4). Dieser besagt, dass das Produkt nicht zum Kauf zur Verfügung steht, erklärt aber nicht, warum. Dies kann verschiedene Gründe haben: vom Testen im falschen Konto oder Gerät bis zum Kauf eines inaktiven Produkts.
Überprüfen Sie folgende Punkte, um diesen Fehler beim Testen zu vermeiden:
1. Senden Sie eine App mit der Billing Library an Ihren Test Track. Dies ist eine zwingende Bedingung. Gleichzeitig können Sie auch mit derselben ApplicationID auf Debug Builds testen. Es ist aber wichtig, dass die App mit der Billing Library mindestens einmal in die Play Console hochgeladen wurde.
2. Fügen Sie diesem Test Track Google Konten der Tester hinzu, was besonders für das interne Testen oder in der Closed Alpha/Beta wichtig ist. Es wird auch einen Link in Wie Tester Ihren Testbereich beitreten geben. Die Tester sollten diese Einladung annehmen.
3. Sie können nur ein aktiviertes Produkt kaufen. Nach der Erstellung eines Produkt gibt es einen Aktivieren Button in der Play Console. Wir haben den Vorgang der Produkterstellung im ersten Artikel genauer beschrieben.
4. Achten Sie darauf, dass das Testen am Gerät über ein Google Konto eines Testers erfolgt (was bedeutet, dass es als Tester in diesem Test Track angemeldet ist und den nötigen technischen Zugang hat). Dieser Punkt scheint offensichtlich, wird aber immer wieder gerne übersehen.
5. Die ApplicationID des Builds, das für den Kauftest genutzt wird, muss zur ApplicionID aus der Play Console passen. Dies ist besonders dann wichtig, wenn Sie in Ihren Debug Builds Suffixe hinzugefügt haben.
6. Fügen Sie die E-Mail-Adressen der Tester über Setup → License Testing im linken Menü des Kontos hinzu (nicht die App), sodass sie die Produkte kostenlos von einer Testkarte kaufen und nicht mit einer echten. Ein weiterer Vorteil besteht darin, dass die Abonnements in diesem Fall eine Testdauer haben. Dies hat nichts mit diesem Fehler zu tun, ist aber gut zu wissen.
Fehler können die Arbeit erheblich erschweren. Es ist wichtig, sie zu kennen und zu verstehen, warum sie auftreten. Wenn man bedenkt, wie viele Schritte Sie durchlaufen müssen, um Zugriff auf Produkte zu erhalten, ist es am einfachsten, ITEM_UNAVAILABLE abzufangen. Ich hoffe sehr, dass Ihnen meine Checkliste weiterhilft.
The Adapty SDK erleichtert die Lösung der Fehler und bietet Ihnen viele weitere Vorteile wie grundlegende Abonnement-Analysen, Kohorten-Analysen, ein einfaches Testen von Paywalls, die Integration mit Analysediensten oder auch eine Serverfehlervalidierung. Probieren Sie es aus!
Further reading
Trend-Einblicke
September 7, 2022