search

session-foundation / session-android

A private messenger for Android.
https://getsession.org
GNU General Public License v3.0
41 stars 4 forks source link

[Feature Request] Allow user to select polling frequency for slow mode notifications #349

Open Para-lyzed opened 2 years ago

Para-lyzed commented 2 years ago

Code of conduct

Currently, it seems that the default polling period for slow mode notifications is 15 minutes. For an instant messenger, this is incredibly slow. If I were to wait 5-15 minutes before responding to any new message I get, it would be rude and very inefficient. Additionally, even after I know a conversation has started, I won't know when I get a new reply unless I have the app constantly open, or I check in every minute, as waiting 15 minutes to reply after the conversation has started is even worse.

I propose that there are options like once a minute, every 3 minutes, every 5 minutes, and maybe even shorter if the polling isn't too resource intensive. This would be a massive improvement for the FOSS notification system, as it isn't very practical to use right now. It would also lend to an experience similar to other FOSS instant messengers with polling notifications, like Element, which never felt like a compromise over using Google FCM.

hjubb commented 2 years ago

This is a good idea. The idea of background polling would probably shift towards a persistent service that users can set to their desired polling time and if the service is stopped fall back to 15 minute intervals. The only downside so far has been that this kind of polling service would need to be in the foreground and have a persistent notification, but I suppose that is a trade-off that users are willing to deal with if it means that polling is more frequent than the current interval

Para-lyzed commented 2 years ago

I also have never had issues with foreground jobs like that after hiding a persistent notification in the settings, so long as I have opened the app since the last boot (though some apps have a "start at boot" option that mitigates that issue). While I'm sure that's device dependent, it means that the notification part of it would affect fewer users, and even if a notification needed to stay shown, it can be a silent and minimized notification that isn't obtrusive.

In fact, that's (at least generally) how Element's polling notification system works. It stays in the foreground with a notification, but I can successfully hide it without losing fast notifications. I don't know the performance/battery drain implications of this with the current implementation of the polling system, as I've seen discussion that it needs to be optimized in previous issues, but at least as far as the Element implementation, I didn't notice a difference in battery use on my device. For the sake of battery, you could also have the default use a slower polling rate (maybe even still the 15 minute background job) as to not influence battery use.

gitbq commented 2 years ago

It seems like this is one of the easier ways to fix the non-Google devices notification issue.