Allow to reuse VoiceSatelliteService with a custom frontend

[xvello]

Thanks a lot for your work on this implementation! I am currently using Assist with two cheap esp32 devices and want to upgrade to hardware with better microphone sensitivity. It turns out that second-hand Android phones offer significantly better mic sensitivity than any off-the-shelf hardware that esphome supports, so I'm testing out your project.

One of the satellites I want to replace is in the kitchen and is set up to display timer progress on its screen. I understand that this is out of scope for this project, but I ruled out the alternatives (WallPanel because Assist timers are not exposed to dashboards, View Assist has too many moving pieces, the Ava fork does too much) and would rather build on top of your project.

Instead of forking your project, I'd rather build my own simple UI in Kotlin and import VoiceSatelliteService as a library, upstreaming improvements when they make sense.

I see three options I'd like to discuss with you, in order of preference:

• The simplest way to serve my use case is to add a LiveData field that contains the latest MessageLite received from HA, accessible to the UI through the ServiceViewModel. It could also be used in your stock UI to show the STT/TTS strings for debugging. I'll need to confirm that quick-fire updates are sent sequentially to observers without skipping intermediate states.
• The most flexible option would be to make the VoiceSatelliteService and VoiceSatellite open for subclassing and set a few members as protected instead of private, to allow overriding VoiceSatellite.handleMessage. I am fine with occasional breaking changes and would have more "knobs to turn" for future use cases.
• The least intrusive option would be to emit Broadcast messages and have my UI be a separate process, but I'd rather not have to keep two APKs up to date and running.

I hope you'll agree with one of these options that allows sharing efforts on VoiceSatelliteService while opening an escape hatch for features that don't match the scope you want to maintain.

[brownard]

Hi, I am open to this. As you say I want to keep this project narrowly focused on the voice side, but I did ultimately want to implement simple visual feedback, like displaying the TTS response text, timer status, and media playback controls. So if that works for you they could be incorporated into this project.

If you'd prefer to build your own with a dependency on this project then I am also happy to do that. This is my first bit of Android development so I am not sure how things like that are usually done on the platform. If opening up some classes for extensibility works for you then that works for me. Ultimately I'd probably pull the ESPHome implementation stuff out into a separate module that's then imported into a thin app.

[xvello]

That's great news!

It's been almost a decade since I did any serious Android development, so my knowledge is three "rewrite every Android app" old and needs to be refreshed. Jetpack compose feels like an upgrade and does allow more UI re-usability than I was used to, so I might get pretty far without a separate app. I might at some point "soft fork" the home screen into my own layout, reusing existing components.

If TTS response feedback and timer status are in scope, I'll work on exposing these through the viewModel and draft corresponding UI components. How do you prefer to collaborate on these tops? Discuss it scope in an issue first, or review PRs?

[brownard]

I'm happy to just review any PRs, if you open up a draft PR early and keep them fairly narrow in scope we can hopefully avoid any wasted effort.

As above I don't want to reimplement a full dashboard app, but a nice clean interface for simple visual feedback would be great. Making a UI look pretty is not really my area, I'm more of a function over form kind of guy, so if you want to rework any of the general design in the process feel free.