Fix dead buy button when re-presenting a cached paywall after a purchase

[claude]

Requested by Brian Anglin · Slack thread

Changes in this pull request

• Reset per-presentation transient state (the purchase/manual loading spinner and the presentation-prepared flags) at the start of PaywallView.present(), so a cached paywall view always starts a new presentation from a clean slate.

Before / After

Before (2.7.21): buying a consumable (e.g. on buy_credits) and then re-opening the same paywall within the same app session leaves the buy button dead — the tap does nothing and no purchase starts — until the app is killed.

After: the re-presented paywall accepts taps and starts the purchase normally.

Root cause

2.7.21 (PR #431, "Fix background teardown") correctly stopped fully tearing down a paywall when it is merely backgrounded: on a non-finishing onStop the view is kept alive so a backgrounded paywall can resume. That change is correct and this PR does not revert it — the don't-destroy-on-background behavior is preserved.

The side effect: the full (finishing) teardown was also the only place that reset per-presentation transient state — it downgraded a LoadingPurchase/ManualLoading spinner back to Ready and called resetPresentationPreparations() (presentationWillPrepare = true, presentationDidFinishPrepare = false). Buying a consumable launches Google Play's billing sheet as a separate activity, so the paywall activity gets onStop() with isFinishing == false — a non-finishing stop that, since #431, skips teardown. That leaves loadingState == LoadingPurchase and presentationDidFinishPrepare == true.

Paywall views are cached and reused by PaywallManager (the cache-hit path only re-wires the callback and merges the paywall data — it does not reload or reset state). On the next presentation of that cached view the stale state carries over: the stale loading overlay swallows the buy tap, and onViewCreated() early-returns because presentationDidFinishPrepare is still true, skipping the re-wiring (SetPresentedAndFinished, didPresentPaywall, loadingStateDidChange(), flushPendingMessages()).

How

superwall/src/main/java/com/superwall/sdk/paywall/view/PaywallView.kt

• Added resetTransientPresentationState() (next to resetPresentationPreparations()), which downgrades a LoadingPurchase/ManualLoading spinner to Ready (mirroring exactly the conditional the old finishing teardown used at the former destroyed() reset site) and calls resetPresentationPreparations().
• Called it as the first line of present().

Why this location is correct:

• present() runs only for a genuinely new presentation (it is invoked from presentPaywallView → paywallView.present(...), which starts a fresh SuperwallPaywallActivity). It is the single entry point common to both fresh (cache-miss) and cached (cache-hit) views.
• It does not run on resume-same-instance. A backgrounded paywall resumes via the activity lifecycle (SuperwallPaywallActivity.onResume() → paywallView.onViewCreated()), which never calls present(). So this change cannot double-fire presentation events on a resume.
• It does not clear the spinner during an in-flight purchase. The billing sheet stop is what triggers the non-finishing onStop; present() is not called while that transaction is in flight (the paywall is already presented and is guarded against re-presentation), so the mid-purchase spinner is untouched.
• For a fresh view the reset is a no-op (loadingState is Unknown/LoadingURL, and the prepare flags are already at their defaults), so first-present behavior is unchanged.

Deliberately not placed on the !forceCleanup branch of destroyed(): that branch fires during the purchase (billing sheet up), so resetting the spinner there would wipe it mid-purchase and could disturb same-instance resume — exactly the cases this location avoids.

Testing

• Added a focused unit test in PaywallViewTest.kt (resetTransientPresentationState_clearsStalePurchaseSpinnerAndPrepareFlag_soRepresentReWires) that sets up a cached view left in LoadingPurchase with presentationDidFinishPrepare == true (the post-Fix background teardown #431 stale state), invokes the reset, and asserts the spinner is back to Ready and the prepare flags are re-armed so onViewCreated() will re-wire instead of early-returning. The existing onViewCreated_afterBackgroundStop_tracksPaywallOpenAgain and destroyed_onNonFinishingBackgroundStop_... tests continue to cover the preserved Fix background teardown #431 backgrounding behavior.
• Not compiled locally: this environment has no Android SDK and no dependency cache, so a Gradle build cannot run here. CI / a reviewer should confirm :superwall compiles and the unit tests pass. A device repro would be: buy a consumable on buy_credits, dismiss, then re-trigger buy_credits in the same session and confirm the buy button starts the purchase (a transaction_start fires).

Reviewer note

Ian Rumac (author of #431) — please confirm the backgrounding behavior from #431 is fully preserved; this PR only relocates the transient-state reset to the next presentation and does not change when the view is torn down.

Checklist

• All unit tests pass. (added test; CI to verify — not compiled locally, no Android SDK here)
• All UI tests pass.
• Demo project builds and runs.
• I added/updated tests or detailed why my change isn't tested.
• I added an entry to the CHANGELOG.md for any breaking changes, enhancements, or bug fixes.
• I have run ktlint in the main directory and fixed any issues.
• I have updated the SDK documentation as well as the online docs.
• I have reviewed the contributing guide

---

Generated by Claude Code