<!-- 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 -->
Following the thread at
https://github.com/home-assistant/iOS/discussions/1764#discussioncomment-10434403
, this is my novice attempt at adding
https://developer.apple.com/documentation/watchkit/wkinterfacedevicebatterystate
or the Watch Battery State, using #2897 as a reference.
## Screenshots
<!-- If this is a user-facing change not in the frontend, please include
screenshots in light and dark mode. -->
I don't know how to take a screenshot of the sensor reporting through
the simulator, I can add them if pointed in the right direction.
## 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#
> _I will look into this. I will look for the corresponding watch
battery change docs if they exist and extend them._
## 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. -->
This is a rough pass. I used #2897 as a launching point - I read it
carefully as this is my first ever code contribution for Swift / iOS,
WatchOS project but I think I had enough heuristics to manage to
_possibly_ get it in the vicinity of it being correct.
I also used `Sources/Shared/API/Webhook/Sensors/BatterySensor.swift` for
including an additional `Battery State` sensor, while exposing both
sensors similarly in name like it's another device.
I think it could still be improved by using
`Sources/Shared/API/Webhook/Sensors/BatterySensor.swift` as a reference.
I tried to change as little as possible.
I wasn't sure if I needed to add anything to
`Sources/App/WatchCommunicatorService.swift`, considering the commit in
#2897,
f961d689e5 (diff-daa127042af3bc5719e4eb4e02e3c50bfcef50084f554e53475f4a4238fdd096)
- I will lean heavily on comments and will iterate where requested, if
the changes aren't edited directly by the maintainers. @bgoncal
- I **do** think I ran the Unit Tests correctly and added to the one
that was also changed in #2897
---------
Co-authored-by: Bruno Pantaleão Gonçalves <5808343+bgoncal@users.noreply.github.com>
<!-- 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 -->
- Create watch home from iPhone
- Configure Assist for watch from iPhone
- Deprecate message for iOS Actions
- Use Scripts or Scenes directly
- Show/Hide Assist in Apple Watch
- Options to require confirmation before running watch item
(script/scene/action)
## Screenshots
<!-- If this is a user-facing change not in the frontend, please include
screenshots in light and dark mode. -->
https://github.com/user-attachments/assets/1e4509f8-45e5-4b39-bfdc-62f9bce64617
## 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. -->
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
- Fixes a crash when saving complications due to #1360 trying to save the MaterialDesignIcons model object as a String.
- Fixes complications not updating on save on the Watch if there are no template-requiring complications.
- Fixes firing the 'success' state on actions on the Watch immediately after asking the phone to send the request, rather than when it completes. This will make it feel slower but will be more accurate since it's failable.
- Updates Communicator to 4.x (the latest) and adjust to its changes.
## Screenshots
n/a
## Link to pull request in Documentation repository
n/a
## Any other notes
As Communicator keeps diverging from how the WatchConnectivity API structures things (especially around error handling) it may be worth thinking about going back to using it directly. For now though keeping our dependencies up-to-date is more important than inaction.
This allows for configuring more than 1 e.g. Modular Small at a time. This requires watchOS 7; for releases before watchOS 7 we do not allow a secondary template to be created. This could be improved by allowing swapping between one of the multiple for watchOS 6 and earlier, but I didn't implement this.
- Adds a "Display Name" to Complications. This is optional and falls back to the template type. This is primarily to differentiate complications; the underlying unique ID is just a UUID.
- Enable previews of complications, which is used when selecting them. This is a stripped-down version of the items in the template, usually just an icon provider or one of the text providers. This is largely easier now since we're now requesting templates for all complications, even those not actively visible.
This also changes the flow when setting up initially. Instead of a list of families to choose from at the start, the user must tap the 'Add' button and pick one from there.
Fixes#839.
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.
One of our top crashes (on all platforms) is crashing when completing the background refresh operation of the Watch Extension's update cycle. I believe this is because the task is being called more than once; presumably because we're mixing multiple types of tasks in one pointer -- communication updates and complication updates, and they stomp on each other.
Another issue here is that we're not using Background Sessions to do the complication updates, when we want to -- when I refactored Webhooks out of the HomeAssistantAPI code path, I neglected to update this Webhook call to handle background updating; it now does.
- Updates complication text rendering to go through the background session supporting Webhook update mechanism.
- Adds support for ring and gauge template rendering. Fixes#1127.
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.
