Conversation
emarc-m
left a comment
emarc-m
left a comment
There was a problem hiding this comment.
Taking the discussion internally for now.
| autoParcel : "com.ryanharter.auto.value:auto-value-parcel:${versions.autoParcel}", | ||
| appCompat : "androidx.appcompat:appcompat:${versions.appCompat}", | ||
| supportAnnotations: "androidx.annotation:annotation:${versions.support}", | ||
| supportAnnotations: "com.android.support:support-annotations:${versions.support}", |
There was a problem hiding this comment.
Please clarify why this needs to be reverted to the support lib version.
| tokensToBeConsumed.remove(purchaseToken); | ||
| listener.failure(purchase, getConsumeError(responseCode)); | ||
| if (product.isSubscription()) { | ||
| api.acknowledgePurchase(purchase.token(), new AcknowledgePurchaseResponseListener() { |
There was a problem hiding this comment.
According to the docs, the purchase product needs to be check if it has already been acknowledge: https://developer.android.com/google/play/billing/integrate#process.
suspend fun handlePurchase() {
if (purchase.purchaseState === PurchaseState.PURCHASED) {
if (!purchase.isAcknowledged) {
val acknowledgePurchaseParams = AcknowledgePurchaseParams.newBuilder()
.setPurchaseToken(purchase.purchaseToken)
val ackPurchaseResult = withContext(Dispatchers.IO) {
client.acknowledgePurchase(acknowledgePurchaseParams.build())
}
}
}
}What will be the effect if a purchase is repeatedly acknowledge?
I this something that the backend does?
Subscriptions are handled similarly to non-consumables. You can acknowledge a subscription Acknowledgement using either BillingClient.acknowledgePurchase() from the Google Play Billing Library or Purchases.Subscriptions.Acknowledge from the Google Play Developer API. All initial subscription purchases need to be acknowledged. Subscription renewals do not need to be acknowledged. For more information on when subscriptions need to be acknowledged, see the Sell subscriptions topic.
| @Override | ||
| public void onSkuDetailsResponse(int responseCode, List<SkuDetails> skuDetailsList) { | ||
| if (responseCode == BillingResponse.OK && skuDetailsList.size() == 1) { | ||
| public void onSkuDetailsResponse(BillingResult result, List<SkuDetails> skuDetailsList) { |
There was a problem hiding this comment.
nit: Please add the nullability annotation to the implementation:
void onSkuDetailsResponse(@NonNull BillingResult var1, @Nullable List<SkuDetails> var2);Please see other implementations for this.
| api project(':cashier') | ||
|
|
||
| compileOnly deps.autoValue | ||
| \ |
| if (accountId != null) { | ||
| throw new IllegalArgumentException("Account id is not supported!"); | ||
| } |
There was a problem hiding this comment.
Is it valid to throw the exception here? I know this is similar to the developerPayload but I think accountId is optional.
2 participants
This PR. updates Google Billing API to version 4.0.0.
AutoParcelto work, so allParcelableobjects are implemented by hand.consumecashier API.