-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Remove long-unused Iterable deep links handling #24487
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: trunk
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -473,24 +473,15 @@ extension WordPressAppDelegate { | |
extension WordPressAppDelegate { | ||
|
||
private func trackDeepLink(for url: URL, completion: @escaping ((URL) -> Void)) { | ||
guard isIterableDeepLink(url) else { | ||
completion(url) | ||
return | ||
} | ||
|
||
let task = URLSession.shared.dataTask(with: url) {(_, response, error) in | ||
if let url = response?.url { | ||
completion(url) | ||
let task = URLSession.shared.dataTask(with: url) { _, response, error in | ||
guard let url = response?.url else { | ||
return | ||
} | ||
|
||
completion(url) | ||
Comment on lines
+477
to
+481
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Copilot observed:
That's a good point actually. I don't think it's in scope for this PR, but we might want to log a ticket to look into it. Unless... how can we get to the point where a deep link has a response without URL? Is this a legacy from the Objective-C There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If you never expect it to happen, let's add |
||
} | ||
task.resume() | ||
} | ||
|
||
private func isIterableDeepLink(_ url: URL) -> Bool { | ||
return url.absoluteString.contains(WordPressAppDelegate.iterableDomain) | ||
} | ||
|
||
private static let iterableDomain = "links.wp.a8cmail.com" | ||
} | ||
|
||
// MARK: - Helpers | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noticed this when running Jetpack in the Simulator and opening the app simulating a user deep link via
xcrun simctl openurl booted https://wordpress.com/notifications
I considered moving the main thread dispatch earlier on, e.g. in the deep link handling
but I thought it best to be precise and keep the main thread dispatching as close to the code requiring it as possible.
However, forcing the deep link handling to run on the main thread might be a good blanket approach if we fear that other deep link might implicitly require the main thread.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd suggest adding
DispatchQueue.main.async
intrackDeepLink
as you originally wanted and addingwpAssert(Thread.isMainThread)
inshowNotificationsTab
. In the future, we'll try and use@MainActor
as much as we can.Adding an
async
inshowNotificationsTab
is too risky because it has many callers, and some of them might rely on it executing synchronously.