Sample code should only restoreTransactions() on install

[GoogleCodeExporter]

The sample code should only call restoreTransactions() on first install (or if 
explicitly forced).

Calling restoreTransactions() too frequently can lead to quota errors -- we 
want to discourage behavior that might lead to this.

Original issue reported on code.google.com by trevorjohns@google.com on 20 Apr 2011 at 9:18

[GoogleCodeExporter]

I want to use in-app billing as a way to upgrade to the premium version of my 
application without having to maintain 2 Market versions and provide a way for 
my users to upgrade within the app. Because of this, it seems logical to be 
able to periodically check that the app has indeed been purchased by making a 
restore transactions request. Is this going to cause problems as I'm seeing on 
my phone that can no longer make restore transaction requests?

(I mentioned in Issue 14 that I have a development phone I've been calling 
restoreTransactions() on and I get nothing but timeouts now)

Original comment by ashug...@gmail.com on 20 Apr 2011 at 11:50

[GoogleCodeExporter]

I have now run into this quota on both of my development phones and can no 
longer properly test in-app billing in my app. Is there a way to clear/remove 
the quota? Does it automatically reset after a certain amount of time?

Original comment by ashug...@gmail.com on 21 Apr 2011 at 1:54

[GoogleCodeExporter]

Wait a second.

Restoring transactions at this time is the only workaround for issue 14, where 
transaction confirmations get lost.

Enforcing quotas might disable this workaround, leaving the users with no way 
to activate what they paid for (and leaving developers to take the blame for 
bugs in app billing).

Please consider fixing issue 14 before implementing quotas.

Original comment by kmans...@gmail.com on 21 Apr 2011 at 8:51

[GoogleCodeExporter]

Regarding Comment 1: Yes, that may cause problems. You should save the result 
of restoreTransactions() to disk after the first time you call it.

Regarding Comment 2: The quota will automatically reset itself after a short 
while.

Regarding Comment 3: Quotas have been implemented and enforced this whole time. 
We haven't changed anything in that regard. As for issue 14, we're definitely 
working on it.

Original comment by trevorjohns@google.com on 21 Apr 2011 at 7:32

[GoogleCodeExporter]

So, is using in-app billing as a way to upgrade to the premium version of my 
application not a valid use case? Similar to LVL, I want to periodically check 
that the app has been purchased (in case the mechanism I use to store the 
information has been compromised). I don't see any other way to do this besides 
using restoreTransactions(). I doubt I will run into quota issues as it took a 
while for that to happen while testing on my devices (on which I was constantly 
uninstalling and reinstalling my app).

Original comment by ashug...@gmail.com on 22 Apr 2011 at 4:40

[GoogleCodeExporter]

I'm not sure of what the "quota problems" you are talking about exactly are, 
but anyway I agree that the two main ways of ensuring that the user cannot 
crack the app modifying the DB info are restoring the transactions each time 
the user opens the app or tracking the purchases in an external system of your 
own.
Why the first way is not recommended?, it would be really resources and time 
saving for the developer to rely on the Market for the user managed purchases.

Original comment by imanol.m...@gmail.com on 12 May 2011 at 4:33

[GoogleCodeExporter]

The problem is that making a "restore transactions" request is going to pull 
information about every purchase the app ever made.

It could be one purchase. Or it could be thousands. The latter case puts a lot 
of burden on our servers, and is essentially unbounded.

We may consider adding a special "license" item type in the future that's 
compatible with the LVL, so that you can just validate that single item. 
However, validating every purchase ever made (which is what "restore 
transactions" was designed for) is not scaleable.

(That being said: If somebody wanted to, it wouldn't be difficult to implement 
this as an app engine app that's compatible with in-app billing.)

Original comment by trevorjohns@google.com on 16 May 2011 at 11:37

[GoogleCodeExporter]

"We may consider adding a special "license" item type in the future that's 
compatible with the LVL, so that you can just validate that single item."

I know that was posted back in May...but I just came across this now, did the 
license type item ever emerge?  thank you.

Original comment by DJXStr...@gmail.com on 4 Dec 2011 at 5:07

[GoogleCodeExporter]

"We may consider adding a special "license" item type in the future that's 
compatible with the LVL"

If this does happen, then this would solve the problem of taking an old paid 
app and converting it to a free app (with Pro in-app purchase). I guess this is 
the sole intention?

However, for this to work, the "license" item type must only be returned for 
old users who previously paid for the app (to distinguish them from the new 
users who got the app for free).

Original comment by mjc1...@gmail.com on 4 Dec 2011 at 5:47

[GoogleCodeExporter]

This appears to have been fixed in the sample code, so perhaps this should be 
marked as such to prevent wasting time checking that fact?

Original comment by jame...@gmail.com on 10 May 2012 at 11:07

[GoogleCodeExporter]

jamescu: Done. :)

Original comment by trevorjohns@google.com on 16 May 2012 at 12:41

• Changed state: Fixed