Wavelet icon indicating copy to clipboard operation
Wavelet copied to clipboard

Create multiple channels for Wavelet notifications

Open banannacodepie opened this issue 4 years ago • 4 comments

This is a suggestion which would help those who do not want a persistent wavelet notification when there is not an active session. In general for applications which run services which require a persistent notification, it's nice to be able to disable the notification. However if the application has a notification of a different category (apologies if that terminology is not correct), Android provides the user separate controls to determine if they are hidden or not. What I'm suggesting is that Wavelet has two categories of notifications:

  1. Service Status (this one is on if the wavelet "power" button is active, the service is started and it's monitoring for new audio sessions)
  2. Active (this one is displayed when there is an active session in progress). This one can be persistent or dismissible, but it probably makes sense to be persistent while the session is active.

The way one would use this is the service status notification could be disabled at the OS level, so we don't have the permanent notification, but when a audio session is started, we would get the second notification which would provide a shortcut to the wavelet options and would indicate which that Wavelet is operating.

This idea came up to me because I typically disable the service notification, but recently I discovered my music sounded lame, and that Wavelet was not active. I've since adjust the power optimizations (Pixel 4a running android 11) to ensure it's active, but without a notification, it's not obvious if Wavelet is active or not. So now I've got the permanent notification back again. :P

Hope this is a useful and clear suggestion, and that others can pipe in if they think it would be handy.

Thanks again for developing and supporting Wavelet. It's an excellent tool which brings a Dolby Atmos experience to all Android devices!

banannacodepie avatar Oct 12 '21 17:10 banannacodepie

I'm no expert, but I think what you're talking about are notification channels. https://developer.android.com/training/notify-user/channels

The problem is probably that wavelet needs to have the active/persistent notification in order to detect and process the music. So you could hide that notification channel but still get a notification when it was processing audio, if that was in a different notification channel.

JoeSchubert avatar Oct 12 '21 20:10 JoeSchubert

Yes, thanks for the link. That's exactly it. The user facing term is "Notification category" but the developer lingo is 'Notification channel" I think you summed up my request succinctly in two sentences. :)

banannacodepie avatar Oct 12 '21 20:10 banannacodepie

I like this idea, so I gave it a try. Unfortunately during testing it appeared that when switching to a muted notification channel with an updated notification, the notification would remain in its old state in the old notification channel. The workaround seems to be cancelling the notification, giving it a new ID and restarting the foreground service with a notification in the hidden channel. This quite hacky and may introduce stability issues. I'll have to test more and see if it works out.

Pittvandewitt avatar Nov 18 '21 22:11 Pittvandewitt

Thanks for giving it a shot. I'm not quite sure I comprehend the issue. It sounds like muted notifications are not refreshed when they are updated? Could that behavior be intended to reduce work since if the channel is muted, then no notification would occur anyway?

Regardless, the workaround described does sound less than ideal! :|

banannacodepie avatar Nov 19 '21 04:11 banannacodepie

Thanks for giving it a shot. I'm not quite sure I comprehend the issue. It sounds like muted notifications are not refreshed when they are updated? Could that behavior be intended to reduce work since if the channel is muted, then no notification would occur anyway?

That's correct. I can't provide an answer as to 'why'. I'm afraid I have to close this issue as infeasible.

Pittvandewitt avatar Mar 29 '23 07:03 Pittvandewitt