lukaspili / Reactive-Billing

Lightweight reactive wrapper around In App Billing API v3 for Android
https://play.google.com/store/apps/details?id=com.github.lukaspili.reactivebilling.sample
MIT License
246 stars 33 forks source link

Optionally attempt to restore purchases before starting purchase flow #21

Open mck182 opened 7 years ago

mck182 commented 7 years ago

This adds the ability to first attempt to restore the purchase for the given product and only if it wasn't purchased before, start the purchase flow.

The rationale for this solution is that both flows (restore and purchase) will have the exact same exit point - the Subscription to purchaseFlow(), which is not necessarily at the same place as the restore/purchase start logic and saves one extra codepath.

For example, consider a Fragment with custom View that has a 'Buy' button, a RecyclerView and an Adapter. The Fragment would hold the Subscription to the purchaseFlow(), which triggers UI changes in the Adapter, and the 'Buy' button would have a click listener which triggers the startPurchase().

Now if we want the 'Buy' button to do the restore first and only if there's nothing to restore start the purchase, we'd need two different paths on how to reach the Adapter - one is through the purchaseFlow() Subscription, the second one would need to be some sort of callback from the custom View back to the Fragment.

So combining these two different steps/paths into one with one single return point makes things much easier.

Of course not everyone would want such logic so this would get triggered only if TRY_RESTORE_FIRST=true is passed in the extras Bundle for the startPurchase().

Cheers, Martin from 500px