Store offerings response in SharedPreferences#1028
Conversation
There was a problem hiding this comment.
This currently lives in the default shared preferences... We probably want to think about having our own shared preferences file though, to avoid devs touching it accidentally.
There was a problem hiding this comment.
Yeah iOS defaults to a custom UserDefaults now.
There was a problem hiding this comment.
Note that we aren't using this yet. Will use it in a followup PR.
There was a problem hiding this comment.
Note that in iOS, we added the response within the Offerings object. I thought about doing that, but due to our module setup, that would require to make it public. Didn't want to do that, so we need to keep them separate.
Codecov Report
@@ Coverage Diff @@
## main #1028 +/- ##
==========================================
+ Coverage 85.50% 85.52% +0.02%
==========================================
Files 173 174 +1
Lines 6091 6087 -4
Branches 855 845 -10
==========================================
- Hits 5208 5206 -2
- Misses 547 548 +1
+ Partials 336 333 -3
|
There was a problem hiding this comment.
Yeah iOS defaults to a custom UserDefaults now.
There was a problem hiding this comment.
I really like this. I'd like to split DeviceCache in iOS as well so it's simply an implementation detail that we use in other cache classes like this one 👍🏻
There was a problem hiding this comment.
This is so much better 👏🏻
There was a problem hiding this comment.
Not for this PR, but with my idea of making DeviceCache agnostic of what it's caching, it would be nice for this to live in OfferingsCache. This is at least a step in the right direction.
There was a problem hiding this comment.
I wish mocking in iOS was this easy :P
076228d to
e767e1c
Compare
### Description Third and final part of persisting offerings in disk to make the system more robust. In this final PR, we use the offerings response cached in #1028 so, in case of a backend error getting offerings, we can calculate the offerings (as long as Play store/Amazon store still give us the product information) as long as we have cached the value before.
**This is an automatic release.** ### New Features * Offline entitlements support (#1030) via Toni Rico (@tonidero) ### Bugfixes * Fix billing connection error when querying purchases early in the process lifetime (#1032) via Toni Rico (@tonidero) ### Performance Improvements * Perform product entitlement mapping request after more critical requests (#1017) via Toni Rico (@tonidero) ### Dependency Updates * Bump fastlane from 2.212.2 to 2.213.0 (#1024) via dependabot[bot] (@dependabot[bot]) ### Other Changes * Get offerings response from disk cache if available (#1029) via Toni Rico (@tonidero) * Improve offline entitlements logs to mention limitations of this mode (#1039) via Toni Rico (@tonidero) * Improve error message when backend returns internal error code (#1038) via Toni Rico (@tonidero) * PurchaseTester: Add new UI to configure internal proxy behavior (#1016) via Toni Rico (@tonidero) * Updated readme to include links to migration guides (#1021) via Marcos Castany (@mcastany) * Store offerings response in SharedPreferences (#1028) via Toni Rico (@tonidero) * Refactor offerings code out of Purchases (#1027) via Toni Rico (@tonidero) --------- Co-authored-by: revenuecat-ops <ops@revenuecat.com> Co-authored-by: Toni Rico <antonio.rico.diez@revenuecat.com>
Description
This is the second PR in preparation of persisting offerings (SDK-3094). In this PR, we persist the backend response for offerings, but we aren't using it yet.
Main changes
OfferingsCacheto abstract the caching logic for offerings and the offerings responseisStalehelpers to extension functions so they can be used in the new offerings cache.