Complete list of "gotcha"s?

[Aditya94A]

Can someone who's using this library in production please document here the complete list of "gotcha"s? I see so many issues saying that the library is behaving weirdly, yet it seems to be the only sorta-working library out there when it comes to IAPs.

For example, when exactly is onBillingError() called? Some are saying it's getting called even after a successful purchase. How do I detect that the purchase was successful and not do error handling in that case?

What's going on with onActivityResult()? Some issues say that how it's done in the README is wrong and is leading to more errors.

Do I use the BillingProcessor's constructor or static initializer? If the constructor is buggy (as the README says), why even have it as an option?

Another issue was saying that isSubscribed() is always returning true?! How to deal with that?

As I'm typing this out, I'm feeling less inclined to push my app to production, even though I just integrated this library :/

@serggl Would love some clarification regarding the state of the library. If some parts do not work as expected, it should be clearly stated in the README so that such a critical functionality in our apps doesn't break in production.

[autonomousapps]

I work for Chess.com and we have been using this library in production for over a year, and we run a very successful subscription-based business. I think that a crucial element is that doing in-app billing "right" requires a proper backend that can make use of the Google API to supplement what the app can do on the mobile side. From my perspective, a lot of the complaints are either user error or a misunderstanding of the basic concepts of in-app billing. This library is not a replacement for understanding how IAP works.

All that said, the library could be a bit better about some things. For example, it makes no attempt to take anything off the main thread, and relies on clients to manage concurrency themselves. This is actually probably for the best, but a note on the readme about long-running ops would not be amiss.

To your question about the constructor vs static factory, the constructor is still there because removing it without a deprecation warning would break clients who updated the lib. What should happen, as I see it, is adding the @Deprecation tag to the constructor and then eventually making it private, at which point users should rely on the factory. Or we add a new constructor that doesn't attach to the service.

I don't know what to say about isSubscribed always returning true. I rely on my backend to tell me if a person's subscription is up-to-date. :man_shrugging:

[matzrm]

Hi,

I'm building an app with IAB and I found this answer very useful:

https://stackoverflow.com/questions/47438092/in-app-billing-connect-to-firebase-and-get-products?answertab=active#tab-top

@autonomousapps Are you doing somethings different from this stackoverflow answer?

[autonomousapps]

I don't use Firebase nor do I intend to. Frankly, I hate Google APIs and I think they need hire API designers because right now most of them are utter shit.

[matzrm]

Ok I understand.Putting Firebase aside and speaking about the backend database structure, do you think that the structure proposed in that answer is right? or did you use any other fields to validation?

Did you know how handle purchases made with the same account but different devices? I would like to charge user also if he chooses to buy something already purchased on another device.

[autonomousapps]

IAB lets you get the list of purchases and subs that the Google user owns. Doesn't matter on which devices s/he gets them originally.

[Fahad-pnw]

hi autonomousapps, could you please guide how would you call expirytimemillis via the server, i need to set the status of the user to basic/pro/free on the srv db. now once the subscription has expired, i just want to set the user back at free.

now either i can run a service to check each time the user gets into the app via a call if the subscription is active which would be the worst way to handle this, the other is somehow getting the expiry/renewal date to check if the iap has been renewed, if it is not, set the status to free on the srv db?

using firebase so it should be a closeknit solution? thank you!