Add Shopping Insights Demo App Integration

[MaxHastingsPP]

Summary of changes

• Created Shopping Insights Fragment
• Created Shopping Insights View Model
• Created Shopping Insights UI
• Added Kotlin language support to demo app module
• Added navigation to shopping insight fragment from main fragment

Images

Checklist

Authors

• @MaxHastingsPP

[scannillo]

I think this is minor, but just posting that we could align our iOS & Android demos more.

I like the idea of the email & phone text field, we can add that on iOS at some point and will probably need it for testing various API scenarios/error cases. I included a screenshot below of iOS, where we have buttons that will launch the Venmo & PayPal flow, which we can consider either adding to Android or removing from iOS. This was just a re-use of what already existed for PreferredPaymentMethods.

---

[MaxHastingsPP]

I think this is minor, but just posting that we could align our iOS & Android demos more.

I like the idea of the email & phone text field, we can add that on iOS at some point and will probably need it for testing various API scenarios/error cases. I included a screenshot below of iOS, where we have buttons that will launch the Venmo & PayPal flow, which we can consider either adding to Android or removing from iOS. This was just a re-use of what already existed for PreferredPaymentMethods.

Yeah I agree that we should have our iOS and Android demo apps similar. From what I see on iOS I think it might make our dev app a bit more flexible if we just print out the JSON response we get back from server rather than trying to parse it ourselves. So that any changes with server side responses would not require us to update our demo app. And would make it a bit easier to see what is exactly returned for edge cases / unhappy paths.

Also I am curious what is being used as input for email, phone number? I don't see it from the screenshot you shared.

[scannillo]

Also I am curious what is being used as input for email, phone number? I don't see it from the screenshot you shared.

It's currently just being hard-coded (here)

[saperi22]

Any UI changes will be handled in subsequent PRs.

[jaxdesmarais]

Hey @saperi22 our general rule is 2 approvals before merging any PR in, it doesn't look like this PR has been approved by anyone on the team yet.

[saperi22]

@jaxdesmarais @scannillo had given her approval in a private DM.
As the PR is going into a feature branch, I merged it in. We'll get another opportunity to renew when this goes into the main branch.

[jaxdesmarais]

@saperi22 if that's the case in the future please post those messages in the PR so other folks know. It'd still require 1 more approval in any case.

Regarding the feature branch being merged into main, we don't typically review those PRs at all on the BT/PPCP teams. All PRs merged into the feature branch should have 2 approvals already. This allows us to, once work is complete, merge feature branches in without additional approvals as all work has already been approved.

The main reason we open those PRs is so that we can ensure CI is still green. This PR is a great example of that process: braintree/braintree_ios#1040. It also allows us to review work in smaller digestible chunks vs the entire context of the feature where it is easier to miss things in a larger feature to main PR.

[scannillo]

@jaxdesmarais @scannillo had given her approval in a private DM.

Ah, I think I meant that this approach looks good. But no worries! We're all still getting on the same page for our dev practices.

We have this highlighted in our BT GHE sdk-knowledge repo, under dev-practices.md#commits--pull-requests, but I know the new folks just got access to that repo. Next week, I will add the 2 review restriction to our repos at the PR level (DTBTSDK-3324).