fix: universal links when touch a push notification open host app

[levibostian]

Closes: #262

Before merging

• Code review
• Docs change helping customers setup universal links deep linking. Including the need to implement the function func application(_ application: UIApplication, continue userActivity: NSUserActivity, restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void) -> Bool. - docs pr made

This PR fixes this bug by:

• If customer's app implements the function func application(_ application: UIApplication, continue userActivity: NSUserActivity, restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void) -> Bool in their app to handle deep links (and they return the correct value from the function), we will attempt to call that function first.
• If they do not implement that function or they return false from the function, we fallback to opening the URL system-wide as the SDK does already today.

This solution should keep backwards compatibility with the SDK customers today - as long as customers are using func application(_ application: UIApplication, continue userActivity: NSUserActivity, restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void) -> Bool correctly (returning an accurate value), this SDK should not be introducing a breaking change for anyone.

QA tests:

• Touch a push without a deep link in it. Expect host app opens, doesn't show "Switch workspace" screen.
• Touch a push with deep link using app scheme url remote-habits://switch_workspace?site_id=app&api_key=scheme. Expect switch workspace screen shows with "app" and "scheme" filled into the text fields on the screen.

This tests backwards compatibility of our SDK.

• Touch a push with a deep link using universal links https://remotehabits.page.link/switch_workspace?site_id=universal&api_key=link. Expect switch workspace screen shows with "universal" and "link" filled into the text fields on the screen.

[ami-oss-ci]

Pull request title looks good 👍!

If this pull request gets merged, it will cause a new release of the software. Example: If this project's latest release version is 1.0.0. If this pull request gets merged in, the next release of this project will be 1.0.1. This pull request is not a breaking change.

All merged pull requests will eventually get deployed. But some types of pull requests will trigger a deployment (such as features and bug fixes) while some pull requests will wait to get deployed until a later time.

To merge this pull request, add the label Ready to merge to this pull request and I'll merge it for you.

This project uses a special format for pull requests titles. Expand this section to learn more (expand by clicking the ᐅ symbol on the left side of this sentence)...

This project uses a special format for pull requests titles. Don't worry, it's easy!

This pull request title should be in this format:

<type>: short description of change being made

If your pull request introduces breaking changes to the code, use this format:

<type>!: short description of breaking change

where <type> is one of the following:

• feat: - A feature is being added or modified by this pull request. Use this if you made any changes to any of the features of the project.

• fix: - A bug is being fixed by this pull request. Use this if you made any fixes to bugs in the project.

• docs: - This pull request is making documentation changes, only.

• refactor: - A change was made that doesn't fix a bug or add a feature.

• test: - Adds missing tests or fixes broken tests.

• style: - Changes that do not effect the code (whitespace, linting, formatting, semi-colons, etc)

• perf: - Changes improve performance of the code.

• build: - Changes to the build system (maven, npm, gulp, etc)

• ci: - Changes to the CI build system (Travis, GitHub Actions, Circle, etc)

• chore: - Other changes to project that don't modify source code or test files.

• revert: - Reverts a previous commit that was made.

Examples:

feat: edit profile photo
refactor!: remove deprecated v1 endpoints
build: update npm dependencies
style: run formatter 

Need more examples? Want to learn more about this format? Check out the official docs.

Note: If your pull request does multiple things such as adding a feature and makes changes to the CI server and fixes some bugs then you might want to consider splitting this pull request up into multiple smaller pull requests.

[codecov]

Codecov Report

Merging #265 (f68e813) into main (a959033) will decrease coverage by 0.39%.
The diff coverage is 10.00%.

@@            Coverage Diff             @@
##             main     #265      +/-   ##
==========================================
- Coverage   52.98%   52.60%   -0.39%     
==========================================
  Files         101      102       +1     
  Lines        1121     1131      +10     
==========================================
+ Hits          594      595       +1     
- Misses        527      536       +9     

Impacted Files	Coverage Δ
...ogenerated/AutoDependencyInjection.generated.swift	98.36% <ø> (ø)
...es/Common/autogenerated/AutoLenses.generated.swift	13.15% <ø> (ø)
.../Common/autogenerated/AutoMockable.generated.swift	44.07% <ø> (ø)
...ogenerated/AutoDependencyInjection.generated.swift	40.00% <ø> (ø)
...gingInApp/autogenerated/AutoLenses.generated.swift	0.00% <ø> (ø)
...ngInApp/autogenerated/AutoMockable.generated.swift	72.22% <ø> (ø)
...rces/MessagingPush/MessagingPush+AppDelegate.swift	0.00% <0.00%> (ø)
...es/MessagingPush/MessagingPushImplementation.swift	0.00% <ø> (ø)
...ogenerated/AutoDependencyInjection.generated.swift	0.00% <0.00%> (ø)
...agingPush/autogenerated/AutoLenses.generated.swift	14.28% <ø> (ø)
... and 11 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[Shahroz16]

maybe I don't understand the problem statement correctly, here for which i apologize.

But from what I understand,

// to ger a URL from string, the method that gets used is 
URL(string: stringUrl)

and this already validates if it's a valid URL, that is it has the allowedSchemes

if let url = URL(string: stringUrl) {
    print(url)
} else {
    print("Invalid URL")
}

and the method, isLinkValidNSUserActivityLink is expecting an URL as well, so wouldn't this be already vetted? otherwise, the URL would always be nil ?

[levibostian]

I wonder if a class or function rename would help better understand the problem.

This function's job is not to test if a URL is valid. The function's job is to verify that a URL is using only http or https for the scheme part of the URL string.

This is needed because MessagingPush+AppDelegate file's code changes are using NSUserActivity.webpageURL and an exception is thrown if a URL is using the wrong scheme.

Do the tests for this class help explain the use of this function?

Would a better comment help? Renaming of this function?

[Shahroz16]

Thanks, for the explanation, the fixed test removed the confusion.

A class renaming might help here because from my understanding there are two types of links, deeplink and universal link. And I was unsure where NSUserActivity lies in all of this.

But i can't think of any other name either, so I am okay if you go with this or if you are able to think of another one.

[levibostian]

Deep links is an umbrella term. A deep link could be a universal link or an app scheme link.

So, it's not deep link or universal link as universal links are deep links. I did add more details to deep links docs in this pr might be helpful for you to read those changes.

[ami-oss-ci]

	Warnings
⚠️	Swift Package Manager files (Package.) were modified but Cocoapods files (.podspec) files were not. This is error-prone when updating dependencies in one service but not the other. Double-check that you updated all of the correct files.

Generated by 🚫 dangerJS against f68e813

[tfcporciuncula]

This change might not work for SwiftUI apps. We do not officially support SwiftUI apps at this time so we can fix this at a later time if needed.

Would you mind elaborating on why this change might not work for SwiftUI apps? Also, I'm surprised to learn you don't officially support them. Is this mentioned anywhere in the docs? I can't find anything about this there.

[tfcporciuncula]

Do we really want to redefine didHostAppHandleLink here? This means we're never changing the original didHostAppHandleLink from line 74, so it'll always be false when we check below on line 84. I believe we want to remove the let here.

Universal links are still not working for us, and based on our tests this is the culprit.

[levibostian]

To reply to your message, @tfcporciuncula.

I can see how my original comment regarding this pull request and SwiftUI could trigger some questions. My original comment was poorly stated and was not accurate in regards to our SDK and it's features.

We do not expect issues to be encountered when using a SwiftUI app with our SDK. If issues do arise, we are open to resolving them. If you or someone you know use SwiftUI with our SDK and have problems, please submit issues to us and we will help get those resolved!

[tfcporciuncula]

Cool, thanks for the clarification! So far we've had no other issues in our SwiftUI app.