-
-
Notifications
You must be signed in to change notification settings - Fork 392
Conversation
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.
Where to show the current push distributor information?
I think we need a new Account Preference for that
Can we have a rate-limit? At least on sounds? If you are a popular account only Android can (and will) silence Tusky.
Yeah but if you are a popular account you probably disable notifications anyway. Or at least don't have sound on.
I think it would be ideal if it would alert only once per channel, surely there must be a way in Android to do that?
|
||
// reset all accounts | ||
accountManager.accounts.forEach { | ||
// TODO this would like to call reset, but that is suspending; why would DB access be suspending? |
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.
Of course db access is suspending, it is very slow compared to other operations and should run on a background thread.
You can inject the Application Scope and use that to launch a coroutine.
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.
If this runs in the background there is a great (?) chance that the real initialization (with setupNotifications()) which comes slightly afterwards will not find updated account data. Ie. with push fields reset when there is a push provider change?
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.
Yes, that could be a race condition. The solution probably is to have only one place where all initialization is done, so that the different steps can be executed in the correct order.
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.
Is now reordered.
app/src/main/java/com/keylesspalace/tusky/components/systemnotifications/NotificationService.kt
Outdated
Show resolved
Hide resolved
UnifiedPush.unregisterApp(context, account.id.toString()) | ||
} | ||
|
||
private fun buildSubscriptionData(account: AccountEntity): Map<String, Boolean> = | ||
fun fetchNotificationsOnPushMessage(account: AccountEntity) { | ||
// TODO should there be a rate limit here? Ie. we could be silent (can we?) for another notification in a short timeframe. |
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.
Yeah some kind of throttling would be good so we don't spam the server with requests on a lot of pushes. But doesn't the WorkManager do that automatically? Or maybe it can be configured to do so.
// Otherwise the pull worker is still present after starting push notifications (and blocks the one time worker there). | ||
disablePullNotifications() |
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.
Wouldn't it be really good for reliability if we had pull notifications on all the time? Surely there is a way around the one time worker conflict? Usind a different worker or something.
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.
Maybe. :-)
Pull notifications are probably at least as unreliable as push notifications. E. g. with deep sleep no (background) worker ever is executed or only very seldomly. Also I have the feeling that Tusky often not recovers well enough when the device is again active.
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.
We use WorkManager, that should be as reliable as it gets. If we use it correctly.
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.
Pull notifications (worker) is now a fallback anytime.
What would it switch? A preference only for displaying something? Of course there might be potential for that: e. g. reset things and/or choose a provider. But that would be more complex and a later step. |
It would open a new screen or dialog with the info |
Starting with version 4.4.0, Mastodon will support the standard webpush: mastodon/mastodon#33528, so you can get the content of the event from the push messages directly, see the PR for moshidon: LucasGGamerM/moshidon#588 |
@Lakoja Whats your plan for this? Will you add more improvements or are you looking to get it merged like this? |
Should be good to go now. Any other improvements can be a followup. |
app/src/main/res/values/strings.xml
Outdated
@@ -407,6 +407,8 @@ | |||
<string name="about_device_info">%1$s %2$s\nAndroid version: %3$s\nSDK version: %4$d</string> | |||
<string name="about_account_info_title">Your account</string> | |||
<string name="about_account_info">\@%1$s\@%2$s\nVersion: %3$s</string> | |||
<string name="about_push_notification_info_title">Push notifications</string> | |||
<string name="about_push_notification_info">Provider: %1$s</string> |
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.
these are unused
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.
Removed
Besides the refactoring these improvements:
This is (also) the revival of #3642
It's not really well tested so far. (Ie. with two or more accounts or two or more push providers.)