Add the E2E control link parser to all four sample apps - #554
Conversation
1abe472 to
71f2515
Compare
fd87aa1 to
278ce30
Compare
71f2515 to
fc857ab
Compare
278ce30 to
66ee89d
Compare
66ee89d to
7c28f96
Compare
fc857ab to
b40215e
Compare
9c0c058 to
babcf9e
Compare
ad8bafd to
992ffc8
Compare
babcf9e to
2c394fc
Compare
992ffc8 to
489127e
Compare
2c394fc to
1bbb44a
Compare
1bbb44a to
9a982e4
Compare
489127e to
07dac43
Compare
9a982e4 to
e650dc3
Compare
2b8fadd to
5b7d18d
Compare
e650dc3 to
ae68cf6
Compare
ae68cf6 to
a3846f6
Compare
a3846f6 to
38169bc
Compare
Package Size
React Native file breakdown
Android file breakdown
Measured from the PR base SHA and PR head SHA. The file breakdown shows uncompressed sizes within each package artifact, so individual files do not sum to the compressed artifact total. This comment reports package artifact sizes only; it is not a final app binary-size report. |
Install this buildOpen Tophat, select your target device, then click Install. Links open on the Mac running Tophat.
Checkout Kit E2E results
|
The E2E suite drives four apps: Swift iOS, Kotlin Android, React Native iOS and React Native Android. Only React Native could read a deep link, and only for a cart. Widen the contract to <scheme>://e2e/<command> with the commands reset, cart and signIn, and port the parser to Swift and Kotlin so one Maestro flow drives every app. Every platform rewrites the scheme to https before parsing. Neither Foundation URLComponents nor java.net.URI accepts the underscores in the Android application id, and the React Native URL polyfill parses a host only for http(s). A test per platform pins that behaviour with both app schemes. The parser stays pure and keeps three outcomes: nil when the link belongs to another feature, a parsed command, or an error that names the bad parameter. A parameter that is present must carry a valid value. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
kyle-schellen
left a comment
There was a problem hiding this comment.
Just left a small non-blocking question
| val uri = try { | ||
| URI(PARSE_ORIGIN_SCHEME + authorityAndPath) | ||
| } catch (error: URISyntaxException) { | ||
| return null |
There was a problem hiding this comment.
Should we reserve null for non-E2E links and throw for malformed E2E URLs instead? Might be stricter than we need today, but it would keep those cases distinct if we need clearer control-link diagnostics later.
If we do want that distinction, it’s probably worth keeping the Android, Swift, and React Native parsers aligned.
There was a problem hiding this comment.
I think I'll leave it to later if the time comes we need that
38169bc to
e746744
Compare
### What changes are you making? Previous PR added classes to handle parsing deep links for e2e scenarios This one adds a controller for E2E that utilises the parser to receive the intent, and then dispatch the actions we need in the sample after React Native already had most of the wiring as we set them up first so this PR brings kotlin and swift up to speed on wiring in the entry points for deep links into the E2EControlLink classes from PR #554 ### How to test These things aren't wired up yet so nothing really to test, just dividing up the work --- ### Before you merge > [!IMPORTANT] > > - [ ] I've added tests to support my implementation > - [ ] I have read and agree with the [Contribution Guidelines](./CONTRIBUTING.md) > - [ ] I have read and agree with the [Code of Conduct](./CODE_OF_CONDUCT.md) > - [ ] I've updated the relevant platform README (`platforms/swift/README.md` and/or `platforms/android/README.md`) --- <details> <summary>Releasing a new Swift version?</summary> - [ ] I have bumped the version in `ShopifyCheckoutKit.podspec` - [ ] I have bumped the version in `platforms/swift/Sources/ShopifyCheckoutKit/ShopifyCheckoutKit.swift` - [ ] I have updated the SwiftPM/CocoaPods version snippets in `platforms/swift/README.md` (major version only) </details> <details> <summary>Releasing a new Embedded Checkout Protocol version?</summary> - [ ] I have bumped `embeddedCheckoutProtocolAndroid` in `platforms/android/gradle/libs.versions.toml` - [ ] I have updated `protocol/languages/kotlin/embedded-checkout-protocol/api/embedded-checkout-protocol.api` if the public API changed </details> <details> <summary>Releasing a new Android version?</summary> - [ ] I have bumped `checkoutKitAndroid` in `platforms/android/gradle/libs.versions.toml` - [ ] I have updated the Gradle/Maven version snippets in `platforms/android/README.md` </details> > [!TIP] > See the [Contributing documentation](./CONTRIBUTING.md) for the full release process per platform.

What changes are you making?
One core file added for each platform
E2EControlLink- parses an incoming deep link into a types argumentThe extra changes in react-native are because we already started a host
cartand this PR supercedes that pattern withe2eas a root host that handles multiple commandsWhy
To keep the end to end test running quickly and without wasting time validating sample app logic as such, which we've opted for a deep link scheme that can prepare some state for us such as cart and products
maestro commands will be something like this rather than a dozen steps to get the cart prepped and move to CartView
How
The shape is
<app-scheme>://e2e/<command>?<parameters>, where the scheme is the app id.This PR adds one parser per platform that turns such a link into a typed command
We use a common
e2ehost on every command, so one intent-filter and one CFBundleURLScheme cover all of them (if you look at the AndroidManifest we use a single host, rather than havingnentries per command.A malformed control link throws, so a typo in a flow fails the test instead of passing silently.
The parsers accept identical input on all platforms.
Note: If you're familiar with maestro you might be wondering why I opted for a reset deep link here, theres a bug in the browserstack integration here,
clearStateis a command in maestro that achieves it by uninstalling and reinstalling the app, in browserstack it reports a success but fails to reinstall the app, which led to broken tests.Whats Next
Wiring the parsers into each app is the next PR in the stack.
Before you merge
Important
platforms/swift/README.mdand/orplatforms/android/README.md)Releasing a new Swift version?
ShopifyCheckoutKit.podspecplatforms/swift/Sources/ShopifyCheckoutKit/ShopifyCheckoutKit.swiftplatforms/swift/README.md(major version only)Releasing a new Embedded Checkout Protocol version?
embeddedCheckoutProtocolAndroidinplatforms/android/gradle/libs.versions.tomlprotocol/languages/kotlin/embedded-checkout-protocol/api/embedded-checkout-protocol.apiif the public API changedReleasing a new Android version?
checkoutKitAndroidinplatforms/android/gradle/libs.versions.tomlplatforms/android/README.mdTip
See the Contributing documentation for the full release process per platform.