<!-- Thank you for submitting a Pull Request and helping to improve Home
Assistant. Please complete the following sections to help the processing
and review of your changes. Please do not delete anything from this
template. -->
## Summary
<!-- Provide a brief summary of the changes you have made and most
importantly what they aim to achieve -->
## Screenshots
<!-- If this is a user-facing change not in the frontend, please include
screenshots in light and dark mode. -->
## Link to pull request in Documentation repository
<!-- Pull requests that add, change or remove functionality must have a
corresponding pull request in the Companion App Documentation repository
(https://github.com/home-assistant/companion.home-assistant). Please add
the number of this pull request after the "#" -->
Documentation: home-assistant/companion.home-assistant#
## Any other notes
<!-- If there is any other information of note, like if this Pull
Request is part of a bigger change, please include it here. -->
<!-- Thank you for submitting a Pull Request and helping to improve Home
Assistant. Please complete the following sections to help the processing
and review of your changes. Please do not delete anything from this
template. -->
## Summary
<!-- Provide a brief summary of the changes you have made and most
importantly what they aim to achieve -->
## Screenshots
<!-- If this is a user-facing change not in the frontend, please include
screenshots in light and dark mode. -->
## Link to pull request in Documentation repository
<!-- Pull requests that add, change or remove functionality must have a
corresponding pull request in the Companion App Documentation repository
(https://github.com/home-assistant/companion.home-assistant). Please add
the number of this pull request after the "#" -->
Documentation: home-assistant/companion.home-assistant#
## Any other notes
<!-- If there is any other information of note, like if this Pull
Request is part of a bigger change, please include it here. -->
<!-- Thank you for submitting a Pull Request and helping to improve Home
Assistant. Please complete the following sections to help the processing
and review of your changes. Please do not delete anything from this
template. -->
## Summary
<!-- Provide a brief summary of the changes you have made and most
importantly what they aim to achieve -->
- `static let` plays nicely with modern Swift concurrency (async/await)
- `static let` makes it impossible to mutate the values - causing
undefined behavior in some cases
<!-- Thank you for submitting a Pull Request and helping to improve Home
Assistant. Please complete the following sections to help the processing
and review of your changes. Please do not delete anything from this
template. -->
## Summary
<!-- Provide a brief summary of the changes you have made and most
importantly what they aim to achieve -->
As the [minimum watchOS is
8](https://github.com/home-assistant/iOS/pull/2609) and [minimum iOS
15](https://github.com/home-assistant/iOS/pull/2469), this PR removes
redundant `#available` checks.
Co-authored-by: Bruno Pantaleão Gonçalves <bruno.ing879@gmail.com>
## Summary
Swift lint and swiftformat are outdated. This PR does update those +
applies the new formatting form swiftformat.
There is 1 swift file with a manual change:
`Sources/Vehicle/Templates/Areas/CarPlayAreasViewModel.swift`. This is
done because `swiftlint` did create the following swiftlint error:
`error: Cyclomatic Complexity Violation: Function should have complexity
10 or less; currently complexity is 11 (cyclomatic_complexity)`.
Because it does change a lot of files the question is if we want to
finetune the `swiftformat` rules.
## Screenshots
No user facing changes.
## Link to pull request in Documentation repository
NA
## Any other notes
NA
## Summary
Fixes#2316, but not the underlying problem, by not confirming local
pushes which fail to be added to the notification center.
## Any other notes
The underlying problem is that we cannot attach anything to a
notification in the Local Push extension as of iOS 16.4. This is clearly
a regression, and it doesn't matter where we write it, it fails to
locate it in locations vended by FileManager:
- The temporary directory
- The documents directory
- The shared container for our app group
All of these fail to attach, all in the same way, and all of them:
1. Are able to be read by the process using `Data(contentsOf: …)`
2. Work fine in the Notification Service Extension
This is definitely a regression on Apple's side and frustratingly my
radar has gone ignored. Par for the course, I guess.
## Summary
Implements the push send and rate limit information in Swift using Vapor.
## Any other notes
This will allow us to get off Firebase, which gives a few immediate benefits:
- We can send PushKit notifications for complications, widgets, and location updates.
- We remove the last SDK that uses network connectivity to third parties.
- Updates several dependencies
- Removes Lokalise -- if we can't do it on Catalyst, it doesn't feel worth it to do it elsewhere
- Migrates the NotificationTestCases from a Podspec that keeps having issues to a fastlane script which copies in the latest ones
Requires home-assistant/core#54947. Refs #1799.
## Summary
Advertises as supporting confirm for local pushes and sends confirmation when receiving a local push.
## Any other notes
Confirmable notifications means the app is required to acknowledge receipt of a notification to core, otherwise it will be sent over the normal non-local-push route. This should eliminate a class of potential bugs in the app, where notifications fail to deliver via local push for some reason; however, this means that there's a possibility that notifications may be delayed if such a bug is occurring, so it is hopefully maybe still noticeable/annoying enough to get reports that we can trace back to find the root cause.
## Summary
Fires a sensor update pass if the app is running when the focus status changes.
## Any other notes
The focus sensor _always_ live-updates, but it does so in the Intents extension. This allows the Intents extension to inform the app that it did an update, which (unfortunately, for now) fires a sensor update pass in the app. So we're over-updating the sensors, but we're keeping the in-app sensor list updated. Worth the cost, I think, since the app running when focus changes happening feels rare unless the user's playing with the sensor.
Refs #1799.
## Summary
I can't see too many cases where we'd drop a subscription, but this is one of them - basically, multiple connection info change notifications fire at once, and the invoked method isn't threadsafe.
## Any other notes
Also adds some more logging and discrete subscription cancelling when stopping to hopefully help debug this in the future if it continues.
## Summary
- Supports setting interruption-level via local push. Fixes#1658.
- Configures entitlement and notification setting. Fixes#1659.
## Link to pull request in Documentation repository
Documentation: home-assistant/companion.home-assistant#540
## Any other notes
Early beta days, I can't tell if the entitlement is all that we need, because I need the notification settings in the simulator which really doesn't like mutated-while-compiling entitlements. It's possible once we switch to Xcode 13 this may not need to be mutated at runtime, and the setting can go away and it'll all be happy.
Refs #1570 and home-assistant/core#50750. Fixes#1382.
## Summary
Adds a new app extension to do local push notifications on iOS 14 when connected to internal SSIDs.
## Screenshots
Adds a default-on setting to Internal URL:
| Light | Dark |
| -- | -- |
|  |  |
## Link to pull request in Documentation repository
Documentation: home-assistant/companion.home-assistant#539
## Any other notes
- Updates the "you need always permission" warning in Internal URL editing to be vibrantly red, to really point out its importance.
- Sets the code signing for the app and the push target to 'manual' on device, hopefully for our internal team only. Special entitlements really do not play well with open source. Worth noting that it is not possible to test this feature without being on the HA team since it does not work in simulator (as far as I can tell) and running on-device requires entitlements.
- Moves commands into Shared in a slightly-easier registration mechanism, so we can share them in the local push extension.
Refs #1382 and home-assistant/core#50750.
## Summary
Uses (and requires) the core-2021.6 local push handling to subscribe to notification calls and show notifications without going through the Apple Push Notification Service.
## Screenshots
| Light | Dark |
| -- | -- |
| <img width="712" alt="Screen Shot 2021-06-06 at 18 08 59" src="https://user-images.githubusercontent.com/74188/120946730-57a8d600-c6f2-11eb-8dde-b03b42a0a03a.png"> | <img width="712" alt="Screen Shot 2021-06-06 at 18 09 09" src="https://user-images.githubusercontent.com/74188/120946737-5d9eb700-c6f2-11eb-8563-8d9b8d8e075b.png"> |
## Link to pull request in Documentation repository
Documentation: home-assistant/companion.home-assistant#539
## Any other notes
- Only works on macOS for this first round. The iOS implementation will be the same manager, but needs extensions scaffolding that I have to put together separately.
- iOS will also likely have a setting to control this behavior, since it has potential battery implications; macOS doesn't have such concerns.
- Adds tests around the parsing of the raw notification payloads that uses the same tests introduced in home-assistant/mobile-apps-fcm-push#55.
- Shows the state of the local push connectivity in Notifications. With multi-server support, this will probably need to be broken down by server, or moved into the server-specific configurations.
This also sets us up to support encrypted notifications, since we're now able to handle the service call's data without any kind of remote manipulation. Unfortunately Apple declined the entitlement which makes this extremely easy, so we'll still need to handle the "commands are unencrypted" nonsense.
