Don't make notification window key as it could conflict with the main window #50
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
UINotifications.framework: Coverage: 97.93
Generated by 🚫 Danger Swift against be26c30 |
For the presentation of notifications the window does not have to be key. It will still receive touch events (gestures, buttons etc) but won't receive keyboard events and motion events.
kairadiagne
force-pushed
the
feature/window-management
branch
from
e51ff71
to
be26c30
Compare
AvdLee
approved these changes
Dec 18, 2020
|
Congratulations! 🎉 This was released as part of Release 1.4.1 🚀 Generated by GitBuddy |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What's the problem?
We ran into an issue with an Authentication library and
ASWebAuthenticationSession. The library would automatically use the applicationskeyWindowas the presentation anchor for the authentication session. If someone would trigger a login while a notification was presented the safari view controller presented by the authentication session would disappear as soon as the notification was dismissed.What was causing the issue?
This happened because the notification window was the apps
keyWindowwhile a notification was presented. As only one window at a time can be the key window the auth SDK was picking that window as the presentation anchor of the auth session. When the notification was dismissed the apps main window became key again and that would break the authentication flow.How it was solved?
It turns out that the
UINotificationWindowdoes not have to be the key window. The only thing it needs is touch events, and those are always delivered to the window in which it occurred. The only requirement for that is that the window is visible. We also want notifications to be presented on top of the app. This is already managed by setting an appropriate window level for presentation (by default above the status bar).The only events that the window can't handle if it is not key are:
Those are not relevant for the use case of presenting a simple in app notification.