Optionally attempt to restore purchases before starting purchase flow #21
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 4 commits
May 15, 2017 16:30
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 a custom View with 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 welcome such change so this logic would get triggered only if TRY_RESTORE_FIRST=true is passed in the extras Bundle for the startPurchase().
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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