Fixes#1300.
## Summary
Updates Alamofire to 5.x and updates how we do authentication adapting and failure retrying.
## Screenshots
n/a
## Link to pull request in Documentation repository
n/a
## Any other notes
- Switches to using `AuthenticationInterceptor` to handle authenticated requests. This has a lot of good things: it's heavily tested, it only executes the refresh one at a time, and it has explicit handling of "this request failed with an _old_ access token" which is the root cause of some logouts in #1300.
- Switches from manually doing retries and backoffs to using `RetryPolicy` which also adds in retries for 5xx errors in addition to all of the URLError-specific logic that it has.
- Updates the apparently-copied-from-`AlamofireObjectMapper` repository for 5.x and removes some old Sodium-based handling that is now part of the Webhook flow, which is separate from Alamofire.
## 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.
This doesn't affect what happens -- saving 404 text to something.mp4 doesn't play -- but it does make the logs easier to see if something is going wrong.
- NSLog is dangerous in production; it crashes randomly on iOS 13. It also truncates the logs to a certain length, unlike print(), so swap to that one.
- This also changes a few try! into not-force-unwrapping, one or two of which have fired into the crash reporter.
- Avoids logging about deleted zones while they are being deleted. Likely related to the infinite-loop zone (#1136) but definitely happens quite a bit right now.
* Move Sentry into Shared, add to all extensions
This gives us crash reporting for extensions that run on the phone and watch.
* Exclude unofficial builds from reporting into Sentry
We provide three lifecycle events communicated back to HA, `ios.finsihed_launching`, `ios_entered_background` and `ios.became_active`. One of the most obvious use cases, IMHO, of `ios.became_active` is to reset/clear the app badge. However, we currently provide any clear data in the event payload about the source (e.g. device name) of the event. This PR provides the same basic device info that we include in the action events. For sake of a single source, the definition of dictionary in `HomeAssistantAPI` is changed to public rather than duplicating elsewhere. Tested against current dev
- Converts to String for the API-like things we provide for template rendering: intent handling and x-url-callback.
- Handles various kinds of results for Complication template handling: tries to smooth values to floats for percentile-based rings and gauges, describes via String for anywhere else.
- Adds a small amount of validation when entering templates in a Complication's Configuration.
Fixes#1177. Fixes#1180.
Running the latest Watch Extension on my device, I'm seeing a lot of kills like:
> Termination Reason: CAROUSEL, Background App Refresh watchdog transgression. Exhausted wall time allowance of 15.00 seconds.
From the [documentation on `WKApplicationRefreshBackgroundTask`](https://developer.apple.com/documentation/watchkit/wkapplicationrefreshbackgroundtask#), the suggestion is to kick off a background URLSession request and immediately end the app refresh task, allowing the background session code paths to complete the execution. Given we're being killed so often, I'm guessing that part'll work just fine.
Fixes#1191.
- Moves our background refresh timing from every 5 minutes to every 15 minutes. Apple [documents this](https://developer.apple.com/documentation/clockkit/updating_your_complication) as:
> The system carefully budgets background refresh tasks. You can schedule only one refresh task at a time. If you have a complication on the active watch face, you can safely schedule four refresh tasks a hour.
- When we refresh the rendering data backing complications, we now immediately tell ClockKit to invalidate/refresh our active complications. I'm not sure what was triggering refreshes before, but they were highly irregular. With this change, I can reliably see (at the new timing above) my complications update at around :00, :15, :30, and :45 on the hour.
- Stops restricting complication rendering to only the active complication. This makes switching between watch faces have the most accurate data possible, and is a very small increase in the size of this request/response -- we're already doing a network call, and the biggest cost of a network call is doing one more than the JSON payload size (which is small).
- Reduces how often we do complication updates on the iPhone side of thing. This doesn't help as much as I had thought it did; we're restricted in how often we can push watch data updates, and since we're not (yet?) using the "update the complications" WatchConnectivity feature, we're not necessarily directly forcing an update anyway.
- Reduces minorly how often we execute syncs on startup. If there's any synced Actions or NotificationCategory, this ends up doing 2+ syncs on startup; removing this restriction does 0-1, depending on if there's any synced. It always occurs when changes are made.
- Combines all .entitlements into either: App-iOS, App-catalyst, WatchApp, Extension-iOS or Extension-catalyst.
- Cleans up and renames all the schemes to match target names
- Moves around several folders and deletes some old files.
- Converts Podfile to be hierarchical, rather than calling shared methods.
- Always runs MaterialDesignIcons script; aborts early if it's up-to-date.
- Updates all dependencies.
This is somewhat in prep of being able to make the project file generated, but also just organizes things into more concrete directory structures.
This pulls out _all_ of the build settings from the root level, and most from the target level, into xcconfigs.
The new directory structure looks like:
- Sources
- App
- (everything from HomeAssistant/)
- WatchApp
- Shared
- MacBridge
- Extensions
- Intents
- NotificationContent
- NotificationService
- Share
- Today
- Watch
- Widgets
- Tests
- App
- UI
- Shared
Somewhat intentionally, the file structure under these is not yet standardized/organized.
The project targets are now:
- App
- WatchApp
- Shared-iOS
- Shared-watchOS
- MacBridge
- Tests-App
- Tests-UI
- Tests-Shared
- Extension-Intents
- Extension-NotificationContent
- Extension-NotificationService
- Extension-Share
- Extension-Today
- Extension-Widget
- WatchExtension-Watch
This does not yet clean up resources vs. sources, nor does it handle some of the "it's in Sources/App but it's part of Shared" crossover directory issues.
