Add BTShopperInsights public API shell
#1142
Conversation
scannillo
force-pushed
the
payment-insights-shell
branch
from
59c03fc to
fb09a79
Compare
scannillo
changed the title
BTPaymentInsights public API shellBTShopperInsights public API shell
scannillo
force-pushed
the
payment-insights-shell
branch
from
2fa7c1e to
bf2efbd
Compare
… proper param types
… note that beta API could be removed
| /// Use `BTShopperInsightsClient` to optimize your checkout experience by prioritizing the customer’s preferred payment methods in your UI. | ||
| /// By customizing each customer’s checkout experience, you can improve conversion, increase sales/repeat buys and boost user retention/loyalty. | ||
| /// - Note: This feature is in beta. It's public API may change or be removed in future releases. | ||
| @objcMembers class BTShopperInsightsClient: NSObject { |
There was a problem hiding this comment.
Just curious about new modules supporting objective-c - is this required by project setup still or could we move to only swift classes?
There was a problem hiding this comment.
Actually I see now that this feature lives in core - what is the reason for not having a separate module for this?
There was a problem hiding this comment.
These are great questions - I honestly am very down to not add Objective-C support to this feature. We could always add it later if we see demand for it. Also worth noting - this feature will go out as an "alpha" so we have the room to iterate on it, break the API, etc.
Done in 0884b78. Will loop @jaxdesmarais in on this one though to confirm.
There was a problem hiding this comment.
Actually I see now that this feature lives in core - what is the reason for not having a separate module for this?
We could make this a separate module. I was approaching this from a path of least resistance approach for now as we target "alpha". We might save us the headache from creating and documenting an entire new module, if the feature doesn't get adopted. And should be relatively simple to move the files into a module if we do want to go that route later on. Open to folks thoughts, though!
There was a problem hiding this comment.
Done in 0884b78. Will loop @jaxdesmarais in on this one though to confirm.
I am totally down for this! Should we take the same approach with the Messaging module (Swift only/init first/etc)?
There was a problem hiding this comment.
Should we also drop the BT prefix? Or do we want to leave that consistent until v7?
There was a problem hiding this comment.
Another great question - maybe let's leave the prefix until we're ready to do that overhaul holistically?
There was a problem hiding this comment.
That makes sense to me! I agree it could be confusing to have some things prefixed and some not so the consistency would be great then we can say goodbye to it in v7. 🚀
UnitTests/BraintreeCoreTests/BTShopperInsightsClient_Tests.swift
Outdated
Show resolved
Hide resolved
scannillo
force-pushed
the
payment-insights-shell
branch
from
0884b78 to
4121489
Compare
Co-authored-by: Sarah Koop <[email protected]>
|
UI test failures are un-related & failing flakily on main |
JIRA DTBTSDK-3173
Summary of changes
BTShopperInsightsClientBTShopperInsightsResultBTShopperInsightsClient_TestsNote
This feature is basically a V2/re-do of PreferredPaymentMethods (see removal PR). Though this feature will leverage a different underlying API to perform the eligibility checks.
Checklist
Added a changelog entryAuthors
@scannillo @MaxHastingsPP @saperi22