stored testing productIds about androidbillinglibrary HOT 3 CLOSED

Thanks lorenx.

What would be the advantage of saving all test transactions with the same id?

from androidbillinglibrary.

let's see an example.

i first purchase my product:

requestPurchase("android.test.purchased")

and it stores productId="android.test.purchased", state=0;

then i request a refund:

requestPurchase("android.test.refunded")

and it stores productId="android.test.refunded", state=2;

in the end, isPurchased() method is ambiguous because if i call:

isPurchased("android.test.purchased")

it returns always true.

well, i just think that it has to be the "state" that store the state for the same productId.
am i wrong?

from androidbillinglibrary.

Got it.

While this behavior would certainly be useful for testing, there's no documentation that says that test transactions should be treated like this and they're not treated like this in the official Android In-app Billing example (Dungeons). Thus, we think it's best to leave the identifiers of test transactions unmodified.

That said, isPurchased return true if the id has a purchased transaction and does not consider refunds or cancellations. We need to clarify this on the documentation and maybe add another method that does consider refunds and cancellations. Currently, finer-grain control of this can be achieved with getPurchases, but it's not optimal.

from androidbillinglibrary.