Skip to content

Add completion callback to syncPurchases API#1002

Merged
tonidero merged 5 commits into
mainfrom
toniricodiez/sdk-3110-android-add-completion-blocks-to
May 24, 2023
Merged

Add completion callback to syncPurchases API#1002
tonidero merged 5 commits into
mainfrom
toniricodiez/sdk-3110-android-add-completion-blocks-to

Conversation

@tonidero

@tonidero tonidero commented May 15, 2023

Copy link
Copy Markdown
Contributor

Description

This PR adds a new optional parameter to the syncPurchases function containing a success and error callbacks for that operation. Also added a new Kotlin-only version syncPurchasesWith to provide an easier Kotlin API.

Additionally, while doing this, I decided to move the logic from syncPurchases to a new SyncPurchasesHelper, so it can be better tested in isolation.

@tonidero tonidero added the pr:feat A new feature label May 15, 2023

@tonidero tonidero May 15, 2023

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm usually not a big fan of local functions, but I thought it was useful here. Lmk if you have any concerns or suggestions though!

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added this new warning to the documentation so developers consider whether they need to wait for this to continue when using this function.

@tonidero tonidero marked this pull request as ready for review May 15, 2023 11:29
@tonidero tonidero requested a review from a team May 15, 2023 11:29
@codecov

codecov Bot commented May 15, 2023

Copy link
Copy Markdown

Codecov Report

Merging #1002 (e2b00cf) into main (ce99086) will increase coverage by 0.12%.
The diff coverage is 95.38%.

❗ Current head e2b00cf differs from pull request most recent head 518043d. Consider uploading reports for the commit 518043d to get more accurate results

@@            Coverage Diff             @@
##             main    #1002      +/-   ##
==========================================
+ Coverage   85.39%   85.52%   +0.12%     
==========================================
  Files         169      169              
  Lines        6006     6036      +30     
  Branches      841      840       -1     
==========================================
+ Hits         5129     5162      +33     
+ Misses        545      543       -2     
+ Partials      332      331       -1     
Impacted Files Coverage Δ
...om/revenuecat/purchases/strings/PurchaseStrings.kt 0.00% <ø> (ø)
.../main/kotlin/com/revenuecat/purchases/Purchases.kt 83.06% <66.66%> (+0.19%) ⬆️
...in/com/revenuecat/purchases/listenerConversions.kt 42.59% <80.00%> (+3.81%) ⬆️
...tlin/com/revenuecat/purchases/PostReceiptHelper.kt 94.25% <100.00%> (ø)
...otlin/com/revenuecat/purchases/PurchasesFactory.kt 82.78% <100.00%> (+0.58%) ⬆️
...in/com/revenuecat/purchases/SyncPurchasesHelper.kt 100.00% <100.00%> (ø)

... and 9 files with indirect coverage changes

@tonidero tonidero marked this pull request as draft May 16, 2023 09:38

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that this is slightly different than in iOS. In iOS, we would use the response from the post receipt request directly since we only do a single post receipt. In android, since we may be doing multiple requests is a bit more complex... we could use the result from the last post receipt, but there could be edge cases so I decided to just grab it from cache directly after all requests are done.

I also thought about initiating a fetch when there is no cached value to try to avoid failing when we don't have a cached customer info cached yet and there are no purchases... The window for that to happen is small though I think and the use cases for the sync purchases method would make that window even smaller. Also, we don't do that in iOS. So I thought we can go with cache only for now.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That window could exist if calling syncPurchases right after configure? If there are no purchases and no cached info has been retrieved. What's the problem with doing a CacheFetchPolicy CACHED_OR_FETCHED to prevent that from happening.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm rethinking about it, I don't think it would be an issue... It might result in extra fetches when developers use syncPurchases, but it shouldn't be a big issue. Will change that

@tonidero tonidero marked this pull request as ready for review May 16, 2023 10:55
@tonidero tonidero requested a review from vegaro May 16, 2023 10:55

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this appInBackground = false be problematic if someone is calling syncPurchases from the background?

@tonidero tonidero May 24, 2023

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is used to detect whether the cached customer info is stale or not. If it's in the background, it won't be considered stale until it's 25h old. So potentially, this being hardcoded to false can cause an increase in requests to the get customer info endpoint.

So I thought that considering the use cases for syncPurchases, users shouldn't really call it with the app in the background... But I think it's better to be safe than sorry, so I can pass that as a parameter to avoid an increase too big.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes: 518043d

@tonidero tonidero force-pushed the toniricodiez/sdk-3110-android-add-completion-blocks-to branch 2 times, most recently from 74dc4f2 to 014d7e0 Compare May 24, 2023 11:09
@tonidero tonidero force-pushed the toniricodiez/sdk-3110-android-add-completion-blocks-to branch from 014d7e0 to 518043d Compare May 24, 2023 11:14
@tonidero tonidero enabled auto-merge (squash) May 24, 2023 11:15
@tonidero tonidero merged commit c49b532 into main May 24, 2023
@tonidero tonidero deleted the toniricodiez/sdk-3110-android-add-completion-blocks-to branch May 24, 2023 11:31
This was referenced May 24, 2023
tonidero added a commit that referenced this pull request May 25, 2023
**This is an automatic release.**

### New Features
* Support DEFERRED mode (#985) via swehner (@swehner)
* Add completion callback to syncPurchases API (#1002) via Toni Rico
(@tonidero)
### Bugfixes
* Workaround bug in android 4 for JSON objects with List<String> (#942)
via Andy Boedo (@aboedo)
### Dependency Updates
* Bump fastlane-plugin-revenuecat_internal from `fe45299` to `13773d2`
(#1015) via dependabot[bot] (@dependabot[bot])
### Other Changes
* Bump dokka to 1.8.10 to support Gradle 8 (#1009) via Toni Rico
(@tonidero)
* Disable offline entitlements temporarily (#1023) via Toni Rico
(@tonidero)
* Fix integration tests in CI (#1019) via Toni Rico (@tonidero)
* Add offline entitlements integration tests (#1006) via Toni Rico
(@tonidero)
* Disable offline entitlements in observer mode (#1014) via Toni Rico
(@tonidero)
* Extracts setup and teardown to BasePurchasesTest (#1011) via Cesar de
la Vega (@vegaro)
* Support forcing server errors for tests (#1008) via Toni Rico
(@tonidero)

---------

Co-authored-by: revenuecat-ops <ops@revenuecat.com>
Co-authored-by: Toni Rico <antonio.rico.diez@revenuecat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

pr:feat A new feature

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants