Add APIs for hybrid SDKs to set presentedOfferingContext by tonidero · Pull Request #2610 · RevenueCat/purchases-android

tonidero · 2025-08-18T14:59:41Z

Description

This adds some new internal APIs to be used by our hybrid SDKs that allow to pass a PresentedOfferingContext when launching paywalls and passing a specific offering.

Actually use presented offering context data

codecov · 2025-08-19T06:32:09Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.38%. Comparing base (cec4b38) to head (2d6fbb4).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2610   +/-   ##
=======================================
  Coverage   78.38%   78.38%           
=======================================
  Files         301      301           
  Lines       11229    11229           
  Branches     1561     1561           
=======================================
  Hits         8802     8802           
  Misses       1741     1741           
  Partials      686      686

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

JayShortway

Thanks for taking care of this! Just a question on whether we need to introduce the new "OfferingInfo" concept for this.

JayShortway · 2025-08-19T08:30:28Z


    @Immutable
-    data class OfferingId(val offeringId: String) : OfferingSelection()
+    data class OfferingInfo(val offeringInfo: OfferingPresentationInfo) : OfferingSelection()


Do we need a new class (OfferingPresentationInfo) here? Can we not add the PresentedOfferingContext parameter to OfferingId? Like so:

data class OfferingId( val offeringId: String, val presentedOfferingContext: PresentedOfferingContext?, ) : OfferingSelection()

Reasoning also being that it's not super clear (at first glance) how setOfferingInfo() is different from setOffering(). That could also remain setOfferingId() in this case:

internal fun setOfferingId( offeringId: String?, presentedOfferingContext: PresentedOfferingContext?, )

Yeah... we could add it as a new parameter, the main reason I joined them into a new class was because both types of data should move together through all the plumbing, and creating a new entity ensured that better than separating into different parameters and moving both around. That could lead to easily forgetting passing/setting one of them IMO. It's true it's a bit confusing with the other setOffering APIs though... not sure if we could come up with a better naming...

What about IdAndPresentedOfferingContext? 😅 (It's already namespaced to OfferingSelection, so maybe we can get away with omitting "Offering" in the name.)

Hmm it's a bit of a longer name... certainly more explicit, but not sure if we win much that much clarity TBH... But I guess it could improve on the readability for the setOfferingId method... So will do the rename.

JayShortway · 2025-08-19T08:34:45Z

     * Default is true for Android 15+, false otherwise.
     */
+    @Deprecated(
+        message = "Use launch with presented offering context instead",


Is the PresentedOfferingContext always available? Should we default to null?

For an offering, it should always be available yes. I had to make it nullable for backwards compatibility reasons, but otherwise, it would be good to assume that it should always be there.

Hmm, but what is the purpose of the "offering ID" API, if devs will always need to have a full Offering (because they now need the PresentedOfferingContext)? That makes the "offering ID" API obsolete no, or am I misunderstanding something?

The main reason is that it's tricky to create a full Offering native object from the hybrids, since it has a lot of data and even some non-parcelable objects like the Store's product entities. So we can't easily recreate the offerings from the data in the hybrids, that's the reason we were only passing the offering id.

This PR adds the data we were missing for proper traceability purposes. Otherwise, any placement/targeting data would be lost.

Right got it, but this is a public API too. Before this PR, it had its utility. You could launch a paywall with just an Offering ID, without having to get Offerings first. But now the utility of this public API is gone, as devs will need to get Offerings to be able to pass a PresentedOfferingContext.

I was gonna suggest:

we deprecate launch(offeringIdentifier: String) in favor of launch(offering: Offering) instead, and

we make launch(offeringIdentifier: String, presentedOfferingContext: PresentedOfferingContext) an @InternalRevenueCatAPI.

But I see you already did 2 😄 So in that case I think we should still do 1, as the current deprecation message encourages the use of an internal API.

Right... our docs did say not to use this method, but yeah, we probably should have made it internal from the beginning... In any case, I do agre that the ReplaceWith should point to the method taking an offering instead of the internal API. Good catch!

tonidero · 2025-08-19T10:46:23Z

In this PR I wasn't using the newly provided presented offering context yet. So I added that in a separate PR: #2612

JayShortway

Looks good! Just the OriginalTemplatePaywallFooterView deprecation message mostly.

JayShortway · 2025-08-20T07:23:37Z

-            this.offeringSelection = offeringId?.let { OfferingSelection.OfferingId(it) }
-                ?: OfferingSelection.None
+        internal fun setOfferingIdAndPresentedOfferingContext(
+            offeringInfo: OfferingSelection.IdAndPresentedOfferingContext?,


nit:

Suggested change

offeringInfo: OfferingSelection.IdAndPresentedOfferingContext?,

idAndPresentedOfferingContext: OfferingSelection.IdAndPresentedOfferingContext?,

JayShortway · 2025-08-20T07:27:16Z

+    @Deprecated(
+        "Use setOfferingInfo instead.",
+        ReplaceWith(
+            "setOfferingInfo(offeringId, presentedOfferingContext)",
+        ),
+    )


setOfferingInfo does not exist anymore, and setOfferingIdAndPresentedOfferingContext is internal. Should we add a setOffering function here? If not, we should remove the ReplaceWith from the deprecation message.

JayShortway · 2025-08-20T07:30:45Z

+                // WIP: We do not support presentedOfferingContext when using the view in XML layouts.
+                presentedOfferingContext = null,


Not for this PR, just thinking out loud: what if we support passing a placement in XML layouts?

Yeah we could... TBH, I'm not sure how many people are using paywalls through XMLs... but it's certainly something we could add if needed.

JayShortway · 2025-08-20T07:31:19Z

+    @JvmOverloads
+    fun setOfferingId(offeringId: String?, presentedOfferingContext: PresentedOfferingContext? = null) {


Do we need a setOffering(Offering) too?

I believe we needed this for RN if I remember correctly, that required us to set the offering AFTER actually creating the paywall, which was pretty convoluted. We didn't need the setOffering API until now, and in general, I think it's better to just pass it in the constructor.

### Description Based on #2610 This actually makes use of the presented offering context to pass a modified offering to the paywall. This data will be sent as part of the post receipt when a purchase is made.

@tonidero

**This is an automatic release.** ## RevenueCat SDK ### 🐞 Bugfixes * Use `Block store` to backup anonymous user ids across installations (#2595) via Toni Rico (@tonidero) ## RevenueCatUI SDK ### Paywallv2 #### 🐞 Bugfixes * Fixes price formatting discrepancies on Paywalls for `{{ product.price_per_[day|week|month|year] }}` (#2604) via JayShortway (@JayShortway) ### 🔄 Other Changes * Revert dokka 2 and gradle 9 update (#2618) via Toni Rico (@tonidero) * Introduce runtime annotations library and add stability annotations for increasing UI performances (#2608) via Jaewoong Eum (@skydoves) * Override presented offering context paywalls without offering (#2612) via Toni Rico (@tonidero) * Add APIs for hybrid SDKs to set presentedOfferingContext (#2610) via Toni Rico (@tonidero) * Bump Baseline Profiles to 1.4.0 and update profiles (#2611) via Jaewoong Eum (@skydoves) * Migrate deprecated kotlinOptions to compilerOptions (#2607) via Jaewoong Eum (@skydoves) * [AUTOMATIC][Paywalls V2] Updates paywall-preview-resources submodule (#2613) via RevenueCat Git Bot (@RCGitBot) * Migrate amazon & debugview modules to KTS (#2327) via Jaewoong Eum (@skydoves) * Update to Dokka 2.0.0 (#2609) via Toni Rico (@tonidero) * Add log when restoring purchases finds no purchases with some troubleshooting (#2599) via Toni Rico (@tonidero) Co-authored-by: revenuecat-ops <ops@revenuecat.com>

This adds some new internal APIs to be used by our hybrid SDKs that allow to pass a `PresentedOfferingContext` when launching paywalls and passing a specific offering. - [ ] Actually use presented offering context data

Based on #2610 This actually makes use of the presented offering context to pass a modified offering to the paywall. This data will be sent as part of the post receipt when a purchase is made.

…nting paywalls (#1246) Adds the `presentedOfferingContext` parameter implemented in the native SDKs (for context, [iOS](RevenueCat/purchases-ios#5491) and [Android](RevenueCat/purchases-android#2610) PRs) Also deprecated the old APIs and added the new APIs to the API test.

### Description Follow-up to #2610. We had a non-null offeringIdentifier parameter, which doesn't allow us to reset the offering selection to none. This would be very uncommon, but we should still support it.

…nting paywalls (#1246) Adds the `presentedOfferingContext` parameter implemented in the native SDKs (for context, [iOS](RevenueCat/purchases-ios#5491) and [Android](RevenueCat/purchases-android#2610) PRs) Also deprecated the old APIs and added the new APIs to the API test. # Conflicts: # ios/PurchasesHybridCommon/PurchasesHybridCommonUI/Paywalls/PaywallProxy.swift

…nting paywalls (#1246) Adds the `presentedOfferingContext` parameter implemented in the native SDKs (for context, [iOS](RevenueCat/purchases-ios#5491) and [Android](RevenueCat/purchases-android#2610) PRs) Also deprecated the old APIs and added the new APIs to the API test.

Add APIs for hybrid SDKs to set presentedOfferingContext

fdb67d9

tonidero added pr:other pr:force_patch Forces a patch release labels Aug 18, 2025

tonidero and others added 3 commits August 19, 2025 07:52

Fix

2423741

Merge branch 'main' into add-hybrid-apis-set-presented-offering-context

cf1e795

Fix metalava

5db56df

tonidero marked this pull request as ready for review August 19, 2025 06:16

tonidero requested review from a team August 19, 2025 06:16

JayShortway reviewed Aug 19, 2025

View reviewed changes

tonidero mentioned this pull request Aug 19, 2025

Override presented offering context paywalls without offering #2612

Merged

tonidero added 2 commits August 19, 2025 15:53

Some refactors from review

9710ec3

Update metalava

7fac16d

tonidero requested a review from JayShortway August 19, 2025 15:07

JayShortway approved these changes Aug 20, 2025

View reviewed changes

tonidero and others added 2 commits August 20, 2025 09:41

Cleanup from review

babb236

Merge branch 'main' into add-hybrid-apis-set-presented-offering-context

2d6fbb4

tonidero enabled auto-merge August 20, 2025 07:41

tonidero added this pull request to the merge queue Aug 20, 2025

Merged via the queue into main with commit 0c1aaa4 Aug 20, 2025
20 checks passed

tonidero deleted the add-hybrid-apis-set-presented-offering-context branch August 20, 2025 08:15

This was referenced Aug 20, 2025

[AUTOMATIC] Release/9.3.1 #2616

Closed

[AUTOMATIC] Release/9.3.1 #2619

Merged

rickvdl mentioned this pull request Aug 21, 2025

Added APIs for hybrid SDKs to set presentedOfferingContext RevenueCat/purchases-ios#5491

Merged

2 tasks

tonidero mentioned this pull request Aug 25, 2025

Release/8.23.0 #2631

Closed

rickvdl mentioned this pull request Aug 26, 2025

Added presentedOfferingContext parameter to the hybrid APIs for presenting paywalls RevenueCat/purchases-hybrid-common#1246

Merged

tonidero mentioned this pull request Sep 4, 2025

Support setting null offering id on PaywallView #2658

Merged

	offeringInfo: OfferingSelection.IdAndPresentedOfferingContext?,
	idAndPresentedOfferingContext: OfferingSelection.IdAndPresentedOfferingContext?,

		// WIP: We do not support presentedOfferingContext when using the view in XML layouts.
		presentedOfferingContext = null,

		@JvmOverloads
		fun setOfferingId(offeringId: String?, presentedOfferingContext: PresentedOfferingContext? = null) {

Uh oh!

Conversation

tonidero commented Aug 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Uh oh!

codecov Bot commented Aug 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

JayShortway left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tonidero commented Aug 19, 2025

Uh oh!

JayShortway left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

tonidero commented Aug 18, 2025 •

edited

Loading

codecov Bot commented Aug 19, 2025 •

edited

Loading