Conversation
timbms
force-pushed
the
migrateToAppIntents2
branch
from
2a7609c to
8d77998
Compare
There was a problem hiding this comment.
Pull request overview
This PR migrates the openHAB iOS application from the legacy Intents framework to the modern App Intents framework introduced in iOS 16. The migration removes the separate Intents extension target and replaces it with native App Intents implementations directly in the main application.
Key changes:
- Removes the openHABIntents extension target including all handler classes, configuration files, and tests
- Adds eight new AppIntent implementations in the AppIntents folder for controlling openHAB items
- Updates the Xcode project to remove the extension target and integrate the new App Intents
Reviewed changes
Copilot reviewed 21 out of 22 changed files in this pull request and generated 17 comments.
Show a summary per file
| File | Description |
|---|---|
| openHABWatch/Domain/UserData.swift | Minor whitespace cleanup in a comment |
| openHABIntentsTests/SetSwitchStateIntentHandlerTests.swift | Removed test file for legacy intent handler |
| openHABIntents/openHABIntents.entitlements | Removed entitlements for legacy intents extension |
| openHABIntents/SetSwitchStateIntentHandler.swift | Removed legacy switch state intent handler |
| openHABIntents/SetStringValueIntentHandler.swift | Removed legacy string value intent handler |
| openHABIntents/SetNumberValueIntentHandler.swift | Removed legacy number value intent handler |
| openHABIntents/SetDimmerRollerValueIntentHandler.swift | Removed legacy dimmer/roller intent handler |
| openHABIntents/SetContactStateValueIntentHandler.swift | Removed legacy contact state intent handler |
| openHABIntents/SetColorValueIntentHandler.swift | Removed legacy color value intent handler |
| openHABIntents/OpenHABIntentHelper.swift | Removed legacy intent helper utilities |
| openHABIntents/IntentHandler.swift | Removed main intent extension handler |
| openHABIntents/Info.plist | Removed extension configuration |
| openHABIntents/GetItemStateIntentHandler.swift | Removed legacy get item state intent handler |
| openHAB.xcodeproj/project.pbxproj | Updated project to remove intents extension target and add new App Intents files |
| AppIntents/SetSwitchState.swift | New App Intent for setting switch states (on/off) |
| AppIntents/SetStringValue.swift | New App Intent for setting string item values |
| AppIntents/SetNumberValue.swift | New App Intent for setting number item values |
| AppIntents/SetDimmerRollerValue.swift | New App Intent for setting dimmer/roller shutter values |
| AppIntents/SetContactStateValue.swift | New App Intent for setting contact states |
| AppIntents/SetColorValue.swift | New App Intent for setting color values in HSB format |
| AppIntents/Home.swift | New App Entity representing an openHAB home configuration |
| AppIntents/GetItemState.swift | New App Intent for retrieving item states |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 21 out of 23 changed files in this pull request and generated 7 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 26 out of 28 changed files in this pull request and generated 8 comments.
Files not reviewed (1)
- openHAB.xcworkspace/contents.xcworkspacedata: Language not supported
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 40 out of 42 changed files in this pull request and generated 10 comments.
Files not reviewed (1)
- openHAB.xcworkspace/contents.xcworkspacedata: Language not supported
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 37 out of 39 changed files in this pull request and generated 3 comments.
Files not reviewed (1)
- openHAB.xcworkspace/contents.xcworkspacedata: Language not supported
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Align iOS behavior with Android by highlighting the single mapping button when the item's state matches the mapping command. Signed-off-by: Tim Mueller-Seydlitz <timbms@gmail.com>
- Always send slider value on release, not just in releaseOnly mode - Add step parameter to Slider to match watchOS and prevent continuous vs step-adjusted value mismatch - Only clear pendingValue when server confirms the value we sent, preventing jumps from intermediate throttled responses Signed-off-by: Tim Mueller-Seydlitz <timbms@gmail.com>
Simplify the drag gesture to send the command immediately on touch instead of waiting for release, removing the pressed state tracking. Signed-off-by: Tim Mueller-Seydlitz <timbms@gmail.com>
Guard against repeated sends in onChanged by tracking singlePressed state. Add press/release visual feedback and selection animation. Signed-off-by: Tim Mueller-Seydlitz <timbms@gmail.com>
When allowedTypes is empty (GenericItemEntity), treat it as nil so searchItems matches all types instead of matching none. Signed-off-by: Tim Mueller-Seydlitz <timbms@gmail.com>
Signed-off-by: Tim Mueller-Seydlitz <timbms@gmail.com>
- Replace force unwrap with guard let in loadCurrentPage() to prevent crash when pollDataForPage returns nil - Remove duplicate property assignments in OpenHABWidget convenience init that overwrote nil-coalesced defaults with raw optionals - Fix ButtonGridButton sending commands twice for press-release buttons by separating Button action (regular taps) from gesture (press-release) - Fix onPressGesture firing onPress on every drag movement by using a stateful ViewModifier that guards against re-entry - Extract duplicate PreviewList struct into PreviewConstants.swift Signed-off-by: Tim Mueller-Seydlitz <timbms@gmail.com>
PreviewConstants.swift has no Xcode target membership so types defined there are invisible to the compiler. Place PreviewList in SegmentedRowView.swift as a non-private type inside #if DEBUG so SliderRowView.swift (same module) can reference it too. Signed-off-by: Tim Mueller-Seydlitz <timbms@gmail.com>
Signed-off-by: Tim Mueller-Seydlitz <timbms@gmail.com>
The method body was empty — connection handling moved to the async for-await loop in init() and the view's onChange modifier. Signed-off-by: Tim Mueller-Seydlitz <timbms@gmail.com>
Signed-off-by: Tim Mueller-Seydlitz <timbms@gmail.com>
Signed-off-by: Tim Mueller-Seydlitz <timbms@gmail.com>
Signed-off-by: Tim Mueller-Seydlitz <timbms@gmail.com>
And this makes shortcuts get converted?
I think dropping iOS16 Support will be fine. Do we need to configure anything in the AppStore to keep 3.2 available for people keeping their devices more than 9 years? Though it's very few, it seems like there still are a handful people using them:
Overall, on average around 600 people are active and have opted in to sharing their usage data:
And I think almost all are on iOS26: (Not going to put another graph here but only about 40 are remaining on platform versions 17 and 18, so we can think about dropping them soon, too) |
Signed-off-by: DigiH <17110652+DigiH@users.noreply.github.com>
|
I added more German translations, but did keep the Stale entries for the time being, as the old Intents would still require them if kept. If it is decided to up the minimum requirement to iOS 17 they can all be deleted along with the previous Intents. |
Signed-off-by: DigiH <17110652+DigiH@users.noreply.github.com>
|
Is it just me with the Simulator again where I still see an unwanted localised home name when setting up a new shortcut? 
where it should be the unlocalised Home 
|
I think I understand now what that is. It says to choose a home. Maybe it should be "choose home" instead of just "home" and in German "Zuhause wählen" instead of "Zuhause". |
|
@TAKeanice you are right |
|
I'm only talking about the "Zuhause" in the screenshot above, which is automatically wrongly set to the localised translation of my poem name "Home" which is then only correctly displayed as the only choice in the selection popup. I don't have an issue with the label "Zuhause" while maybe an additional colon might be clearer - "Zuhause:". I don't think "Zuhause wählen" is necessary,. as it should already be correctly auto-populated, and also is if the home name is not "Home", but something else. |
After my revalation I know that I was wrong here
These are still relevant. |
|
As there were other localisation issues solely with the Simulator before though, can anybody check if this is also happing on an actual iPhone? ;) |
I can't follow.
After deletion it jumps back to "Zuhause". So I think the only change should be to add "..." or "choose" or whatever to the label on the right shown when nothing is selected |
Signed-off-by: Tim Mueller-Seydlitz <timbms@gmail.com>
In your first screenshot it says]
where it should already be
as Home is the name of your only/currently active home. There should not be any need to tap on the blue Zuhause to select the correct Home in the popup. I. e. actual home names should never be localised. BTW @TAKeanice Are you also generally running the openHAB app in English, with your home name being Home? |
Signed-off-by: Tim Mueller-Seydlitz <timbms@gmail.com>
Signed-off-by: Tim Mueller-Seydlitz <timbms@gmail.com>
|
After the last commits I am still seeing a localised home name in German, but more importantly: when tapping on the Items variable in a shortcut it brings up an empty sheet, no Items listed whatsoever, in German or English. Can anyone reproduce this? |
|
And looking further into the localised home name: • The actual home name does not even seem to be taken into consideration as the default value for the selected game in shortcuts, but it always just seems to be the default unusual name given to any newly created home. I assume this because renaming the home name in the openHAb app to something other than "Home" does not affect the default name for newly created shortcuts. Only the subsequent popup does have the correct renamed home name. This should also be the name appearing as the already selected default home in Germany as well as in English. So this not might not be a localisation issue after all, but just a default selection not honouring actual home names at all. |
|
@DigiH I think you still got the part with the "Zuhause" wrong: It is not the name of a randomly chosen or default home, but the name of the prompt or placeholder when no home is selected. It's perfectly valid to have that localized, only the text might be clearer to avoid exactly the confusion you seem to have. But I also think it should not be necessary to select any value for the home variable. The way this worked previously in the old logic of INIntents was that unique items from any home are not prompting a query for the home when triggering the shortcut. Only if there were two identically named items, it would conflict and prompt for a home. I also wrote this in number 4 of my improvement recommendations. |
If that is really the case then I definitely have got it working ;) But why would it be that way? So anyone who keeps the default home name assigned it, which it initially gets, does get the benefit of not having to worry about assigning homes though the popup, while anybody who wants a more personalised home name has to go through the popup every time they want to create a shortcut? And as we already do have the correct home name in the popup, why not populate it directly as the home, especially if there is only one home. And aren't homes defined by a unique UUID in the background to their name? Let's say I have a home in a rural area, but then decide to get a second home in the middle of the city. Then I might want to rename my default rural home "Home" to "Country Home" - would that mean that all shortcut assigned homes would then have to be manually adjusted? This is not the case in the current SiriKit Intents after renaming a home, even though the home name in the shortcut stays the old name it works correctly with the new home name - which makes it even more confusing for me than before. So why would the name aways be the default name when, after choosing the correct name from the popup it does stay the proper chosen correct name, even after closing the shortcut and opening it again?!? I'm sorry, but your last comment made me even more confused now; as to what the Home row in the shortcuts should actually signify and how it should display and work 😕 |
Signed-off-by: Tim Mueller-Seydlitz <timbms@gmail.com>
Let me make another explanation attempt. If you see "Home" in the english UI, you see "Zuhause" in the German UI. Both mean no home has been selected. English users just have the downside that they cannot distinguish if their home called "Home" or no home is selected, because in both cases the UI shows "Home" and not even the color changes. In the German UI it would be distinguishable because as you saw in my screenshots, without a home selected the UI shows "Zuhause". Both behave the same way (in INIntents at least they did): |
is it really though?
But what about the home names of already existing shortcuts? Let me take you trough a quick excercies with TestFlight 3.2.20 - I assume the latest official release might behave the same - in English to avoid any possible localisation issue • I set up a new home in the app, it does get the default home name "Home" And I do know that when renaming a home it does state that this might break any existing shortcuts, but why would I even tap and hold on …, then select Edit and the expand the home row in the opened shortcut, when just tapping the shortcut confirms that it is running fine. Also how all these different home names will migrate to the new App Intents remains to be seen. And if this wasn't confusing enough already I am now planning to add another home of my friends or family to the app, which has some identical item names but not all. So all of a sudden now some of my "Home" shortcuts still work, while other "Home" shortcuts fail, same with some of the Crib and Pad shortcuts. O do know the reason why because you shared the insider info further above, but how this should also migrate to the new App Intents with all the different assigned home names is to be seen. So is there really a UUID in the background or is it just the insider info you shared above about the assigned home not not really being taken into account when there is only one home present? I also know that my exercise above is on the extreme side, but any user who has created at least one shortcut in the past and has renamed their home at least once could face this to some extend. If you now tell me that all this is working as intended and it is only me who finds this wildly confusing, and that all these possible different home names in the shortcuts won't be an issue for the App Intent migration, then I am fine with that and won't go on any further. I only do have two shortcuts for my hoe which get tied in with some automations, so worse comes to worst they can easily be recreated very quickly. |
Gosh, you could be right. I probably wanted to use UUIDs to reference homes in the INIntents version but encountered technical limitations. The warning and that unique items work without selected home mitigated this caveat. I will check that this weekend to confirm it. |
This PR migrates the openHAB iOS application from the legacy Siri Intents to the modern App Intents framework. The migration removes the separate Intents extension target and replaces it with native App Intents implementations directly in the main application.
Key changes:
BTW: This PR eliminates the last compiler warnings related to the Apple generated code from the legacy Siri Intents.
Depends on #892