## 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
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.
## Summary
Allows attachments to be loaded on-the-fly in the content extension if they are not present.
## Link to pull request in Documentation repository
Documentation: home-assistant/companion.home-assistant#510
## Any other notes
- Adds `lazy` as an option to the `attachment` dictionary. When true, this prevents the attachment from being downloaded except when displayed in the content extension.
This is similar, but not identical, to hide-thumbnail. Hiding the thumbnail still uses the internal storage of the notifications which are limited to e.g. 50mb. However, we'd still want to pre-load those attachments even if the thumbnail is hidden.
- Retries non-lazy attachments which failed due to a network error when the content extension opens.
Adds new fastlane lanes:
- `fastlane lint` which checks the linters
- `fastlane autocorrect` which applies the linters which can autocorrect (Rubocop, SwiftFormat)
Adds a build step to the Codegen abstract target which runs SwiftFormat in lint mode, pointing out what it's going to change when run.
Applies SwiftFormat to nearly all code -- exempts a few externally-sourced files and generated code.
## Summary
- Refactors notification attachment into smaller units. Adds tests.
- Adds an image attachment with whatever the error reason is when an attachment fails to download.
- Adds a Shared framework scheme which can run just its tests. It's a bit faster than doing the whole app which has a lot of extensions and watchOS targets.
## Screenshots
## Any other notes
This does not (yet?) create the error images for the service timeout. Not sure how relevant that may end up. I haven't yet come across a case of this happening in logs and being confusing.
