Proper PaywallsBehaviour

[vegaro]

We realized the current version wasn't correct since the functions are not available from the Editor. Meaning that if you try to link a Button's onClick event to PresentPaywall, it's not possible because of the parameters, and becuase it doesn't return void.

This PR adds proper configuration options and refactors the functions so they can be worked directly from the Editor.

Here's an example of the component with a handler for the result events attached to it:

And then a Button can be configured to present the paywall:

[vegaro]

These UnityEvents can accept generics, but won't work with a custom class like PaywallResult, so I decided to split it into multiple events, that way they can be set in the editor. The alternative is to use a primitive type (string), but I think that limits us more if we ever want to send something in the events:

[Serializable]
public class StringEvent : UnityEvent<string> { }

[Header("Events")]
public StringEvent OnPaywallResult = new StringEvent();

private void HandleResult(PaywallResult result)
{
    OnPaywallResult?.Invoke(result.Result.ToString());
}

[vegaro]

If we ever need to send something like UnityEvent<CustomerInfo>, it's still possible but devs need to hook to it via code (it doesn't show up in the Editor's dropdown):

[Serializable]
public class CustomerInfoEvent : UnityEvent<CustomerInfo> { }

[Header("Events")]
public CustomerInfoEvent OnCustomerInfoUpdated = new CustomerInfoEvent();

using UnityEngine;

public class CustomerInfoHandler : MonoBehaviour
{
    [SerializeField] private Purchases purchases;

    void Start()
    {
        // Subscribe to the event
        purchases.OnCustomerInfoUpdated.AddListener(HandleCustomerInfo);
    }

    void OnDestroy()
    {
        // Unsubscribe
        purchases.OnCustomerInfoUpdated.RemoveListener(HandleCustomerInfo);
    }

    private void HandleCustomerInfo(Purchases.CustomerInfo customerInfo)
    {
        Debug.Log($"Customer info updated: {customerInfo.ActiveSubscriptions.Count} active subscriptions");
        
        foreach (var entitlement in customerInfo.Entitlements.Active)
        {
            Debug.Log($"Active entitlement: {entitlement.Key}");
        }
    }
}

Or we could remove the parameter and inform developers to fetch the CustomerInfo themselves which I believe is the Unity standard since it works in the Editor:

[Header("Events")]
[Tooltip("Invoked when customer info is updated. Use GetCustomerInfo() to fetch the latest data.")]
public UnityEvent OnCustomerInfoUpdated = new UnityEvent();

private void NotifyCustomerInfoUpdate()
{
    OnCustomerInfoUpdated?.Invoke();
}

[tonidero]

Just a couple comments, but looking great!! Excited to get this out!

[tonidero]

LGTM as far as I can tell 🙌

[vegaro]

@tonidero @facumenzella
I am a bit doubtful about my last commit that adapts PaywallOptions to the changes from #710

In the last commit I added a purchases.GetOfferings call to get the Offering via the identifier. But I am not completely convinced because of the async calls and because it feels useless having to do that if we are actually converting it to offering identifier later on.

The alternative is to add an internal constructor to PaywallOptions and do this:

        internal string OfferingIdentifier => _offeringIdentifier ?? Offering?.Identifier;

The problem that has is that _offeringIdentifier will be not null, and Offering null, which is kinda inconsistent and could be weird.

What do you think?

[facumenzella]

I am thinking that if we add async methods to the MonoBehaviour, we need to expose a OnPaywallPresentedChanged or something like that to allow hooking to state changes right?
I am thinking about loading states for example

nothing 🙃

[vegaro]

Actually, I was looking at Android's implementation and there's a sealed class OfferingSelection to solve the offeringIdentifier vs offering problem in PaywallOptions. I will have a go at that, because I think that's the correct solution

[vegaro]

ok finally! I think the last commit is what I like the most 2c0e358 (#706) @facumenzella @tonidero

[tonidero]

This looks good!