-
-
Notifications
You must be signed in to change notification settings - Fork 824
Add to dialog (widget, android auto favorite) #5622
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Test Results0 tests 0 ✅ 0s ⏱️ Results for commit 6354781. ♻️ This comment has been updated with latest results. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO you're trying to do a bit too much in one go here. The screenshot test is telling - it includes options that are not implemented - and there are actions with todo's in them.
app/src/main/kotlin/io/homeassistant/companion/android/util/vehicle/DomainChecks.kt
Outdated
Show resolved
Hide resolved
app/src/main/kotlin/io/homeassistant/companion/android/webview/addto/AddToAction.kt
Outdated
Show resolved
Hide resolved
|
This PR will be reworked since we are most probably move the UI on the frontend side. All the logic of this PR will be kept except that the frontend will send us an event with the |
OK, until that is decided (not sure where) and implemented this PR can be drafted then? |
Yes indeed I can't do it on my phone but you can or I'll do it tomorrow. |
This is out of scope for this PR but I always wondered if it was the correct approach for the app and frontend to communicate like so for every action. Open app and it says what can and cannot be supported, then now it looks like even further communication is requested for whats supported at different actions. Would it make more sense for the app to first register with the server what it can and cannot support like in some JSON format so we rely a bit less on external bus for whats supported and keep it strictly for actions (i.e. opening settings, triggering dialogs etc....). The features that are supported are on a per device and app version level so the initial communication when we do (re)registration should contain everything needed up until needing to send an action to the app or vice versa. For example if a device doesnt have NFC then it will never have it, so why ask every time. Unless its a user facing setting some of these things will change very little or only on app update. |
Use a browser on your phone 😉 Changed |
3d0650c to
6354781
Compare
...in/kotlin/io/homeassistant/companion/android/widgets/camera/CameraWidgetConfigureActivity.kt
Fixed
Show fixed
Hide fixed
...in/kotlin/io/homeassistant/companion/android/widgets/camera/CameraWidgetConfigureActivity.kt
Fixed
Show fixed
Hide fixed
...in/kotlin/io/homeassistant/companion/android/widgets/entity/EntityWidgetConfigureActivity.kt
Fixed
Show fixed
Hide fixed
...in/kotlin/io/homeassistant/companion/android/widgets/entity/EntityWidgetConfigureActivity.kt
Fixed
Show fixed
Hide fixed
...ssistant/companion/android/widgets/mediaplayer/MediaPlayerControlsWidgetConfigureActivity.kt
Fixed
Show fixed
Hide fixed
...ssistant/companion/android/widgets/mediaplayer/MediaPlayerControlsWidgetConfigureActivity.kt
Fixed
Show fixed
Hide fixed
|
@jpelgrom I've addressed your comments and the frontend has been updated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the frontend has been updated
Frontend PR is still pending review, no?
I'm also still seeing commented out code/unimplemented actions. Let's remove that, there's a lot going on. You already have issues to track them.
...in/kotlin/io/homeassistant/companion/android/widgets/camera/CameraWidgetConfigureActivity.kt
Outdated
Show resolved
Hide resolved
| * or on a phone. | ||
| */ | ||
| @Serializable | ||
| data object AndroidAutoFavorite : EntityAddToAction { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a bit weird to me to have these inside the interface
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a sealed class, I'm used to writing it like this but we could put it outside 👍. It just needs to be in the same package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a dealbreaker and may just be personal preference, my (limited) experience with sealed classes put it outside like in the official docs. Inside makes me think of enums ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've used sealed class when they first introduced it and it was mostly to "replace" enums. That should be why I'm used to do that 👍🏻 but fine for me, one less indentation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait no, it has a reason ^^ if we don't put it in the sealed class the usage is going to be
val action = Tilewhere if it is inside
val action = EntityAddToAction.TileI think it's better for context while working with an action, don't you think?
(even if we could make an import that removes the first part)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now it's a naming question. Changing them so you have TileAddToAction, CameraWidgetAddToAction, etc. would also work in my opinion.
For now fine either way, let's not have the PR get stuck on this discussion.
app/src/test/kotlin/io/homeassistant/companion/android/webview/addto/EntityAddToActionTest.kt
Show resolved
Hide resolved
app/src/main/kotlin/io/homeassistant/companion/android/webview/addto/EntityAddToAction.kt
Outdated
Show resolved
Hide resolved
app/src/main/kotlin/io/homeassistant/companion/android/webview/addto/EntityAddToAction.kt
Outdated
Show resolved
Hide resolved
app/src/main/kotlin/io/homeassistant/companion/android/webview/addto/EntityAddToAction.kt
Outdated
Show resolved
Hide resolved
...src/main/kotlin/io/homeassistant/companion/android/webview/externalbus/ExternalBusMessage.kt
Outdated
Show resolved
Hide resolved
app/src/test/kotlin/io/homeassistant/companion/android/webview/addto/EntityAddToHandlerTest.kt
Outdated
Show resolved
Hide resolved
It should be merged after the release of Wednesday. I meant that the PR on the frontend has been updated not the frontend itself. I'll remove the todos. |
Co-authored-by: Joris Pelgröm <jpelgrom@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes now look good to me, also tested with yesterday's frontend branch which looks like it is close enough to final.

Summary
We want to make the native features of the companion apps more accessible to the user. When the user is going to click on
Add tofrom the frontend it will display within the more info dialog the list of potential actions. This PR covers the needed change to react to this click on a action but also sending the list of potential actions, inform the frontend that we support this feature and expose a way to add an Android Auto favorite or a widget depending on the domain of the entity. Follow-up PRs are going to add shortcut, tile and watch favorite support.Checklist
Screenshots
see home-assistant/frontend#26346
Link to pull request in documentation repositories
User Documentation: home-assistant/companion.home-assistant#1232
Any other notes
This features depends on the frontend, it will only work when this home-assistant/frontend#26346 is going to be merged.
Only the relevant actions based on the entity, are sent to the frontend.