iOS: add App Group container access and NSE bridge module for upcoming NotificationService extension#86
Draft
jkaczman wants to merge 1 commit into
Draft
iOS: add App Group container access and NSE bridge module for upcoming NotificationService extension#86jkaczman wants to merge 1 commit into
jkaczman wants to merge 1 commit into
Conversation
…pcoming NotificationService extension
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
This PR lays groundwork for the iOS NotificationService extension for properly handling thumbnail notification upgrades (re #78)
We now store new data in iOS in an App Group container, so that it can be accessed by native Swift code running in a NotificationServiceExtension. This will allow it to share MLS state and decrypt notifications in native code through a C ABI interface. The extension is not allowed to access Application Support or anything like that for process isolation reasons. An iOS app extension runs as a separate process (with its own sandbox), and that sandbox can't touch the main app's Documents / Application Support dirs. An App Group container is the only way in iOS for the app and the app extension to share state, so that's why I did it like this.
Old cameras will still work on the old directory in Application Support, but new pairings will be directed to the App Group container. However, old cameras will not upgrade notifications with thumbnails due to the restrictions mentioned above.
This is not a complete fix. It is only part of the solution; it was done this way to allow for less than 1000 LOC PRs for proper squash-and-merge conventions. Therefore, it will be merged into this "dev-ios-nse" branch, which will have another follow up PR finishing the implementation. There will also be another PR in the secluso/core repository implementing this slim C ABI interface for the NSE to work with (as the NSE has a 24MB memory budget; app_native is likely overkill and will surpass this). Breaking it up into multiple PRs like this also allows for easier review, as a massive PR is harder to parse.
Includes a small Dart-side bridge module that writes server creds into the App Group whenever they change (so NSE can call the relay on its own). Also some utility functions for the next PR (e.g. event-drain for the consumer)
Added a couple of tests against the path resolver (determine if camera directs to App Group / legacy) and bridge module. We haven't been doing this as much for mobile_client, but probably should do so for future PRs (and work on getting tests in place for all the current functionality).