Skip to content
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

Improve deep link handling on cold start #2026

Merged
merged 1 commit into from
Apr 2, 2024

Conversation

nathreed
Copy link
Contributor

Previously, if the app was not already running when the Safari action extension was used to open a post in the app, the post would open in the in-app Safari instead of using the Ice Cubes UI.
The action extension only worked well if Ice Cubes was already running but backgrounded when it was used.
This was because of the hasConnection(with:) check used to ensure that the current server has a federation relationship with the server the post is on.
Early in app launch, the list of federated peers has not come back from the API request yet, so hasConnection(with:) was always returning false.

To fix, issue a request to fetch the peers as part of the URL handling process, before checking hasConnection(with:) to make the final navigation decision.
As an optimization, only do this if hasConnection(with:) returns false initially -- if it returns true, we already know a connection exists so no need to check again.

Previously, if the app was not already running when the Safari action extension was used to open a post in the app, the post would open in the in-app Safari instead of using the Ice Cubes UI.
The action extension only worked well if Ice Cubes was already running but backgrounded when it was used.
This was because of the `hasConnection(with:)` check used to ensure that the current server has a federation relationship with the server the post is on.
Early in app launch, the list of federated peers has not come back from the API request yet, so `hasConnection(with:)` was always returning `false`.

To fix, issue a request to fetch the peers as part of the URL handling process, before checking `hasConnection(with:)` to make the final navigation decision.
As an optimization, only do this if `hasConnection(with:)` returns `false` initially -- if it returns `true`, we already know a connection exists so no need to check again.
@Dimillian Dimillian merged commit 8038e8e into Dimillian:main Apr 2, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants