Paywalls: Add support to launch paywall as activity

[tonidero]

Description

Adds a PaywallActivityLauncher class that devs can instantiate in their activity/fragment onCreate in order to launch the PaywallActivity which is a wrapper around the full screen PaywallView. Then, they receive the result in a PaywallResultHandler interface.

Once they want to launch the activity, they can call the launch method in that PaywallActivityLauncher.

[tonidero]

I've been thinking about splitting all this into a different module, so we don't clutter the ui:revenuecat dependency for people not using activities/fragments. The idea would be to have a different dependency for people using activities fragments with all these codes and dependencies.

The down side is to further split into more modules, and we might need to expose some things like the setOfferingId in the PaywallViewOptions... But I think it might be ok?

[vegaro]

I would keep it in the same module, so we don't end up with many modules again. But it's true androidx.activity:activity-compose is 1.1 MB, which is not small compared to the 300 KB the billing client takes

[NachoSoto]

Is 1MB much these days? 😅

[tonidero]

Well, usually it's much less than that for devs minifying their apps. It's true that we're using a ton of dependencies in the revenuecatui module, so I wasn't sure about trying to optimize it a bit... But yeah, we can keep it in one module for now and avoid having a ton of modules 👍

[tonidero]

This was added by the wizard when I created the activity. Need to test whether it's actually needed

[tonidero]

Same, added by the wizard. This shouldn't really hurt at all.

[codecov]

Codecov Report

All modified lines are covered by tests ✅

Comparison is base (0cb8c8e) 85.06% compared to head (5968c44) 85.06%.

❗ Current head 5968c44 differs from pull request most recent head 6826ef7. Consider uploading reports for the commit 6826ef7 to get more accurate results

Additional details and impacted files

@@            Coverage Diff            @@
##           paywalls    #1317   +/-   ##
=========================================
  Coverage     85.06%   85.06%           
=========================================
  Files           193      193           
  Lines          6475     6475           
  Branches        942      942           
=========================================
  Hits           5508     5508           
  Misses          600      600           
  Partials        367      367           

Files	Coverage Δ
...src/main/kotlin/com/revenuecat/purchases/errors.kt	100.00% <100.00%> (ø)

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

[vegaro]

I would keep it in the same module, so we don't end up with many modules again. But it's true androidx.activity:activity-compose is 1.1 MB, which is not small compared to the 300 KB the billing client takes

[vegaro]

What if we make PaywallResultHandler a lambda like this:

typealias PaywallResultHandler = (PaywallResult) -> Unit

Then in the constructor of the launcher, we can handle the ActivityResultCallback there directly:

    constructor(activity: ComponentActivity, resultHandler: PaywallResultHandler) {
        activityResultLauncher = activity.registerForActivityResult(PaywallContract()) { paywallResult ->
            resultHandler(it)
        }
    }

Then, the activity can be started like this:

paywallActivityLauncher = PaywallActivityLauncher(this) { result ->
    Log.e("PaywallsTester", "LAUNCH PAYWALL RESULT: $result")
}

This way, folks don't have to make their Activity conform to PaywallResultHandler (ActivityResultCallback) and override onActivityResult.

[tonidero]

I thought about that... My reasoning to go this way is in case we ever want to add another callback or anything, this would be more extensible even though slightly harder to use... Maybe it's ok though. We can discuss that

[vegaro]

For adding another callback, we could have it as:

    constructor(activity: ComponentActivity, resultHandler: PaywallResultHandler, anotherCallback: NewCallback) {

And then we could do ourselves the complicated part, which is figuring out which callback to call using the activity result code. Otherwise devs would have to handle that

[tonidero]

Well, that's not as extensible IMO... Another point to consider is that this PaywallActivityLauncher needs to be created during the onCreate, it can't be created after (it will fail at runtime if you try). In that case, you would have a callback at the activity level, not inside a method, so you still need to reference some other class there. I think for a class variable, an interface is a more common pattern... What do you think?

[vegaro]

Makes sense. Using the interface is actually more flexible + it's using a "system" interface, that devs will probably be familiar with. Let's do the interface

[NachoSoto]

How come this is needed if we already have Offering?

[tonidero]

We can't pass an Offering object to the new activity since it's not serializable. As a fallback, in order to display a specific offering in the activity, we allow to pass an offering id and load the offering again from the paywall view itself.

I'm not exposing that API publicly right now, so devs still need to pass the full Offering object normally, this would only be used for activities

[NachoSoto]

This is a weird definition of the options then.
What do you think about turning this into an enum:

sealed class Selection {
    data class Offering(val offering: Offering) : Selection()
    data class OfferingIdentifier(val id: String) : Selection()
    object None : Selection()
}

[tonidero]

Hmm well, I'm currently not exposing the option to pass the identifier to the paywallView publicly. I guess we could hold that type internally to decide what to do though, since they are indeed exclusive. Will do that!

[NachoSoto]

Is this usable from Java too?

[tonidero]

It's usable yes, though you don't really have a nice switch as you do in Kotlin, you basically have to check the type and perform the downcast to the corresponding type. It's really a much nicer API in Kotlin, but still usable in Java.

[NachoSoto]

👍🏻

[tonidero]

Will merge this, if there are any further comments I can address separately