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().
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