[Customer Center] Create a completion handler

[vegaro]

Checklist

• If applicable, unit tests
• If applicable, create follow-up issues for purchases-android and hybrids

Motivation

Description

[vegaro]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• [Customer Center] Create a completion handler #4028 👈
• [Customer Center] Add contact support button #4023
• [Customer Center] Add colors support #3983
• [Customer Center] Promotional Offers support #3968
• [Customer Center] Initial implementation #3967 : 3 other dependent PRs (#3919 , #3933 , #3959 )
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @vegaro and the rest of your teammates on Graphite

[RevenueCat-Danger-Bot]

	1 Error
🚫	Label the PR using one of the change type labels

Label	Description
breaking	Changes that are breaking
build	Changes that affect the build system
ci	Changes to our CI configuration files and scripts
docs	Documentation only changes
feat	A new feature
fix	A bug fix
perf	A code change that improves performance
RevenueCatUI	A change to the RevenueCatUI library
refactor	A code change that neither fixes a bug nor adds a feature
style	Changes that don't affect the meaning of the code (white-space, formatting, missing semi-colons, etc
test	Adding missing tests or correcting existing tests
next_release	Preparing a new release
dependencies	Updating a dependency
phc_dependencies	Updating purchases-hybrid-common dependency

Generated by 🚫 Danger

[tonidero]

I've been wondering whether it would make more sense to call this CustomerCenterActionHandler. Then, we would notify whenever an action is performed.

My main concern with this approach is that it moves away from what we have in paywalls, where we have individual callbacks for many actions like purchase/restore started/failed/completed... But I feel since there are going to be more actions here, it makes more sense to do something like that. Wdyt?

[vegaro]

That's a good point... Right, I think at some point we will have actions that are no completion actions like feedbackSurveyStarted so we want this to be an action handler. I honestly prefer just having this handler with a bunch of different events that can be handled in a switch statement than a lot of functions like we do in paywalls

It is true that adding a new event to a sealed class is technically a breaking change, but I think it's assumable. It is also true that it's not possible to modify an existing case in an enum (and add more properties) without creating a new event, but that's also an issue with independent functions.

In summary I find it cleaner to use sealed class when we are going to have a lot of potential events.

[tonidero]

If we follow my previous suggestion, I would move away from using the Result naming, since this may happen at any point, and even multiple times. I would only keep this naming if we want to return a single result after the customer center closes, but I think I prefer my suggested option. Lmk what you think!

[tonidero]

Would it be possible to move this inside the view model? That way we centralize the logic there.

[tonidero]

Ideally this calls the view model, which internally calls whatever it needs I think.